Application Performance Monitoring and Distributed Tracing Configuration
This domain tests APM and distributed tracing configuration: how services are discovered, how traces are assembled across tiers, and how application perspectives shape what users see.
Instrumentation model
Instana sensors auto-instrument supported runtimes and middleware; the agent must be present on the application host or in the pod. Services and endpoints are discovered from traffic and runtime metadata. Application perspectives group services and calls for a business or team view. Trace context must propagate across HTTP, messaging, and async boundaries.
Configuration checks
Verify the runtime sensor is enabled, the process started after agent installation, and the runtime version is supported. Instana propagates its own trace headers and supports W3C Trace Context where configured. Sampling and payload capture affect trace volume and detail, not service discovery.
Worked example
A Java service appears in the dashboard but downstream database calls are missing. Confirm the agent is connected on the app host, the JDBC or middleware sensor is enabled, and the call actually leaves the JVM. If the call uses an unsupported driver or a connection pool created before instrumentation, restart or adjust the sensor configuration.
Traps
Instrumenting only the entry service, ignoring asynchronous context loss, and mistaking a missing application perspective for a missing agent are frequent errors. Do not disable tracing globally to silence one noisy endpoint; scope or sample instead.