Observe Bercantum dengan Prometheus, Grafana, dan OpenTelemetry: Playbook Tindak Balas Insiden Praktikal

Senario

Platform Kubernetes anda menjalankan berpuluh-puluh perkhidmatan mikro, setiap satu menghasilkan metrik, log, dan jejak. Prometheus mengutip metrik, Grafana memvisualisasikannya, dan anda menggunakan pelbagai alat untuk jejak. Apabila insiden berlaku, anda sering perlu bertukar antara papan pemuka, pertanyaan log, dan paparan jejak, cuba menggabungkan apa yang berlaku. Ini adalah masalah silo pemerhatian yang klasik.

Dalam catatan ini, kami akan membina saluran pemerhatian yang bersatu menggunakan OpenTelemetry (OTel) untuk instrumentasi dan pengumpulan telemetri, Prometheus untuk penyimpanan metrik, dan Grafana untuk papan pemuka dan amaran. Kami juga akan menggunakan exemplar untuk melompat terus dari metrik ke jejak, mengurangkan masa purata untuk diagnosis (MTTD) secara drastik.

Gejala

• Latensi p99 pada perkhidmatan checkout melebihi 500ms, melanggar SLO.
• Kadar ralat untuk API pembayaran meningkat kepada 2%, dengan cepat menghabiskan belanjawan ralat.
• Papan pemuka CPU dan memori tidak menunjukkan anomali yang jelas, tetapi pengguna melaporkan kelembapan.
• Jurutera sokongan menyelaras cap masa secara manual merentas log dan jejak, membuang 30 minit setiap insiden.

Diagnosis

Mulakan dengan mencuba memandu masalah menggunakan PromQL. Pertanyaan histogram latensi untuk perkhidmatan checkout:

histogram_quantile(0.99,
  sum(rate(http_request_duration_seconds_bucket{service="checkout"}[5m])) by (le, route)
)

Ini mendedahkan laluan mana yang perlahan. Katakan /api/checkout adalah puncanya. Seterusnya, gunakan histogram yang sama untuk mencari exemplar—ID jejak yang mewakili. Dalam Grafana, dayakan exemplar dalam editor pertanyaan. Klik ikon berkilau pada titik data untuk membuka jejak yang berkaitan dalam backend jejak anda (mis., Tempo).

Jika anda belum mempunyai exemplar, anda masih boleh menyiasat jejak dengan menyelaras cap masa. Tetapi exemplar menjadikannya lebih pantas.

Arahan dan Konfigurasi

1. Menggunakan OpenTelemetry Collector

OTel Collector adalah gerbang yang tidak mengikat vendor. Buat ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: otel-collector-conf
  namespace: observability
data:
  otel-collector-config.yaml: |
    receivers:
      otlp:
        protocols:
          grpc:
          http:
    processors:
      batch:
        timeout: 5s
    exporters:
      prometheusremotewrite:
        endpoint: http://prometheus:9090/api/v1/write
        retry_on_failure:
          enabled: true
      otlp:
        endpoint: tempo:4317
        tls:
          insecure: true
    service:
      pipelines:
        metrics:
          receivers: [otlp]
          processors: [batch]
          exporters: [prometheusremotewrite]
        traces:
          receivers: [otlp]
          processors: [batch]
          exporters: [otlp]

Terapkan:

kubectl create ns observability
kubectl apply -f otel-collector.yaml

Juga gunakan collector sebagai DaemonSet untuk mengumpul metrik peringkat nod dan menerima OTLP dari perkhidmatan. Untuk kesederhanaan, kami menggunakan satu Deployment collector.

2. Instrumentasi Perkhidmatan dengan OpenTelemetry

Gunakan Operator OpenTelemetry untuk menyuntik instrumentasi automatik:

kubectl apply -f https://github.com/open-telemetry/opentelemetry-operator/releases/latest/download/opentelemetry-operator.yaml

Kemudian beri anotasi Deployment anda:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout
  namespace: prod
spec:
  template:
    metadata:
      annotations:
        instrumentation.opentelemetry.io/inject-java: "true"

Atau gunakan SDK secara manual. Untuk perkhidmatan Python:

from opentelemetry import trace
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor

trace.set_tracer_provider(TracerProvider())
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter(endpoint="otel-collector:4317"))
)

