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-gatewaysifar - 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.