Skip to main content
Quickly review the diagnostic endpoints built into the OpenTelemetry Collector and when to use each. These tools help with operational visibility, orchestration readiness, live component inspection, and deep runtime profiling. We have four main endpoints for troubleshooting the Collector:
  • Metrics: operational visibility and ingestion verification.
  • Health check: simple heartbeat for orchestration Liveness/Readiness checks.
  • zPages: live, in-browser component views for interactive debugging.
  • pprof: advanced Go runtime profiles (CPU, memory, contention).
Metrics validate that data is being received and delivered to backends. They reveal ingestion/delivery patterns and surface internal resource usage trends inside the Collector.
The image compares different metrics and tools for tracking and ingestion, like "Metrics," "Health Check," "zPages," and "pprof," with numbers beside each. There are options related to "Enable and track ingestion," "Delivery," and "Resource Usage."
Health check endpoints are primarily for orchestration systems (Kubernetes, Nomad, etc.). Use them during rollouts, restarts, or whenever the orchestrator needs a simple OK/Not-OK probe to manage lifecycle operations. zPages provides quick, live, in-browser views of what Collector components are doing. Use zPages for hands-on troubleshooting when you want to inspect component internals without attaching debuggers or altering configuration.
The image is a screenshot showing different components with associated ports, specifically "Metrics (8888)," "Health Check (13133)," "zPages (55679)," and "pprof (1777)." The "zPages" component is highlighted, with a note about live, in-browser component views.
pprof is for advanced investigations: capture CPU profiles, inspect heap allocations, and analyze mutex contention. Use pprof when you suspect performance bottlenecks or need to profile under realistic load.
The image is a diagram titled "pprof — When to Use," showing four sections: Metrics, Health Check, zPages, and pprof, each with a port number. Below pprof, there are options for CPU, Memory, and Contention analysis.
Below is a concise example Collector configuration showing where to enable these diagnostic extensions and how to expose the Collector’s own Prometheus metrics for scraping. Note that metrics are configured under service.telemetry.metrics, while health check, pprof, and zPages are configured as extensions and then referenced under service.extensions.
pprof is powerful but advanced. Use it when you need CPU or memory profiles to diagnose performance bottlenecks. For day-to-day checks, rely on metrics, health checks, and zPages.
Below is a quick reference table for these endpoints and when to use them:
EndpointPortPurposeTypical Use
Metrics8888Prometheus-compatible operational metricsValidate ingestion and delivery patterns; monitor resource usage
Health check13133Liveness/readiness heartbeatOrchestration probes during rollouts and restarts
zPages55679In-browser component insightsLive troubleshooting of component internals without a debugger
pprof1777Go runtime profiling (CPU, memory, contention)Deep performance analysis under load
Links and references:
The image shows a "Wrap Up" slide with four sections: Metrics 8888, Health 13133, zPages 55679, and pprof 1777, each with related features like built-in metrics, heartbeat signal, in-browser view, and live debug.
That wraps up this topic.

Watch Video