Configure general settings
Elastic Cloud Serverless projects are autoscaled environments, fully managed by Elastic and available on Elastic Cloud. Availability This functionality is generally available and ready for production usage. Serverless interfaces and procedures might differ from classic Elastic Stack deployments. The Elastic Stack includes Elastic's core products such as Elasticsearch, Kibana, Logstash, and Beats. Availability This functionality is generally available and ready for production usage. Unless stated otherwise on the page, this functionality is available when your Elastic Stack is deployed on Elastic Cloud Hosted, Elastic Cloud Enterprise, Elastic Cloud on Kubernetes, and self-managed environments. This documentation corresponds to the latest patch available for each minor version. If you're not using the latest patch, check the release notes for changes.
Serverless
Generally available
Stack
Generally available
You can specify settings in the auditbeat.yml config file to control the general behavior of Auditbeat.
These options are supported by all Elastic Beats. Because they are common options, they are not namespaced.
Here is an example configuration:
name: "my-shipper"
tags: ["service-X", "web-tier"]
The name of the Beat. If this option is empty, the hostname of the server is used. The name is included as the agent.name field in each published transaction. You can use the name to group all transactions sent by a single Beat.
Example:
name: "my-shipper"
The Elastic Stack includes Elastic's core products such as Elasticsearch, Kibana, Logstash, and Beats. Availability We plan to add this functionality in a future Elastic Stack update. Subject to changes. Unless stated otherwise on the page, this functionality is available when your Elastic Stack is deployed on Elastic Cloud Hosted, Elastic Cloud Enterprise, Elastic Cloud on Kubernetes, and self-managed environments. This documentation corresponds to the latest patch available for each minor version. If you're not using the latest patch, check the release notes for changes.
Stack
Planned
Planned
Sets the hostname the Beat reports in host.name and observer.hostname (when add_observer_metadata is configured). Use this when the Beat cannot determine its own hostname, for example in Kubernetes environments where os.Hostname() returns a pod name instead of the node name.
Example:
hostname: "k8s-node-01"
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:
tags: ["my-service", "hardware", "test"]
When the Beat is managed by Elastic Agent, tags applied to the Elastic Agent are also added to the tags field of every event.
Elastic Agent tags are appended to any tags already on the event rather than replacing them. For example, a Beat configured with tags: ["my-service"] and an agent tagged production publishes events with tags: ["my-service", "production"]. Tags are not de-duplicated, so a tag set both here and on the Elastic Agent appears twice.
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:
fields: {project: "myproject", instance-id: "574734885120952459"}
If this option is set to true, the custom 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:
fields_under_root: true
fields:
instance_id: i-10a64379
region: us-east-1
A list of processors to apply to the data generated by the beat.
See Processors for information about specifying processors in your config.
Sets the maximum number of CPUs that can be executing simultaneously. The default is the number of logical CPUs available in the system.
Configure the precision of all timestamps. By default it is set to millisecond. Available options: millisecond, microsecond, nanosecond