Book Consultation Submit Ticket

Prometheus, Grafana, and OpenTelemetry: A Production Observability Field Guide

This post walks through a real-world incident, showing how Prometheus, Grafana, and OpenTelemetry work together to diagnose and resolve a performance issue. Includes commands, risk controls, rollback steps, and guidance on when to escalate to OpsGlobal.

Prometheus, Grafana, and OpenTelemetry: A Production Observability Field Guide
Observability 6min 41 views 2026-07-18
PrometheusGrafanaOpenTelemetryKubernetesSRE

Scenario

An e-commerce platform experiences slow checkout and page timeouts during a flash sale. CPU usage spikes, but the root cause is unclear. The team already uses Prometheus and Grafana but lacks distributed tracing.

Symptoms

  • Grafana dashboard shows pod CPU >80%
  • Request latency P99 rises from 200ms to 2s
  • Users report checkout API timeouts
  • Some services return 502 errors

Diagnosis

1. Check Infrastructure

Query high-CPU pods with PromQL:

sum(rate(container_cpu_usage_seconds_total{namespace="production"}[5m])) by (pod)

Identifies checkout-service pods as hot spots.

2. Add OpenTelemetry Tracing

Install OpenTelemetry Collector exporting to Jaeger. Instrument services with OpenTelemetry SDK. Redeploy. In Jaeger UI, find that checkout-service traces show 90% of time spent in calls to payment-gateway.

3. Deep Dive

Check logs for payment-gateway:

kubectl logs -n production -l app=payment-gateway --tail=100

Reveals many connection refused errors — downstream bank API is down.

Commands

Enable Debug Logs Temporarily

kubectl set env deployment/checkout-service LOG_LEVEL=debug -n production

Hotfix: Circuit Breaker

Add config via ConfigMap:

# payment-gateway-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: payment-gateway-config
data:
  circuit-breaker: |
    timeout: 500ms
    maxFailures: 3

Apply:

kubectl create -f payment-gateway-config.yaml -n production --dry-run=client -o yaml | kubectl apply -f -

Verify Circuit Breaker

Check circuit_breaker_state metric in Prometheus. State should change to open after failures.

Risk Controls

  • Assess disk space before enabling debug logs; disable after diagnosis.
  • Test circuit breaker config on non-critical nodes first.
  • All changes via CI/CD pipeline, avoid direct production edits.

Rollback

Rollback Log Level

kubectl set env deployment/checkout-service LOG_LEVEL=info -n production

Rollback Circuit Breaker

Delete ConfigMap and restart:

kubectl delete configmap -n production payment-gateway-config
kubectl rollout restart deployment/payment-gateway -n production

Verification

  • Grafana latency panel: P99 <500ms
  • payment-gateway error rate zero
  • OpenTelemetry traces show circuit breaker blocking failed calls

When to Submit an OpsGlobal Ticket

  • If bank API issue is upstream and needs third-party coordination from OpsGlobal
  • If OpenTelemetry Collector setup is too complex or troubleshooting exceeds 2 hours
  • When cascading failures require architectural changes (e.g., retry queues)

Conclusion: Combining Prometheus (metrics), Grafana (visualization), and OpenTelemetry (tracing) dramatically reduces MTTR. Always implement resilience patterns like circuit breakers in production.

Use cases

Useful for teams handling Observability issues and needing a clear troubleshooting and delivery workflow.

Problem background

This post walks through a real-world incident, showing how Prometheus, Grafana, and OpenTelemetry work together to diagnose and resolve a performance issue. Includes commands, risk controls, rollback steps, and guidance on when to escalate to OpsGlobal.

Troubleshooting steps

Confirm impact and recent changes, collect logs, configuration and metrics, then apply fixes from low to high risk.

Command examples

Replace sample resource names with real values and store passwords, tokens and keys in environment variables.

Risks

Before production changes, confirm backups, access boundaries, change windows and rollback paths.

Rollback plan

Keep original configuration and release versions; roll back config, images or database changes if metrics degrade.

Deliverables

Root-cause notes, key commands, remediation steps, verification results and follow-up recommendations.

!

Need help with a similar technical issue?

If your servers, Kubernetes, Docker, CI/CD, databases or monitoring systems have similar issues, submit logs and config files for remote diagnosis.

Ticket Contact on WhatsApp Consult