- Observability: other versions:
- Get started
- What is Elastic Observability?
- What’s new in 8.17
- 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
- Add data from Splunk
- Applications and services
- Application performance monitoring (APM)
- Get started
- Learn about data types
- Collect application data
- View and analyze data
- Act on data
- Use APM securely
- Manage storage
- Configure APM Server
- Monitor APM Server
- APM APIs
- Troubleshooting
- Upgrade
- Release notes
- Known issues
- 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 projects
- Multi-factor Authentication
- Configure Synthetics settings
- Grant users access to secured resources
- Manage data retention
- Use Synthetics with traffic filters
- Migrate from the Elastic Synthetics integration
- Scale and architect a deployment
- Synthetics support matrix
- Synthetics Encryption and Security
- Troubleshooting
- Real user monitoring
- Uptime monitoring (deprecated)
- Tutorial: Monitor a Java application
- Application performance monitoring (APM)
- CI/CD
- Cloud
- Infrastructure and hosts
- Logs
- Troubleshooting
- Incident management
- Data set quality
- Observability AI Assistant
- Reference
IMPORTANT: No additional bug fixes or documentation updates
will be released for this version. For the latest information, see the
current release documentation.
What happens when APM Server or Elasticsearch is down?
edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.
What happens when APM Server or Elasticsearch is down?
editIf Elasticsearch is down
APM Server does not have an internal queue to buffer requests, but instead leverages an HTTP request timeout to act as back-pressure. If Elasticsearch goes down, the APM Server will eventually deny incoming requests. Both the APM Server and APM agent(s) will issue logs accordingly.
If APM Server is down
Some agents have internal queues or buffers that will temporarily store data if the APM Server goes down. As a general rule of thumb, queues fill up quickly. Assume data will be lost if APM Server goes down. Adjusting these queues/buffers can increase the agent’s overhead, so use caution when updating default values.
-
Go agent - Circular buffer with configurable size:
ELASTIC_APM_BUFFER_SIZE. -
Java agent - Internal buffer with configurable size:
max_queue_size. - Node.js agent - No internal queue. Data is lost.
- PHP agent - No internal queue. Data is lost.
- Python agent - Internal Transaction queue with configurable size and time between flushes.
-
Ruby agent - Internal queue with configurable size:
api_buffer_size. - RUM agent - No internal queue. Data is lost.
- .NET agent - No internal queue. Data is lost.
Was this helpful?
Thank you for your feedback.