106 lines
3.8 KiB
Plaintext
106 lines
3.8 KiB
Plaintext
//////////////////////////////////////////////////////////////////////////
|
|
//// This content is shared by all Elastic Beats. Make sure you keep the
|
|
//// descriptions here generic enough to work for all Beats that include
|
|
//// this file. When using cross references, make sure that the cross
|
|
//// references resolve correctly for any files that include this one.
|
|
//// Use the appropriate variables defined in the index.asciidoc file to
|
|
//// resolve Beat names: beatname_uc and beatname_lc.
|
|
//// Use the following include to pull this content into a doc file:
|
|
//// include::../../libbeat/docs/generalconfig.asciidoc[]
|
|
//// Make sure this content appears below a level 2 heading.
|
|
//////////////////////////////////////////////////////////////////////////
|
|
|
|
[float]
|
|
[[configuration-general]]
|
|
=== General configuration options
|
|
|
|
These options are supported by all Elastic Beats. Because they are common
|
|
options, they are not namespaced.
|
|
|
|
Here is an example configuration:
|
|
|
|
[source,yaml]
|
|
------------------------------------------------------------------------------
|
|
name: "my-shipper"
|
|
tags: ["service-X", "web-tier"]
|
|
------------------------------------------------------------------------------
|
|
|
|
[float]
|
|
==== `name`
|
|
|
|
The name of the Beat. If this option is empty, the `hostname` of the server is
|
|
used. The name is included as the `beat.name` field in each published transaction. You can
|
|
use the name to group all transactions sent by a single Beat.
|
|
|
|
Example:
|
|
|
|
[source,yaml]
|
|
------------------------------------------------------------------------------
|
|
name: "my-shipper"
|
|
------------------------------------------------------------------------------
|
|
|
|
[float]
|
|
==== `tags`
|
|
|
|
A list of tags that the Beat includes in the `tags` field of each published
|
|
transaction. Tags make it easy to group servers by different logical properties.
|
|
For example, if you have a cluster of web servers, you can add the "webservers"
|
|
tag to the Beat on each server, and then use filters and queries in the Kibana
|
|
web interface to get visualisations for the whole group of servers.
|
|
|
|
Example:
|
|
|
|
[source,yaml]
|
|
--------------------------------------------------------------------------------
|
|
tags: ["my-service", "hardware", "test"]
|
|
--------------------------------------------------------------------------------
|
|
|
|
[float]
|
|
[[libbeat-configuration-fields]]
|
|
==== `fields`
|
|
|
|
Optional fields that you can specify to add additional information to the
|
|
output. Fields can be scalar values, arrays, dictionaries, or any nested
|
|
combination of these. By default, the fields that you specify here will be
|
|
grouped under a `fields` sub-dictionary in the output document. To store the
|
|
custom fields as top-level fields, set the `fields_under_root` option to true.
|
|
|
|
Example:
|
|
|
|
[source,yaml]
|
|
------------------------------------------------------------------------------
|
|
fields: {project: "myproject", instance-id: "574734885120952459"}
|
|
------------------------------------------------------------------------------
|
|
|
|
[float]
|
|
==== `fields_under_root`
|
|
|
|
If this option is set to true, the custom <<libbeat-configuration-fields,fields>> are
|
|
stored as top-level fields in the output document instead of being grouped under
|
|
a `fields` sub-dictionary. If the custom field names conflict with other field
|
|
names, then the custom fields overwrite the other fields.
|
|
|
|
Example:
|
|
|
|
[source,yaml]
|
|
------------------------------------------------------------------------------
|
|
fields_under_root: true
|
|
fields:
|
|
instance_id: i-10a64379
|
|
region: us-east-1
|
|
------------------------------------------------------------------------------
|
|
|
|
[float]
|
|
==== `processors`
|
|
|
|
A list of processors to apply to the data generated by the beat.
|
|
|
|
See <<filtering-and-enhancing-data>> for information about specifying
|
|
processors in your config.
|
|
|
|
[float]
|
|
==== `max_procs`
|
|
|
|
Sets the maximum number of CPUs that can be executing simultaneously. The
|
|
default is the number of logical CPUs available in the system.
|