עצור את ספאם ההתראות: קווי בסיס של ML למדדים שלך

Prometheus אוסף אלפי מדדים. התראות מוגדרות. אבל המהנדס התורן שלך מקבל 200 התראות בלילה — 190 מהן חיוביות שגויות, והאירוע האמיתי הולך לאיבוד ברעש. עם ניסיון של למעלה מ-5 שנים ב-DevOps, אנו מציעים גישת AIOps לזיהוי חריגות שפותר בדיוק את הבעיה הזו. במקום ספים קבועים, אנו משתמשים בהתראות ML שמתאימות את עצמן. אנו מתמחים בזיהוי חריגות במדדים להפחתת רעש. גישה זו מוכחת כמפחיתה חיוביות שגויות ב-80-90% — פי 5 יותר יעילה מספים סטטיים.

למה התראות סף קלאסיות לא עובדות

מצב טיפוסי: ב-prometheus.rules.yml יש { "description": "HTTP latency anomaly detection", "analysis_config": { "bucket_span": "5m", "detectors": [ { "detector_description": "mean(response_time) by service", "function": "mean", "field_name": "response_time", "partition_field_name": "service" } ] }, "data_description": { "time_field": "@timestamp" } } . זה עובד ל-MVP. לייצור עם עבודות אצווה ליליות, קמפיינים שיווקיים ושיאים עונתיים — זה לא. Alert Manager מציף את התורן בכל שיא של יום שישי, הצוות משתיק התראות דרך inhibit_rules, ובסופו של דבר שירות מתדרדר אמיתי נשאר ללא השגחה במשך 40 דקות.

מקרה נפוץ שני — מדדי מסד נתונים. pg_stat_activity מציג את מספר החיבורים. סף מוגדר על 80. אבל מספר החיבורים הרגיל במוצאי שבת הוא 5, ובשישי בשעה 18:00 — 200. סף אחד לא מתאים לשניהם. AIOps פותר זאת אוטומטית על ידי בניית קווי בסיס דינמיים נפרדים לכל קטע זמן.

אילו מדדים כדאי לזהות עם AIOps?

• מדדים עם עונתיות חזקה (מדדים עונתיים): HTTP RPS, מספר משתמשים מקוונים, גודל תור משימות.
• מדדים עם שונות גבוהה אך התנהגות צפויה: זמן השהיה לכל נקודת קצה, שיעור שגיאות.
• מדדים רגישים לשעה ביום: CPU, זיכרון, שימוש לכל שירות.

אל תשתמשו בזיהוי חריגות עבור מדדים עם מגמות ליניאריות (למשל, קצב מילוי דיסק) — השתמשו ב-predict_linear() שם.

כלים וגישות

Prometheus + תוספי ML של Grafana. Grafana תומך ב-predict_linear() ישירות ב-PromQL, אבל לזיהוי חריגות אמיתי זה לא מספיק. לזיהוי חריגות ב-Prometheus, מומלץ השילוב הזה. אפשרות רצינית היא Grafana ML (לשעבר תוסף grafana-ml, כיום חלק מ-Grafana Cloud), שבונה קו בסיס מנתונים היסטוריים ומזהה סטיות. עבור self-hosted — Prophet של Meta דרך grafana-prophet-datasource או שירות מותאם אישית.

Elastic Anomaly Detection (חלק מ-Elastic Stack Platinum/Enterprise). מוגדר דרך PUT _ml/anomaly_detectors/<job_id>:

{
  "description": "HTTP latency anomaly detection",
  "analysis_config": {
    "bucket_span": "5m",
    "detectors": [
      {
        "detector_description": "mean(response_time) by service",
        "function": "mean",
        "field_name": "response_time",
        "partition_field_name": "service"
      }
    ]
  },
  "data_description": {
    "time_field": "@timestamp"
  }
}

גלאי כזה מתחשב אוטומטית בתבניות יומיות ושבועיות — influencers עוזרים לזהות איזה שירות ספציפי חריג.

Datadog Anomaly Monitor — המהיר ביותר להקמה עבור צוותים שכבר משתמשים ב-Datadog. סוג ההתראה anomaly בתצורת המוניטור תומך בשלושה אלגוריתמים: basic (ממוצעים נעים), agile (SARIMA לנתונים עונתיים), robust (עמיד בפני חריגים). בפועל, עבור רוב מדדי ה-HTTP, agile עם seasonality: weekly עובד היטב.

מערך מותאם אישית על Python + InfluxDB. אם אתם רוצים שליטה מלאה — Prophet או statsmodels SARIMAX: סקריפט קורא מ-InfluxDB, מחשב רווח סמך, כותב את התוצאה חזרה כמדד נפרד. Alertmanager מגיב כשערכים יוצאים מהרווח. זה דורש עבודה רבה אבל נותן גמישות מרבית למדדים ספציפיים.

מאמר ויקיפדיה על זיהוי חריגות והתיעוד הרשמי של Elastic מאשרים תצורות אלו.

איך אנו מיישמים AIOps: הניסיון שלנו

ביצענו 30+ יישומים של זיהוי חריגות לחברות בגדלים שונים. בפרויקט אחד, הפחתנו חיוביות שגויות מ-200 ל-15 ביום, מה שאיפשר לצוות SRE להתמקד באירועים אמיתיים. חיסכון בעלות אירועים לאחר היישום הגיע עד 40% מזמן התורנות. בפרויקט אחד, אנו מעריכים שההפסדים הכספיים מהשבתות הופחתו ב-$20,000 בשנה. בפרויקט אחר, חסכנו $12,000 בשעות נוספות תורנות בתוך שישה חודשים. המהנדסים שלנו מוסמכים ב-Kubernetes, AWS ו-Prometheus, מה שמבטיח תוצאות איכותיות. לצוות שלנו יש ניסיון משולב של 7+ שנים ב-DevOps. עם 5+ שנים בשוק, אנו מביאים מומחיות עמוקה בניטור DevOps.

תהליך: שלבים ולוחות זמנים

1. ביקורת על התראות ומדדים קיימים — ניתוח יחס רעש לאות על פני 30 יום, זיהוי מועמדים לזיהוי חריגות.
2. בחירת כלי וארכיטקטורה — בהתבסס על המערך והתקציב שלכם.
3. הגדרת גלאים + קו בסיס — כוונון פרמטרים, תצורה.
4. ריצת ניסיון וכיול — שבועיים של פעילות מקבילה, הערכת איכות.
5. תיעוד והדרכת צוות — runbook, אסטרטגיית התראות, הדרכה.

סה"כ: 2 עד 4 שבועות תלוי במספר השירותים ומורכבות המדדים. עלות מחושבת לאחר הביקורת.

מה כלול

• ביקורת על מערכת הניטור וההתראות הקיימת.
• בחירת כלי זיהוי חריגות למערך שלכם.
• הגדרת גלאים תוך התחשבות בעונתיות ומגמות.
• תקופת ריצת ניסיון עם כיול למזעור חיוביות שגויות.
• תיעוד: runbook התראות, תיאורי תקופות קו בסיס, הוראות לתורנים.
• הדרכת צוות (1-2 ימים).
• תמיכה המשכית למשך חודש.

קבלו ייעוץ: צרו קשר לביקורת על התשתית שלכם. פנו אלינו, ונעריך את הפרויקט במפתח מלא.