Apm-server

When an application is slow or returns errors, Elastic APM helps connect those symptoms to the requests and code involved. APM Server is the receiving service in that system: small agents inside your applications send it timing, error and transaction data, which it prepares for storage in Elasticsearch. Use it when you need that intake path for Elastic's application monitoring; installing the server alone does not instrument your applications.

Current guidance

This is Elastic APM Server, the intake service used by application instrumentation, not the application agents themselves. ECK provides an ApmServer resource and can configure Elasticsearch output trust through elasticsearchRef. Its current integration guide also describes the Kibana reference and APM integration-package configuration needed for applicable server versions. Reusing the original chart values without those version-specific requirements can produce a listening endpoint that fails to store usable telemetry.

Inventory agent versions, intake URLs, service names, sampling settings and authentication before changing the server. Keep TLS verification enabled and distinguish server-side agent credentials from browser RUM traffic, where a shared secret embedded in JavaScript is not private. Preserve any ingress body-size, timeout and network-access requirements rather than assuming a generic web-service configuration is sufficient.

Run a known transaction with an error through the candidate and confirm the resulting trace and service metadata in the intended Elasticsearch data streams and Kibana views. Check rejected requests, ingestion delay and retention behavior as well as Pod health. A temporary parallel intake path should have bounded traffic and cost; changing the server does not automatically migrate existing observability data or instrument applications that were never sending it.