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
Intro
Application Performance Monitoring
Application performance monitoring, or APM, tracks the speed, reliability, and availability of software in production. It helps you detect a poor user experience, locate the affected operation, and gather evidence about the cause.
The useful mental model is a feedback loop:
user-visible symptom
↓
service health signal
↓
affected transaction or endpoint
↓
slow span, failing dependency, or exhausted resource
↓
change, deploy, and measure again
APM narrows the distance between “checkout is slow” and “the payment database call dominates the slow traces after this deployment.” It does not prove causation by itself. It gives you correlated evidence for a disciplined investigation.
Why APM exists
A healthy host does not guarantee a healthy application. CPU and memory can look normal while one endpoint times out for a specific customer path. An application can also return errors quickly, making an average response-time chart appear healthy.
APM starts closer to the work users ask the application to perform. It treats requests, transactions, jobs, and dependencies as first-class units. You can then connect their behavior to runtime and infrastructure signals.
AWS defines APM as monitoring and managing the ongoing performance and availability of production systems. Its guidance pairs APM with real-user monitoring and synthetic monitoring for broader coverage. Real-user monitoring captures actual interactions. Synthetic monitoring runs scripted interactions, including when no real traffic exists.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
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 as monitoring application speed, reliability, and availability for issue detection, alerting, and root-cause investigation
- Automatic instrumentation without application source changes
- Attribute and cardinality definitions, including user identifiers as high-cardinality values
- Quiz questions 1 and 8 and the first links rationale
- https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/o.cm.5-detect-performance-issues-using-application-performance-monitoring.html
Supports
- APM as ongoing real-time monitoring and management of production performance and availability
- APM supporting early detection, diagnosis, service maintenance, and reduced resolution time
- Real-user monitoring capturing actual interactions and synthetic monitoring using scripted canaries without real traffic
- APM, real-user monitoring, and synthetic monitoring as complementary coverage
- Quiz question 1 and the second links rationale
- https://sre.google/sre-book/monitoring-distributed-systems/
Supports
- Four golden signals as latency, traffic, errors, and saturation
- Separating successful and failed request latency
- Dashboards, alerting, trend analysis, and retrospective debugging purposes
- Symptom-first monitoring and avoiding premature cause assumptions
- Quiz questions 2 and 9 and the third links rationale
- https://sre.google/sre-book/service-level-objectives/
Supports
- User-centered service level indicators
- Client-side collection where server measurements miss user problems
- Average latency hiding materially different tail behavior
- Percentiles describing typical and high-tail latency behavior
- Quiz questions 2 and 6 and the fourth links rationale
- https://opentelemetry.io/docs/what-is-opentelemetry/
Supports
- OpenTelemetry generating, collecting, and exporting traces, metrics, and logs
- OpenTelemetry as vendor- and tool-agnostic and not an observability backend
- Backend storage and visualization intentionally supplied by other tools
- OpenTelemetry Protocol, semantic conventions, APIs, SDKs, libraries, automatic instrumentation, and Collector components
- Quiz questions 3 and 10 and the fifth links rationale
- https://opentelemetry.io/docs/concepts/instrumentation/
Supports
- Instrumentation as application components emitting telemetry signals
- Zero-code and code-based instrumentation as complementary modes
- Code-based instrumentation providing deeper application insight
- Zero-code instrumentation covering libraries and application edges without source changes
- Context propagation correlating signals and semantic conventions standardizing names
- The sixth links rationale
- https://opentelemetry.io/docs/concepts/signals/traces/
Supports
- Spans as units of work and building blocks of traces
- Span name, parent, timestamps, context, attributes, events, links, and status
- Nested spans representing sub-operations and span context being propagated
- Span links representing causal relationships, including asynchronous work
- Quiz questions 4, 5, and 9 and the seventh links rationale
- https://www.w3.org/TR/trace-context/
Supports
- Interoperable traceparent and tracestate headers
- Creating or forwarding trace identity and parent identity across request boundaries
- Broken propagation producing disconnected trace context
- Quiz question 5 and the eighth links rationale
- https://opentelemetry.io/docs/concepts/components/
Supports
- Collector as a vendor-agnostic proxy receiving, processing, filtering, and exporting telemetry to one or more backends
- Language APIs and SDKs generating telemetry and incorporating instrumentation libraries
- Production export through a Collector
- https://opentelemetry.io/docs/concepts/sampling/
Supports
- Head sampling deciding early without inspecting the complete trace
- Head sampling efficiency and inability to guarantee retention of traces containing later errors
- Tail sampling selecting using errors, latency, or attributes after considering most or all spans
- Tail sampling state, resource, operational, and vendor-specific trade-offs
- Quiz question 7 and the ninth links rationale
- https://opentelemetry.io/docs/security/handling-sensitive-data/
Supports
- Implementer responsibility for privacy compliance, consent, protection, storage, and instrumentation review
- Sensitive data examples including personal data, credentials, tokens, financial data, health data, and user behavior
- Data minimization and collecting only data with an observability purpose
- Collector filtering, attribute removal, transformation, hashing, and redaction controls
- Quiz question 10 and the tenth links rationale