تطوير الويب

مراقبة Kubernetes مع kube-prometheus-stack خطوة بخطوة

1 min de lecture

مقال مرتبط · هذا الدليل جزء من سلسلة Kubernetes منزلي على Proxmox VE. الدليل السابق: Argo CD GitOps. الدليل التالي: Velero backups.

دون مراقبة، نُشَغِّل عنقود Kubernetes معصوبَي العينين: نتعلّم أنّ عقدة مُشبَعة حين يشكو المستخدمون، نكتشف أنّ pod في دوران بعد ساعات من إعادة التشغيل، لا نعرف إن مرّت النسخ الاحتياطية حقًّا الليلة الماضية. chart Helm kube-prometheus-stack يجمع في تثبيت متماسك Prometheus، Alertmanager، Grafana، node-exporter، kube-state-metrics ومُشَغِّل Prometheus. النسخة 84.5.0 الصادرة في مايو 2026 تُسَلِّم Prometheus 3.0، Grafana 11.7، ومُشَغِّل Prometheus 0.90. يُثَبِّت هذا الدليل الـ chart، يتحقّق من وصول المقاييس، يُهَيِّئ أولى قواعد التنبيه، ويكشف Grafana عبر Ingress مع توثيق.

الخطوة 1 — تحضير namespace وvolumes

Prometheus وAlertmanager وGrafana تُديم حالتها على القرص. مع Rook-Ceph في مكانه (الدليل السابق)، لدينا StorageClass rook-ceph-block افتراضي. لا حاجة لـ volume يدوي: الـ chart يُوفِّر ما يلزم.

kubectl create namespace monitoring

# تحقّق من أنّ StorageClass الافتراضي هو rook-ceph-block
kubectl get sc
# DEFAULT يجب أن يكون (true) على rook-ceph-block

StorageClass افتراضي نشط يتفادى تحديد storageClassName في قيم Helm. إن تعدّدت الفئات المُعَلَّمة افتراضية، يختار Kubernetes عشوائيًّا. الأمر kubectl patch sc يُتيح التبديل عند الحاجة.

الخطوة 2 — تثبيت kube-prometheus-stack عبر Helm

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

cat > values.yaml <

الـ chart ينشر نحو 25 موردًا: Prometheus، Alertmanager، Grafana، DaemonSet node-exporter، kube-state-metrics، مُشَغِّل Prometheus، إضافة إلى عشرين ServiceMonitor وPrometheusRule جاهزة. تحقّق بـ kubectl get pods -n monitoring.

الخطوة 3 — الوصول إلى Grafana واستكشاف اللوحات المُسَلَّمة

kubectl -n monitoring port-forward svc/kube-prometheus-stack-grafana 3000:80 &
# افتح http://localhost:3000
# Login: admin
# Password: ChangeMeQuickly (غيِّرها فور الدخول)

في أوّل تسجيل دخول، نكتشف نحو ثلاثين لوحة مُهَيَّأة سلفًا في الشريط الجانبي الأيسر: Kubernetes / Compute Resources / Cluster، Kubernetes / Networking / Cluster، Node Exporter / Nodes، Kubernetes / API server وأخرى. رؤية رسوم مأهولة ببيانات حقيقية يُؤكِّد أنّ Prometheus يحصد المُصدِّرات وأنّ Grafana يقرأ datasource Prometheus المُهَيَّأ افتراضيًّا.

الخطوة 4 — التحقّق من ServiceMonitor لـ Cilium وRook

المكوّنات المُثَبَّتة في الأدلّة السابقة (Cilium، Rook-Ceph) تكشف مقاييس Prometheus. مُشَغِّل Prometheus يكتشفها تلقائيًّا عبر ServiceMonitor، شريطة وجودها.

kubectl get servicemonitor -A
# يجب إدراج cilium، hubble، rook-ceph-mgr، rook-ceph-exporter

