Menguasai OpenTelemetry, Prometheus, dan Grafana: Panduan Penyelesaian Masalah Praktikal untuk SRE Kubernetes

Senario

Kluster Kubernetes anda menjalankan Prometheus dan Grafana. Pasukan aplikasi telah membolehkan OpenTelemetry untuk menghantar jejak dan metrik melalui Pengumpul OpenTelemetry ke titik akhir penulisan jauh Prometheus. Tiba-tiba, papan pemuka Grafana untuk beberapa perkhidmatan mula menunjukkan jurang, penggunaan CPU dan memori Prometheus melonjak, dan anda menghadapi risiko OOM. Pada masa yang sama, log Pengumpul menunjukkan ralat penulisan jauh.

Simptom

• Panel Grafana menunjukkan "Tiada data" atau jurang berselang-seli.
• Memori pod Prometheus terus meningkat dan mungkin mencapai had.
• Pengumpul OpenTelemetry membalas dengan HTTP 500 atau 429.
• Metrik up menunjukkan sasaran tidak dapat dicapai, atau prometheus_remote_storage_queue_length terus meningkat.

Diagnosis

1. Periksa Sasaran Prometheus

Pertama, sahkan bahawa Prometheus masih mengikis semua sasaran. Lawati halaman UI Prometheus Targets atau gunakan baris arahan:

kubectl exec -n monitoring prometheus-0 -- wget -qO- http://localhost:9090/api/v1/targets | jq '.data.activeTargets[] | {scrapeUrl, health, lastError}'

Cari sasaran yang menjadi down. Punca biasa termasuk perubahan label yang memutuskan pemilih atau perubahan port pengeksport.

2. Periksa Konfigurasi Penulisan Jauh

Sahkan bahawa konfigurasi penulisan jauh Prometheus betul. Periksa fail konfigurasi:

kubectl exec -n monitoring prometheus-0 -- cat /etc/prometheus/prometheus.yml | grep -A 20 'remote_write'

Pastikan url menunjuk ke titik akhir Pengumpul OpenTelemetry dan kelayakan (jika ada) tidak tamat tempoh.

3. Periksa Log Pengumpul OpenTelemetry

Tail log Pengumpul untuk mencari ralat tertentu:

kubectl logs -n otel-collector -l app=otel-collector --tail=100

Ralat biasa termasuk:

• 416 Requested Range Not Satisfiable — siri masa bergerak ke belakang.
• 429 Too Many Requests — had tulis melebihi; anda memerlukan had kadar atau penskalaan.
• 500 Internal Server Error — isu dalaman Pengumpul, kemungkinan salah konfigurasi pengeksport.

4. Periksa Letupan Kardinaliti

Kardinaliti tinggi menyebabkan tekanan memori Prometheus. Gunakan PromQL untuk mengesan:

kubectl exec -n monitoring prometheus-0 -- wget -qO- 'http://localhost:9090/api/v1/query?query=topk(10,%20count%20by%20(__name__)(%7B__name__%3D~%22.%2B%22%7D))'

Atau jalankan topk(10, count by (__name__)({__name__=~".+"})) di UI Web.

Periksa juga jika sebarang nilai label meletup, seperti url atau request_id:

count(count by (url) (http_requests_total)) > 1000

5. Sahkan Sama Ada Pengumpul Kehilangan Metrik

Dayakan pengeksport debug pada Pengumpul untuk menghantar data ke stdout dan perhatikan jika metrik tiba:

exporters:
  debug:
    verbosity: detailed
service:
  pipelines:
    metrics:
      exporters: [debug, prometheus]

Arahan dan Tindakan

Sandarkan Konfigurasi Semasa

kubectl get configmap -n monitoring prometheus-config -o yaml > prometheus-config-backup.yaml
kubectl get configmap -n otel-collector otel-collector-config -o yaml > collector-config-backup.yaml

Gunakan Perubahan Konfigurasi dengan Selamat

Sentiasa gunakan --dry-run=client dan --dry-run=server terlebih dahulu:

