Elastic Agent uses data streams to store time series data across multiple indices while giving you a single named resource for requests. Data streams are well-suited for logs, metrics, traces, and other continuously generated data. They offer a host of benefits over other indexing strategies:
- Reduced number of fields per index: Indices only need to store a specific subset of your data–meaning no more indices with hundreds of thousands of fields. This leads to better space efficiency and faster queries. As an added bonus, only relevant fields are shown in Discover.
- More granular data control: For example, file system, load, CPU, network, and process metrics are sent to different indices–each potentially with its own rollover, retention, and security permissions.
- Flexible: Use the custom namespace component to divide and organize data in a way that makes sense to your use case or company.
- Fewer ingest permissions required: Data ingestion only requires permissions to append data.
Data stream naming schemeedit
Elastic Agent uses the Elastic data stream naming scheme to name data streams. The naming scheme splits data into different streams based on the following components:
typedescribing the data, such as
datasetis defined by the integration and describes the ingested data and its structure for each index. For example, you might have a dataset for process metrics with a field describing whether the process is running or not, and another dataset for disk I/O metrics with a field describing the number of bytes read.
A user-configurable arbitrary grouping, such as an environment (
qa), a team, or a strategic business unit. A
namespacecan be up to 100 bytes in length (multibyte characters will count toward this limit faster). Using a namespace makes it easier to search data from a given source by using a matching pattern. You can also use matching patterns to give users access to data when creating user roles.
The naming scheme separates each components with a
For example, if you’ve set up the Nginx integration with a namespace of
Elastic Agent uses the
nginx.access dataset, and
prod namespace to store data in the following data stream:
Alternatively, if you use the APM integration with a namespace of
Elastic Agent stores data in the following data stream:
All data streams, and the pre-built dashboards that they ship with, are viewable on the Fleet Data Streams page:
If you’re familiar with the concept of indices, you can think of each data stream as a separate index in Elasticsearch. Under the hood though, things are a bit more complex. All of the juicy details are available in Elasticsearch Data streams.
When searching your data in Kibana, you can use a data view to search across all or some of your data streams.
An index template is a way to tell Elasticsearch how to configure an index when it is created. For data streams, the index template configures the stream’s backing indices as they are created.
Elasticsearch provides the following built-in, ECS based templates:
Elastic Agent integrations can also provide dataset-specific index templates, like
These templates are loaded when the integration is installed, and are used to configure the integration’s data streams.
Index lifecycle management (ILM)edit
Use the index lifecycle management (ILM) feature in Elasticsearch to manage your Elastic Agent data stream indices as they age. For example, create a new index after a certain period of time, or delete stale indices to enforce data retention standards.
Installed integrations may have one or many associated data streams—each with an associated ILM policy.
By default, these data streams use an ILM policy that matches their data type.
For example, the data stream
uses the metrics ILM policy as defined in the
metrics-system.logs index template.
Want to customize your index lifecycle management? See Tutorial: Customize data retention policies.
Elastic Agent integration data streams ship with a default ingest pipeline that preprocesses and enriches data before indexing. The default pipeline should not be directly edited as changes can easily break the functionality of the integration.
Starting in version 8.4, all default ingest pipelines call a non-existent and non-versioned "
@custom" ingest pipeline.
If left uncreated, this pipeline has no effect on your data. However, if added to a data stream and customized,
this pipeline can be used for custom data processing, adding fields, sanitizing data, and more.
The full name of the
@custom pipeline follows the following pattern:
@custom pipeline can directly contain processors or you can use the
pipeline processor to call other pipelines that can be shared across multiple data streams or integrations.
@custom pipeline will persist across all version upgrades.
See Tutorial: Transform data with custom ingest pipelines to get started.