הגדרת כללי התראה של Grafana להודעות אוטומטיות

אנו נתקלים בזה כל הזמן: כאשר יש התראות רבות, המהנדס התורן מפסיק להגיב אליהן. עייפות התראות אינה מטאפורה. מצב אמיתי: 300 התראות פעילות בערוץ Slack, 280 מתוכן הן נדנוד כרוני של NodeMemoryPressure יחיד על צומת עמוס ש"תמיד עושה את זה." כתוצאה מכך, התראה קריטית על קריסת מסד נתונים טובעת בתוך הרעש הזה. הניסיון שלנו מראה: הגדרת התראות נכונה חוסכת עד 70% מזמן התורן ומבטלת שיחות לילה שווא.

Unified Alerting לעומת Legacy

מאז Grafana 9 ומעלה, הגישה הקלאסית עם כללי Alertmanager ב-Prometheus והתראות דרך Grafana פוצלה—כיום קיים Grafana Unified Alerting, המנהל התראות ממקורות נתונים מרובים (Prometheus, Loki, InfluxDB) בממשק אחד. זה נוח אך יוצר בלבול: אם לפרויקט כבר יש Alertmanager מוגדר עם routes, inhibit rules ו-silences, שכפול הלוגיקה ב-Grafana Alerting מיותר.

החוק פשוט: אם Prometheus Alertmanager הוא כבר מרכז הניתוב, השתמשו ב-Grafana רק להצגת התראות, כתבו כללים ב-PrometheusRule CRD (עבור Kubernetes) או ב-prometheus.yml. אם Grafana היא נקודת הכניסה היחידה ואין Alertmanager נפרד, השתמשו ב-Grafana Unified Alerting עם contact points.

כיצד לתכנן כללים ללא נדנוד

נדנוד—התראה שמשנה מצב כל הזמן מ-firing ל-resolved ובחזרה. מטפלים בזה בשתי דרכים.

ראשונה—פרמטר for בכלל. for: 5m פירושו שהתנאי חייב להיות נכון ברציפות למשך 5 דקות לפני שליחת התראה. עבור התראות CPU זה קריטי: קפיצה של 10 שניות לא צריכה להעיר מהנדס בלילה.

---
groups:
  - name: node.alerts
    rules:
      - alert: NodeCPUHighUsage
        expr: |
          ( 1 - avg by (instance) ( rate(node_cpu_seconds_total{mode="idle"}[5m]) ) ) > 0.85
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "CPU > 85% на {{ $labels.instance }} в течение 10 минут"
          runbook_url: "https://wiki.example.com/runbooks/node-cpu"

שנייה—ספים נכונים. 85% CPU—אזהרה, 95%—קריטי. אל תשתמשו בהתראה אחת ב-80% עם severity=critical. יש צורך בהדרגתיות כדי שהתורן ידע: אפשר לבדוק אזהרה בבוקר, קריטי דורש שיחה מיידית.

מדוע נדנוד מסוכן?

נדנוד סותם ערוצי התראות, מפחית את תשומת הלב של התורן ומסתיר אירועים אמיתיים. עם שינויים תכופים במצב, המהנדס מפסיק לסמוך על ההתראות, מה שמוביל להחמצת אירועים קריטיים. פרמטר groups: - name: node.alerts rules: - alert: NodeCPUHighUsage expr: | ( 1 - avg by (instance) ( rate(node_cpu_seconds_total{mode="idle"}[5m]) ) ) > 0.85 for: 10m labels: severity: warning annotations: summary: "CPU > 85% на {{ $labels.instance }} в течение 10 минут" runbook_url: "https://wiki.example.com/runbooks/node-cpu" הוא הדרך היחידה לחתוך רעש מבלי לאבד רגישות.

כיצד להגדיר Inhibit Rules ב-Alertmanager?

ב-Alertmanager, הגדירו inhibit rules: אם for פעיל, כל ההתראות מאותו צומת (pod, service, container) מושתקות. אחרת, צומת אחד שנפל מוביל למפולת של 50 התראות ילד.

---
inhibit_rules:
  - source_match:
      alertname: NodeDown
    target_match_re:
      alertname: "Pod.*|Container.*|Service.*"
    equal:
      - instance

ניתוב: התראות קריטיות עוברות ל-PagerDuty עם מדיניות הסלמה, אזהרות עוברות לערוץ Slack #alerts-warning, מידע עובר לערוץ נפרד בעדיפות נמוכה. התורן רואה רק מה שדורש פעולה מיידית.

Contact Points ב-Grafana Unified Alerting

אם משתמשים ב-Grafana Alerting, הגדירו contact points באמצעות provisioning, לא דרך הממשק:

---
# /etc/grafana/provisioning/alerting/contact-points.yaml
apiVersion: 1
contactPoints:
  - orgId: 1
    name: pagerduty-critical
    receivers:
      - uid: pd-critical-uid
        type: pagerduty
        settings:
          integrationKey: "${PAGERDUTY_INTEGRATION_KEY}"
          severity: critical

סודות—דרך משתני סביבה, לא hardcoded. Grafana קורא אותם בעת ההפעלה.

השוואה בין Grafana Unified Alerting ו-Prometheus Alertmanager

קבוצות הערכה והשפעתן על ביצועים

כל כללי ההתראות מקובצים עם NodeDown. ברירת המחדל היא דקה אחת. עבור תשתית קריטית, אפשר להשתמש ב-30 שניות, אך זה מגביר עומס על Prometheus/Grafana. עבור 99% מהכללים, דקה אחת היא מרווח נורמלי. מהיר יותר נדרש רק עבור שירותים קריטיים ל-SLA עם RTO הדוק.

כיצד ליצור כלל התראה ב-Unified Alerting (שלב אחר שלב)

1. עברו ל-Alerting → Alert rules
2. לחצו על New alert rule
3. בחרו מקור נתונים (Prometheus, Loki)
4. כתבו ביטוי, הגדירו inhibit_rules: - source_match: alertname: NodeDown target_match_re: alertname: "Pod.*|Container.*|Service.*" equal: [instance] ו-severity
5. הגדירו annotations (summary, description, runbook_url)
6. בחרו contact point
7. שמרו

מה כלול בעבודת הגדרת ההתראות

• ביקורת על התראות ומקורות נתונים קיימים
• תכנון כללים עם קיבוץ וספים
• הגדרת contact points (Slack, PagerDuty, Telegram)
• יצירת inhibit rules וניתוב
• תיעוד Runbook עם קישורים אוטומטיים
• הדרכה לצוות התורן על טיפול בהתראות
• תמיכה לאחר השחרור למשך שבועיים

לוחות זמנים

ביקורת על התראות קיימות ותכנון מבנה נכון לוקחים יותר זמן מההגדרה עצמה. פרויקט טיפוסי: 2–4 ימים למלאי ותכנון כללים, 1–2 ימים ליישום ובדיקות, יום אחד לתיעוד Runbook עם קישורים מ-annotations של ההתראות.

המומחים בצוות שלנו מחזיקים בהסמכות Kubernetes ויש להם ניסיון תשתיתי של 5+ שנים. אנו מבטיחים הפחתת רעש התראות וניתוב ברור של הודעות. הזמינו הגדרת התראות turnkey—אנו נבצע ביקורת, תכנון ויישום של מערכת ההודעות. צרו קשר להערכת הפרויקט שלכם.