Application Performance Monitoring
Application performance monitoring (APM) instruments running software to measure response times, error rates, throughput, and resource consumption. It helps teams detect degradations, trace slow requests across services, and identify bottlenecks before users are affected.
itObservability and performance | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic — Application Performance Monitoring
Application performance monitoring, or APM, is how you follow a piece of application work through production without interrogating every server as though it were personally responsible for checkout. It watches the speed, reliability, and availability of requests, jobs, and dependencies. The goal is modest and valuable: turn “something is slow” into evidence worth testing.
The useful shape is a feedback loop. A user notices a symptom. A service signal says which operation is affected. A trace, the record of one operation across components, leads to its spans, the timed pieces of that operation. From there, you form one hypothesis, change one thing, and measure the original signal again. A dashboard is merely where the clues wait.
The mildly rude surprise is that healthy infrastructure can coexist with a broken application path. CPU may be calm while one payment call consumes most of a checkout trace. An average latency can look polite while a smaller group of requests waits far too long. That is why APM begins with operations and user-facing latency, errors, traffic, and saturation rather than a general hunt for a guilty machine.
Instrumentation produces the telemetry. Zero-code instrumentation gives broad coverage of familiar frameworks; code-based instrumentation supplies the business meaning a framework cannot guess. Context propagation carries a trace identity across services, proxies, and queues. Lose it at one boundary and the request becomes several disconnected stories, which is rather like receiving a mystery novel with the middle pages filed in another building.
The evidence comes in several forms. Metrics reveal changing rates and latency distributions. Traces show an individual path. Logs retain detailed events. Profiles explain which code consumed CPU or memory after a trace has narrowed the search. They are collaborators, not substitutes. Sampling and attribute choices decide what remains visible and what becomes expensive or sensitive, so they deserve deliberate budgets.
Read the Intro when you need the full data path and the limits of APM. Use the Slides for the relationships between signals, spans, propagation, and sampling. Keep the Cheatsheet nearby during an investigation. Then try the Exercise: it makes the feedback loop tangible by comparing a local baseline, a known scenario, and the evidence after reversal.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://opentelemetry.io/docs/concepts/glossary/
Supports
- APM terminology, automatic instrumentation, attributes, and cardinality
- https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/o.cm.5-detect-performance-issues-using-application-performance-monitoring.html
Supports
- APM, real-user monitoring, and synthetic monitoring coverage
- https://sre.google/sre-book/monitoring-distributed-systems/
Supports
- Four golden signals and symptom-first monitoring
- https://sre.google/sre-book/service-level-objectives/
Supports
- User-centered indicators and latency distributions
- https://opentelemetry.io/docs/what-is-opentelemetry/
Supports
- OpenTelemetry components, the 2019 merger, and its role outside an APM backend
- https://opentelemetry.io/docs/concepts/instrumentation/
Supports
- Zero-code and code-based instrumentation and context propagation
- https://opentelemetry.io/docs/concepts/signals/traces/
Supports
- Span structure, parentage, links, and context
- https://www.w3.org/TR/trace-context/
Supports
- Interoperable traceparent and tracestate propagation
- https://opentelemetry.io/docs/concepts/components/
Supports
- Collector pipeline responsibilities
- https://opentelemetry.io/docs/concepts/sampling/
Supports
- Head and tail sampling trade-offs
- https://opentelemetry.io/docs/security/handling-sensitive-data/
Supports
- Telemetry privacy, minimization, filtering, and redaction
- https://opentelemetry.io/docs/demo/
Supports
- Local Docker demo deployment and documented feature-flag scenarios for the exercise
- https://opentelemetry.io/docs/collector/quick-start/
Supports
- Local collection pipeline and trace inspection
- https://research.google/pubs/dapper-a-large-scale-distributed-systems-tracing-infrastructure/
Supports
- 2010 Dapper milestone
- https://github.com/openzipkin/zipkin
Supports
- Zipkin as an open-source distributed tracing project
- https://www.cncf.io/blog/2016/10/11/opentracing-joins-the-cloud-native-computing-foundation
Supports
- OpenTracing CNCF acceptance in 2016
- https://www.cncf.io/blog/2016/10/20/opentracing-turning-the-lights-on-for-microservices/
Supports
- OpenTracing goals and its 2015 origin
- https://www.cncf.io/blog/2016/05/09/cncf-accepts-prometheus-as-its-second-hosted-project/
Supports
- Prometheus CNCF acceptance in 2016
- https://github.com/census-instrumentation/opencensus-go
Supports
- OpenCensus tracing and metrics libraries
- https://www.cncf.io/projects/opentracing/
Supports
- OpenTracing archive status in 2021
- https://opentelemetry.io/blog/2023/sunsetting-opencensus/
Supports
- OpenCensus archive in 2023 and OpenTelemetry migration
- https://slack.engineering/tracing-at-slack-thinking-in-causal-graphs/
Supports
- Trace causal-graph design, sampling scale, and trace-volume trade-offs
- https://slack.engineering/tracing-notifications/
Supports
- Cross-system telemetry semantics, trace modeling, and faster notification triage
