- Observability: other versions:
- What is Elastic Observability?
- What’s new in 8.7
- Send data to Elasticsearch
- Spin up the Elastic Stack
- Deploy Elastic Agent to send data
- Deploy Beats to send data
- Elastic Serverless Forwarder for AWS
- Deploy serverless forwarder
- Configuration options
- Troubleshooting
- Observability overview page
- Application performance monitoring (APM)
- Application logs
- Log monitoring
- Infrastructure monitoring
- Uptime
- Synthetics (beta)
- Get started
- Scripting browser monitors
- Configure lightweight monitors
- Manage monitors
- Analyze monitor data
- Monitor resources on private networks
- Use the CLI
- Configure projects
- Configure Synthetics settings
- Grant users access to secured resources
- Manage data retention
- Use Synthetics with traffic filters
- Migrate from the Elastic Synthetics integration
- User Experience
- Universal Profiling
- Alerting
- Cases
- CI/CD observability
- Troubleshooting
- Fields reference
- Tutorials
- Monitor Amazon Web Services (AWS) with Elastic Agent
- Monitor Amazon Web Services (AWS) with Beats
- Monitor Google Cloud Platform
- Monitor a Java application
- Monitor Kubernetes
- Monitor Microsoft Azure with Elastic Agent
- Monitor Microsoft Azure with the native Azure integration
- Monitor Microsoft Azure with Beats
Using the Event ID format (version 1.6.0 and above)
editUsing the Event ID format (version 1.6.0 and above)
editVersion 1.6.0 introduces a new event ID format that prevents duplicate ID errors when a high volume of events is ingested to Elasticsearch. This new format combines a timestamp with data specific to the relevant AWS resource, extracted from the AWS Lambda event received by the forwarder.
The timestamp is used as a prefix for the ID, because identifiers that gradually increase over time generally result in better indexing performance in Elasticsearch, based on sorting order rather than completely random identifiers. For more information, please refer to this Elastic blog on event-based data.
If old events that are already published to Elasticsearch using a version of Elastic Serverless Forwarder before v1.6.0 are ingested again, they will be treated as new events and published to Elasticsearch as duplicates.