8.2. Tools and Standards
The signals are only as useful as the pipeline that collects, stores, and queries them — and the wrong tool choice here becomes a cost and cardinality problem that scales with your traffic. This chapter covers the vendor-neutral instrumentation standard (OpenTelemetry), the pull-based metrics model of Prometheus and its query language, dashboarding and alerting with Grafana, the tracing backends (Jaeger, Tempo), and the kernel-level observability that eBPF unlocks without touching application code.
Topics Covered
Section titled “Topics Covered”- 8.2.1. OpenTelemetry: The Vendor-Neutral Instrumentation Standard: Covers OpenTelemetry, the vendor-neutral standard for instrumenting code once and exporting anywhere.
- 8.2.2. Prometheus: Pull-Based Metric Collection and PromQL: Explains Prometheus’s pull-based collection, PromQL, and the cardinality explosion that kills it.
- 8.2.3. Grafana: Dashboard Design and Alerting: Covers Grafana dashboard design and alerting that turns raw metrics into actionable signals.
- 8.2.4. Jaeger / Zipkin / Tempo: Distributed Tracing Backends: Compares Jaeger, Zipkin, and Tempo as tracing backends, and head-versus-tail sampling trade-offs.
- 8.2.5. Loki: Log Aggregation with the Prometheus Philosophy: Explains Loki, which applies the Prometheus label model to logs for cheap, index-light aggregation.
- 8.2.6. eBPF: Kernel-Level Observability (Cilium, Pixie): Covers eBPF observability with Cilium and Pixie: kernel-level visibility without touching application code.