3. Konfigurasi Prometheus untuk Tulis Jauh

Dayakan penerima tulis jauh apabila memulakan Prometheus:

prometheus --web.enable-remote-write-receiver

Dalam konfigurasi Prometheus anda, pastikan anda mempunyai kerja mengikis untuk collector:

scrape_configs:
  - job_name: 'otel-collector'
    static_configs:
      - targets: ['otel-collector:8888']

4. Menyediakan Sumber Data dan Exemplar Grafana

Dalam Grafana, tambah Prometheus dan Tempo sebagai sumber data. Untuk Prometheus, dalam tetapan sumber data, dayakan "Exemplars" dan tambah medan terbitan dengan carian ID jejak:

• Medan TraceID: traceID
• Sumber data: Tempo
• Pertanyaan: {traceID="${__value.raw}"}

Kini anda boleh mengklik exemplar dalam mana-mana graf Prometheus untuk membuka jejak penuh.

5. Membina Papan Pemuka dan Amaran

Buat papan pemuka dengan panel untuk latensi, kadar ralat, dan kejenuhan (kaedah USE). Untuk amaran, tentukan peraturan Prometheus:

groups:
  - name: checkout-slo
    rules:
      - alert: CheckoutP99High
        expr: |
          histogram_quantile(0.99,
            sum(rate(http_request_duration_seconds_bucket{service="checkout"}[5m]))
            by (le, route)
          ) > 0.5
        for: 10m
        annotations:
          summary: "Perkhidmatan checkout latensi p99 tinggi"

Kawalan Risiko

• Canary collector: Mulakan dengan satu contoh dan pantau penggunaan sumbernya.
• Gunakan had sumber: Tetapkan had memori dan CPU pada collector untuk mengelakkan gangguan.
• Hadkan kadar tulis jauh: Gunakan queue_size dan retry_on_failure untuk mengelakkan banjir kepada Prometheus.
• Sandarkan konfigurasi: Simpan konfigurasi Prometheus, Grafana, dan OTel dalam Git sebelum pelancaran.
• Dayakan TLS untuk titik akhir OTLP dalam pengeluaran, gunakan sijil komersial atau mTLS.

Rollback

Jika collector OTel menyebabkan ketidakstabilan, anda boleh berbalik dengan cepat:

kubectl delete deployment otel-collector -n observability

Ini menghentikan semua pengambilan OTLP. Prometheus masih akan mengusik sasaran pengikisan sedia ada. Untuk instrumentasi automatik, keluarkan anotasi dari Deployment:

kubectl annotate deployment checkout instrumentation.opentelemetry.io/inject-java-

Untuk perubahan konfigurasi Prometheus, gunakan fail konfigurasi sebelumnya:

cp prometheus.yml.bak prometheus.yml
kill -HUP $(pidof prometheus)

Pengesahan

Selepas penggunaan, sahkan setiap lapisan:

1. Collector: Semak log untuk ralat: kubectl logs <otel-collector-pod>
2. Prometheus: Pertanyaan metrik yang hanya wujud melalui tulis jauh OTLP, contohnya otelcol_exporter_sent_metric_points.
3. Grafana: Buka papan pemuka dan sahkan data baru muncul.
4. Exemplar: Dalam Grafana Explore, jalankan pertanyaan PromQL, tuding pada titik data, dan klik "Exemplar" untuk membuka jejak.
5. Amaran: Gunakan curl untuk menjana latensi tinggi dan sahkan amaran berbunyi dalam 10 minit.

Bila Perlu Menghantar Tiket OpsGlobal

Anda patut mempertimbangkan untuk mengupah OpsGlobal jika:

• Pasukan anda menghabiskan lebih 10 jam seminggu untuk menyelenggara stack pemerhatian anda.
• Anda memerlukan instrumentasi lanjutan untuk perkhidmatan legacy yang tidak menyokong OTel secara asli.
• Anda mahu pemantauan 24/7 untuk infrastruktur pemerhatian anda sendiri.
• Anda hampir berpindah ke service mesh dan memerlukan bantuan untuk mengintegrasikan telemetri.

SRE jauh OpsGlobal boleh mereka bentuk, menggunakan, dan mengendalikan stack Prometheus, Grafana, dan OpenTelemetry anda, memastikan anda memenuhi SLO dan mendapat keterlihatan yang anda perlukan.