kubectl apply -f prometheus-config-backup.yaml --dry-run=client -o yaml
kubectl apply -f prometheus-config-backup.yaml --dry-run=server

Laraskan metrics_relabel_configs untuk Mengehadkan Kardinaliti

Dalam konfigurasi Prometheus, tambah peraturan relabel untuk membuang label berkardinaliti tinggi daripada metrik yang dihantar ke penulisan jauh:

remote_write:
  - url: http://otel-collector.otel-collector:4318/api/v1/metrics
    write_relabel_configs:
      - source_labels: [__name__]
        regex: 'http_requests_total'
        action: keep
      - source_labels: [request_id]
        regex: '.*'
        action: drop

Muat Semula Konfigurasi Prometheus

kubectl exec -n monitoring prometheus-0 -- kill -HUP 1

Skala Pengumpul OpenTelemetry

Jika Pengumpul menjadi hambatan, tambah bilangan replika dan sumber:

kubectl scale deployment/otel-collector --replicas=3 -n otel-collector
kubectl set resources deployment/otel-collector -n otel-collector --requests='cpu=500m,memory=1Gi' --limits='cpu=1,memory=2Gi'

Kawalan Risiko

• Jangan ubah suai konfigurasi pengeluaran tanpa membuat sandaran.
• Salah konfigurasi write_relabel_configs boleh senyap membuang semua data; sentiasa uji dalam persekitaran staging dahulu.
• Menjalankan kill -HUP memuat semula konfigurasi tanpa memulakan semula proses. Jika konfigurasi tidak sah, Prometheus mungkin gagal dimuat semula; gunakan promtool check config sebelum digunakan.
• Membuang/mengekalkan label pada skala besar boleh menghalang Prometheus daripada menemui sasaran; nilai kesan terlebih dahulu.
• Menskala Pengumpul mungkin meningkatkan kos; laraskan berdasarkan penggunaan sumber sebenar.

Pelan Gulung Balik

1. Pulihkan sandaran konfigurasi:

kubectl apply -f prometheus-config-backup.yaml
kubectl apply -f collector-config-backup.yaml

1. Muat semula Prometheus untuk menggunakan konfigurasi.

2. Jika perubahan Pengumpul menyebabkan isu, gulung balik Deployment ke versi imej sebelumnya:

kubectl rollout undo deployment/otel-collector -n otel-collector

1. Sahkan semua Pod sihat:

kubectl get pods -n monitoring -n otel-collector

Pengesahan

Sahkan Prometheus Menerima Penulisan Jauh

Periksa metrik penulisan jauh:

prometheus_remote_storage_succeeded_samples_total - prometheus_remote_storage_failed_samples_total

Atau query metrik up:

up

Sahkan Metrik OpenTelemetry Sampai ke Prometheus

Andaikan aplikasi mendedahkan http_requests_total, buat panel Grafana dan query:

sum(rate(http_requests_total[5m])) by (service)

Sahkan Kardinaliti Telah Menurun

Jalankan semula query kardinaliti dan pastikan bilangan nilai label berada dalam julat yang munasabah.

Periksa Penggunaan Memori

Perhatikan memori kontena Prometheus untuk mengesahkan ia tidak lagi meningkat.

Bila Perlu Hantar Tiket OpsGlobal

• Jika anda tidak dapat memulihkan data selepas setengah jam langkah di atas.
• Prometheus berulang kali dibunuh OOM dan memerlukan penyelesaian sharding atau penyimpanan jangka panjang.
• Pengumpul OpenTelemetry crash-loop dan anda tidak dapat mengesan isu konfigurasi.
• Anda memerlukan bantuan pakar untuk mereka bentuk seni bina pemerhatian berskala besar untuk mengelakkan masalah serupa.

OpsGlobal menyediakan sokongan SRE 24×7. Pakar kami boleh mengakses kluster anda dari jauh, mendiagnosis dan menyelesaikan isu kompleks Prometheus, Grafana, dan OpenTelemetry dengan cepat, memastikan timbunan pemerhatian anda stabil dan boleh dipercayai.