- Elastic Cloud Serverless
- Elasticsearch
- Elastic Observability
- Get started
- Observability overview
- Elastic Observability Serverless billing dimensions
- Create an Observability project
- Quickstart: Monitor hosts with Elastic Agent
- Quickstart: Monitor your Kubernetes cluster with Elastic Agent
- Quickstart: Monitor hosts with OpenTelemetry
- Quickstart: Unified Kubernetes Observability with Elastic Distributions of OpenTelemetry (EDOT)
- Quickstart: Collect data with AWS Firehose
- Get started with dashboards
- Applications and services
- Application performance monitoring (APM)
- Get started with traces and APM
- Learn about data types
- Collect application data
- View and analyze data
- Act on data
- Use APM securely
- Reduce storage
- Managed intake service event API
- Troubleshooting
- Synthetic monitoring
- Get started
- Scripting browser monitors
- Configure lightweight monitors
- Manage monitors
- Work with params and secrets
- Analyze monitor data
- Monitor resources on private networks
- Use the CLI
- Configure a Synthetics project
- Multifactor Authentication for browser monitors
- Configure Synthetics settings
- Grant users access to secured resources
- Manage data retention
- Scale and architect a deployment
- Synthetics Encryption and Security
- Troubleshooting
- Application performance monitoring (APM)
- Infrastructure and hosts
- Logs
- Inventory
- Incident management
- Data set quality
- Observability AI Assistant
- Machine learning
- Reference
- Get started
- Elastic Security
- Elastic Security overview
- Security billing dimensions
- Create a Security project
- Elastic Security requirements
- Elastic Security UI
- AI for Security
- Ingest data
- Configure endpoint protection with Elastic Defend
- Manage Elastic Defend
- Endpoints
- Policies
- Trusted applications
- Event filters
- Host isolation exceptions
- Blocklist
- Optimize Elastic Defend
- Event capture and Elastic Defend
- Endpoint protection rules
- Identify antivirus software on your hosts
- Allowlist Elastic Endpoint in third-party antivirus apps
- Elastic Endpoint self-protection features
- Elastic Endpoint command reference
- Endpoint response actions
- Cloud Security
- Explore your data
- Dashboards
- Detection engine overview
- Rules
- Alerts
- Advanced Entity Analytics
- Investigation tools
- Asset management
- Manage settings
- Troubleshooting
- Manage your project
- Changelog
Using logsdb index mode with Elastic Security Serverless
editUsing logsdb index mode with Elastic Security Serverless
editLogsdb is enabled by default for Elastic Cloud Serverless. This topic explains the impact of using logsdb index mode with Elastic Security Serverless.
With logsdb index mode, the original _source
field is not stored in the index but can be reconstructed using synthetic _source
.
When the _source
is reconstructed, modifications are possible. Therefore, there could be a mismatch between users' expectations and how fields are formatted.
Continue reading to find out how this affects specific Elastic Security Serverless components.
Alerts
editWhen alerts are generated, the _source
event is copied into the alert to retain the original data. When the logsdb index mode is applied, the _source
event stored in the alert is reconstructed using synthetic _source
.
If you’re switching to use logsdb index mode, the _source
field stored in the alert might look different in certain situations:
- Arrays can be reconstructed differently or deduplicated
- Field names
-
geo_point
data fields (refer to Representation of ranges and Reduced precision ofgeo_point
values for more information)
Alerts generated by the following rule types could be affected:
- Custom query
- Event correlation (non-sequence only)
- Non-aggregate rule types (for example, ES|QL rules that use non-aggregating queries)
Alerts that are generated by threshold, machine learning, and event correlation sequence rules are not affected since they do not contain copies of the original source.
Rule actions
editWhile we do not recommend using _source
for actions, in cases where the action relies on the _source
, the same limitations and changes apply.
If you send alert notifications by enabling actions to the external systems that have workflows or automations based on fields formatted from the original source, they may be affected. In particular, this can happen when the fields used are arrays of objects.
We recommend checking and adjusting the rule actions using _source
before switching to logsdb index mode.
Runtime fields
editRuntime fields that reference _source
may be affected. Some runtime fields might not work and need to be adjusted. For example, if an event was indexed with the value of agent.name
in the dot-notation form, it will be returned in the nested form and might not work.
The following is an example of accessing _source
that works with the logsdb index mode enabled:
"source": """ emit(params._source.agent.name + "_____" + doc['agent.name'].value ); """ "source": """ emit(params._source['agent']['name'] + "_____" + doc['agent.name'].value ); """ "source": """ emit(field('agent.name').get(null) + "_____" + doc['agent.name'].value ); """ "source": """ emit($('agent.name', null) + "_____" + doc['agent.name'].value ); """
The following will not work with synthetic source (logsdb index mode enabled):
"source": """ emit(params._source['agent.name'] + "_____" + doc['agent.name'].value ); """
On this page