# إن كان مفقودًا، فعِّله في Helm Cilium:
# helm upgrade cilium ... --set prometheus.enabled=true \
#   --set operator.prometheus.enabled=true \
#   --set hubble.metrics.enabled="{dns,drop,tcp,flow,icmp,http}"

رؤية ServiceMonitor يُتيح فتح لوحات خاصّة في Grafana (Cilium ID 16611، Ceph Cluster ID 2842). نحصل على رؤية مفصَّلة لإنتاجية eBPF لكلّ عقدة، عدد كائنات Ceph لكلّ pool، الـ PGs في طور التوضع.

الخطوة 5 — كتابة أوّل قاعدة تنبيه مخصَّصة

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: app-error-rate
  namespace: monitoring
  labels:
    release: kube-prometheus-stack
spec:
  groups:
  - name: app.errors
    rules:
    - alert: HighErrorRate
      expr: |
        sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
        / sum(rate(http_requests_total[5m])) by (service) > 0.05
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "Service {{ $labels.service }} returns >5% errors"
        description: "Error rate is {{ $value | humanizePercentage }} over 5 minutes"
kubectl apply -f app-error-rate.yaml

# تحقّق من تحميل القاعدة
kubectl -n monitoring exec -it kube-prometheus-stack-prometheus-0 \
  -c prometheus -- promtool check rules /etc/prometheus/rules/*.yaml | head

قاعدة تظهر في واجهة Prometheus (Status ← Rules) تُؤكِّد دمج مُشَغِّل Prometheus لها. اللصاقة release: kube-prometheus-stack أساسية: تُعلن القاعدة لـ Prometheus الرئيسي، دونها يُتجاهَل المنفست بصمت.

الخطوة 6 — تهيئة Alertmanager لتنبيه القنوات الصحيحة

apiVersion: v1
kind: Secret
metadata:
  name: alertmanager-kube-prometheus-stack-alertmanager
  namespace: monitoring
stringData:
  alertmanager.yaml: |
    route:
      receiver: discord
      group_by: ['alertname', 'severity']
      group_wait: 30s
      group_interval: 5m
      repeat_interval: 4h
      routes:
      - match:
          severity: critical
        receiver: discord
        repeat_interval: 30m
    receivers:
    - name: discord
      webhook_configs:
      - url: https://discord.com/api/webhooks/...
        send_resolved: true

بعد kubectl apply، Alertmanager يُعيد تحميل إعداده في ثوانٍ (المُشَغِّل يُراقب الـ Secret). التنبيهات الحرجة تصل كلّ 30 دقيقة، التنبيهات warning كلّ 4 ساعات، ممّا يتفادى الرشقات ويُبقي إشارة حيّة.

الخطوة 7 — كشف Grafana عبر Ingress مع TLS

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: grafana
  namespace: monitoring
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod-dns
spec:
  ingressClassName: cilium
  tls:
  - hosts:
    - grafana.exemple.lan
    secretName: grafana-tls
  rules:
  - host: grafana.exemple.lan
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: kube-prometheus-stack-grafana
            port:
              number: 80

بعد إصدار الشهادة (مرئية بـ kubectl get certificate -n monitoring)، Grafana يستجيب HTTPS على الـ URL المختار. نفس الآلية تنطبق على المكوّنات الأخرى (Argo CD، Hubble UI، dashboard Ceph)، ممّا يُوَحِّد منصّة متماسكة.

الخطوة 8 — التحقّق من جمع المقاييس التطبيقية

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: myapp
  namespace: demo
  labels:
    release: kube-prometheus-stack
spec:
  selector:
    matchLabels:
      app: myapp
  endpoints:
  - port: metrics
    interval: 30s
    path: /metrics
kubectl apply -f myapp-servicemonitor.yaml
# واجهة Prometheus: Status ← Targets
# myapp يجب أن يظهر بحالة UP

رؤية target بحالة UP في Prometheus يُؤكِّد أنّ المقاييس التطبيقية تُحصد كلّ 30 ثانية. تصير فورًا قابلة للاستعلام بـ PromQL واستعمالها في لوحات Grafana أو قواعد تنبيه.

الخطوة 9 — التحقّق من الاحتفاظ واستهلاك القرص

kubectl -n monitoring exec kube-prometheus-stack-prometheus-0 -c prometheus \
  -- du -sh /prometheus
# يجب عرض حجم ينمو ثم يستقرّ بين 25 و30 جيغا

# إن اقترب الاستهلاك من السقف، وسِّع PVC
kubectl -n monitoring patch pvc \
  prometheus-kube-prometheus-stack-prometheus-db-prometheus-kube-prometheus-stack-prometheus-0 \
  --patch '{"spec":{"resources":{"requests":{"storage":"100Gi"}}}}'

الـ PVC قابل للتوسيع لأنّ allowVolumeExpansion: true مُعَرَّف على StorageClass Rook-Ceph. التوسيع online، دون انقطاع. لاحتفاظ طويل (سنة من المقاييس)، خَطِّط لـ Thanos أو VictoriaMetrics الذين يُصدِّرون الكتل إلى objectstore S3 (bucket Rook المُنشَأ في الدليل السابق يفي بالغرض).

أخطاء شائعة وحلولها

العَرَض السبب الحلّ
pod Prometheus يبقى في CrashLoopBackOff PVC غير مربوط، StorageClass مفقود افحص kubectl get pvc -n monitoring وStorageClass
Grafana يعرض "No data" Datasource سيّء أو network policy تحظر افحص في Grafana Configuration ← Data Sources
ServiceMonitor مُتَجاهَل لصاقة release: kube-prometheus-stack ناقصة أضف اللصاقة على ServiceMonitor وPrometheusRule
Alertmanager لا يُنبِّه URL webhook خاطئ أو محجوب اختبر webhook بـ curl من pod في العنقود
ذاكرة Prometheus تنفجر سلاسل نشطة كثيرة، cardinality bomb حدِّد المقياس السيّء بـ topk(10, count by (__name__)({__name__=~".+"}))

لاستكمال المسار

الرصد في مكانه: مقاييس مجموعة، لوحات مقروءة، تنبيهات. اللبنة الأخيرة هي النسخ الاحتياطي: دون Velero، يمكن لخطأ تشغيل أن يُدمّر أسابيع من العمل. دليل نسخ احتياطي Kubernetes مع Velero يُفَصِّل النسخ المُجَدوَلة إلى bucket S3 Ceph وإجراء الاستعادة المُختَبَر. للنظرة العامّة، عُد إلى الدليل الرئيسي.

مصادر وتوثيق رسمي

  • kube-prometheus-stack chart: github.com/prometheus-community/helm-charts
  • توثيق Prometheus: prometheus.io/docs
  • توثيق Grafana: grafana.com/docs/grafana
  • توثيق Alertmanager: prometheus.io/docs/alerting
  • مواصفات PrometheusRule: prometheus-operator.dev/api
  • مواصفات ServiceMonitor: prometheus-operator.dev/design

الخطوة 10 — تنسيق قيم Helm في Argo CD

ملف values.yaml الذي يقود التثبيت بأهمّية المنفستات المُولَّدة. فقدانه يعني إعادة تذكّر الخيارات المختارة. الممارسة الموصى بها التزامه في مستودع GitOps وترك Argo CD يقود نشر kube-prometheus-stack عبر Application Helm.

mkdir -p clusters/homelab/infra/kube-prometheus-stack
cp values.yaml clusters/homelab/infra/kube-prometheus-stack/values.yaml

cat > clusters/homelab/infra/kube-prometheus-stack/application.yaml <

بعد مزامنة هذه Application، ترقية Prometheus تصير زيادة targetRevision في المنفست والتزام. Argo CD يُطبّق upgrade Helm معاملاتيًّا، وselfHeal يحمي من التعديلات خارج Git.

الخطوة 11 — مراقبة صحّة نسخ Velero (استباق)

الدليل التالي سينشر Velero للنسخ الاحتياطية. استباق مفيد: Velero يكشف مقاييس Prometheus تنغرس فورًا في الـ stack الذي ثبَّتناه. ServiceMonitor Velero يظهر تلقائيًّا حين نُثَبِّت Velero بعلم --set metrics.enabled=true. لوحات Grafana للاستيراد (ID 11055) تعرض: عدد النسخ يوميًّا، المدّة المتوسّطة، نسبة الإخفاق، حجم آخر snapshot لكلّ namespace.

تهيئة الآن PrometheusRule تُنبِّه إن أخفقت نسخة Velero أو لم تُشَغَّل لأكثر من 26 ساعة يتفادى المفاجأة السيّئة يوم نحتاج فعلًا إلى استعادة.

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: velero-backup-health
  namespace: monitoring
  labels:
    release: kube-prometheus-stack
spec:
  groups:
  - name: velero
    rules:
    - alert: VeleroBackupFailed
      expr: velero_backup_failure_total > 0
      for: 10m
      labels:
        severity: critical
    - alert: VeleroBackupTooOld
      expr: time() - velero_backup_last_successful_timestamp > 93600
      for: 30m
      labels:
        severity: critical

بهاتين القاعدتين، سنعرف بلا تأخير إن أخفقت نسخة ليلية أو إن توقّف Velero. هذا نوع الإشارة التي لا نملكها طبيعيًّا ونندم على غيابها يوم الحادث.

الخطوة 12 — فهم كلفة الذاكرة وCPU للـ stack

kube-prometheus-stack ليس خفيفًا، ومن المفيد قياس استهلاكه الفعلي لتقدير العنقود. على homelab بست عقد مع 30 ServiceMonitor نشطًا و15 يومًا احتفاظ، الأوامر العامّة المرصودة في مايو 2026: Prometheus يستهلك 1.5 إلى 2.5 جيغا RSS و0.3 إلى 0.6 vCPU في المتوسّط؛ Grafana يستهلك 200 ميغا RSS و0.05 vCPU في الراحة؛ Alertmanager 100 ميغا؛ node-exporter 30 إلى 50 ميغا لكلّ عقدة؛ kube-state-metrics نحو 200 ميغا على عنقود بأقلّ من 500 pod.

المكوّن الأسرع نموًّا هو Prometheus، ونموّه تهيمن عليه cardinality السلاسل أكثر من عدد المقاييس. مقياس بلصاقة request_id فريد لكلّ طلب يُولِّد ملايين السلاسل النشطة في ساعات قليلة ويُفَجِّر الذاكرة. المُصدِّرات جيّدة التصميم (node-exporter، kube-state-metrics) لا تُسبّب هذه المشكلة؛ المقاييس التطبيقية المكتوبة بسرعة نعم.

الزرّ المعروف لهذه الحالات هو storage.tsdb.head-chunks-write-queue-size والـ profiler المدمج المتاح عبر /debug/pprof/ على pod Prometheus. لكنّ الحلّ الحقيقي مراجعة المقاييس التطبيقية قبل السماح بدخولها للإنتاج: إدراج السلاسل عالية cardinality في Prometheus لتحديد المُذنبين قبل أن يصيروا مشكلة تشغيلية.

المهارة التي تُؤتي ثمارها على المدى البعيد المراجعة المنتظمة للمقاييس النشطة وحذف ما لا يخدم. عنقود سليم يُلاحظ ما يجب، فقط ما يجب. هذا الانضباط في النظافة الميتريّة يُكتَسب في أشهر قليلة ويفصل بين عنقود نُراقبه بسلاسة وعنقود يُراقب نفسه لدرجة استهلاك كلّ موارده.

مقالات ذات صلة

Partager