Tempah Konsultasi Hantar Tiket

Prometheus, Grafana, dan OpenTelemetry: Panduan Amali Kebolehcerapan Produksi

Artikel ini membincangkan senario insiden dunia sebenar, bagaimana Prometheus, Grafana, dan OpenTelemetry bekerjasama untuk mendiagnosis dan menyelesaikan isu prestasi. Termasuk arahan, kawalan risiko, langkah pengembalian, serta bila perlu melaporkan kepada OpsGlobal.

Prometheus, Grafana, dan OpenTelemetry: Panduan Amali Kebolehcerapan Produksi
Observability 6min 40 paparan 2026-07-18
PrometheusGrafanaOpenTelemetryKubernetesSRE

Senario

Platform e-dagang mengalami kelembapan checkout dan tamat masa halaman semasa jualan kilat. Penggunaan CPU meningkat tetapi punca utama tidak jelas. Pasukan sudah menggunakan Prometheus dan Grafana tetapi kekurangan penjejakan taburan.

Gejala

  • Papan pemuka Grafana menunjukkan CPU pod >80%
  • Latensi permintaan P99 meningkat daripada 200ms ke 2s
  • Pengguna melaporkan tamat masa API checkout
  • Sebahagian perkhidmatan memulangkan ralat 502

Diagnosis

1. Periksa Infrastruktur

Cari pod dengan CPU tinggi menggunakan PromQL:

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

Mengenal pasti pod checkout-service sebagai punca.

2. Tambah Penjejakan OpenTelemetry

Pasang OpenTelemetry Collector dan eksport ke Jaeger. Instrumen perkhidmatan dengan SDK OpenTelemetry. Gunakan semula. Dalam UI Jaeger, jejak checkout-service menunjukkan 90% masa dihabiskan dalam panggilan ke payment-gateway.

3. Diagnostik Mendalam

Semak log untuk payment-gateway:

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

Mendedahkan banyak ralat connection refused — API bank hiliran tidak berfungsi.

Arahan

Dayakan Log Debug Sementara

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

Pembaikian Segera: Pemutus Litar

Tambah konfigurasi melalui ConfigMap:

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

Guna:

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

Sahkan Pemutus Litar

Periksa metrik circuit_breaker_state dalam Prometheus. Keadaan harus bertukar ke open selepas kegagalan.

Kawalan Risiko

  • Nilai ruang cakera sebelum dayakan log debug; matikan selepas diagnosis.
  • Uji konfigurasi pemutus litar pada nod bukan kritikal dahulu.
  • Semua perubahan melalui saluran paip CI/CD, elakkan suntingan langsung pada produksi.

Pengembalian

Kembalikan Tahap Log

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

Kembalikan Pemutus Litar

Padam ConfigMap dan mula semula:

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

Pengesahan

  • Panel latensi Grafana: P99 <500ms
  • Kadar ralat payment-gateway sifar
  • Jejak OpenTelemetry menunjukkan pemutus litar menghalang panggilan yang gagal

Bila Laporkan kepada OpsGlobal

  • Jika isu bank API adalah hiliran dan memerlukan koordinasi pihak ketiga oleh OpsGlobal
  • Jika penyediaan OpenTelemetry Collector terlalu kompleks atau penyelesaian masalah melebihi 2 jam
  • Apabila kegagalan berantai memerlukan perubahan seni bina (contohnya, giliran ulangan)

Kesimpulan: Gabungan Prometheus (metrik), Grafana (visualisasi), dan OpenTelemetry (penjejakan) mengurangkan MTTR secara mendadak. Sentiasa laksanakan corak ketahanan seperti pemutus litar dalam produksi.

Senario Penggunaan

Sesuai untuk pasukan yang menyelesaikan isu Observability dan memerlukan aliran kerja yang jelas.

Latar Belakang Masalah

Artikel ini membincangkan senario insiden dunia sebenar, bagaimana Prometheus, Grafana, dan OpenTelemetry bekerjasama untuk mendiagnosis dan menyelesaikan isu prestasi. Termasuk arahan, kawalan risiko, langkah pengembalian, serta bila perlu melaporkan kepada OpsGlobal.

Langkah Penyelesaian

Sahkan impak dan perubahan terkini, kumpul log, konfigurasi dan metrik, kemudian baiki mengikut risiko.

Contoh Arahan

Gantikan contoh dengan nama sumber sebenar dan simpan kata laluan, token atau kunci dalam pembolehubah persekitaran.

Risiko

Sebelum operasi produksi, semak sandaran, akses, tetingkap perubahan dan pelan rollback.

Pelan Rollback

Simpan konfigurasi dan versi asal; rollback konfigurasi, imej atau perubahan pangkalan data jika metrik tidak normal.

Senarai Serahan

Rekod punca isu, arahan penting, langkah pembaikan, hasil pengesahan dan cadangan susulan.

!

Perlu bantuan isu teknikal serupa?

Jika pelayan, Kubernetes, Docker, CI/CD, pangkalan data atau pemantauan anda bermasalah, hantar log dan konfigurasi untuk diagnosis jauh.

Tiket Hubungi WhatsApp Konsultasi