AIOps לניתוח לוגים: זיהוי אוטומטי של חריגות בלוגים

AIOps לניתוח לוגים: זיהוי אוטומטי של חריגות בלוגים

Elastic מדווחת על 100 GB של לוגים ביום, Alertmanager שותק — לא הוגדרו ספים. מהנדס התורן בודק את Kibana ידנית כל שעתיים. תקרית מתגלה 40 דקות לאחר שהמשתמשים כבר פנו לתמיכה. זהו תרחיש קלאסי: הרבה לוגים, מעט אותות, אנשים מתעייפים. מהנדסי DevOps ו-SRE המוסמכים שלנו מיישמים פתרונות AIOps סוהריים כך שתקבלו רק התראות שבאמת דורשות תגובה. אנו מעריכים את הפרויקט שלכם תוך יום אחד.

AIOps לניתוח לוגים אינו עוסק בהחלפת אנשים. הוא עוסק בסינון רעש: מתוך 10,000 אירועים בדקה, האוטומציה בוחרת את 3 שכדאי להסתכל עליהם כרגע. אנו מבטיחים הפחתה של 40% ב-MTTR בתוך החודש הראשון לאחר ההטמעה.

מה ML באמת עושה בלוגים — והיכן לא לסמוך עליו

גישות מודרניות לניתוח לוגים אוטומטי מתחלקות לשתי קטגוריות: מבוססות תבניות (ניתוח תבניות, אלגוריתם drain) ומבוססות embedding (וקטוריזציה באמצעות LLM או מודלים דמויי BERT). שתיהן עובדות, אבל בתרחישים שונים.

Drain3 היא ספריית Python המיישמת אלגוריתם עץ לניתוח לוגים. היא מקבלת שורת לוג גולמית ומפיקה תבנית: Connection to <IP>:<PORT> failed after <NUM> retries. זה שימושי לקיבוץ: אלף שורות על כתובות IP שונות הופכות לתבנית אחת עם מונה. חריגה מתרחשת כאשר המונה עבור תבנית מסוימת מזנק או שמופיעה תבנית חדשה שלא הייתה קיימת קודם.

from drain3 import TemplateMiner
from drain3.template_miner_config import TemplateMinerConfig

config = TemplateMinerConfig()
config.load("drain3.ini")
template_miner = TemplateMiner(config=config)

with open("app.log") as f:
    for line in f:
        result = template_miner.add_log_message(line.strip())
        if result["change_type"] == "cluster_created":
            print(f"NEW PATTERN: {result['template_mined']}")

# drain3.ini [DRAIN] sim_th = 0.4 depth = 4 max_children = 100 max_clusters = 1024 

תבנית חדשה בלוגי ייצור היא אות. לא תמיד תקרית, אבל תמיד סיבה להסתכל.

גישת ה-embedding נחוצה כאשר טקסט הלוג מגוון סמנטית ותבניות עובדות בצורה גרועה. לדוגמה, tracebacks של Python או הודעות שגיאה בטקסט חופשי מ-API של צד שלישי. כאן משתמשים ב-sentence-transformers לוקטוריזציה וב-FAISS או pgvector לזיהוי חריגות על בסיס מרחק קוסינוס מלוגים "נורמליים" ידועים.

אבל מודלי embedding דורשים GPU או משאבי CPU משמעותיים, והם פחות נפוצים בסביבות ייצור. עבור רוב המשימות, Drain3 בשילוב שיטות סטטיסטיות מספיקים.

כיצד Drain3 עוזר בניתוח לוגים

Drain3 מנתח לוגים, מקבץ אותם לאשכולות לפי תבנית, ועוקב אחר הופעת תבניות חדשות. אם אשכול עם שגיאת חיבור הופיע פעם בשעה ועכשיו עשר פעמים בדקה — זו חריגה. אנו מגדירים התראות אוטומטיות על בסיס שינוי זה. לייצור, אנו משתמשים ב-Drain3 יחד עם Prometheus ו-Alertmanager.

למה לסמוך על גישות Embedding?

גישות Embedding (BERT, OpenAI Ada) מטפלות טוב יותר בטקסט לא מובנה, למשל tracebacks. הן ממירות מחרוזות לוקטורים, וחריגה היא ערך חריג במרחב הוקטורי. עם זאת, הן דורשות יותר משאבים וזמן כוונון. עבור רוב הלוגים עם תבניות ברורות (Nginx, PostgreSQL), Drain3 יעיל יותר — מהיר יותר וללא צורך ב-GPU. השוואה להלן.

Drain3 לעומת Embedding: מתי לבחור מה

טכנולוגיות להטמעה בייצור

Loki + LogQL + Grafana Alerting

אם Loki כבר בשימוש, הצעד הראשון להתראות "חכמות" הוא מדדים מהלוגים באמצעות from drain3 import TemplateMiner from drain3.template_miner_config import TemplateMinerConfig config = TemplateMinerConfig() config.load("drain3.ini") template_miner = TemplateMiner(config=config) with open("app.log") as f: for line in f: result = template_miner.add_log_message(line.strip()) if result["change_type"] == "cluster_created": print(f"NEW PATTERN: {result['template_mined']}") . לדוגמה, ספירת קצב לוגי ERROR:

sum(rate({app="payment-service"} |= "level=error" [5m])) by (app) 

התראה על זינוק פתאומי היא כבר הרמה הראשונה של AIOps ללא ML. חריגה באמצעות Z-score:

( sum(rate({app="payment-service"} |= "error" [5m])) - avg_over_time(sum(rate({app="payment-service"} |= "error" [5m]))[1h:5m]) ) / stddev_over_time(sum(rate({app="payment-service"} |= "error" [5m]))[1h:5m]) > 3 

זה מחשב Z-score בזמן אמת: אם קצב השגיאות הנוכחי חורג מהממוצע השעתי ביותר מ-3 סטיות תקן — התראה.

OpenSearch + זיהוי חריגות

ל-OpenSearch (לשעבר Open Distro for Elasticsearch) יש תוסף מובנה לזיהוי חריגות המבוסס על Random Cut Forest (RCF). הגדרה דרך API:

PUT _plugins/_anomaly_detection/detectors
{
  "name": "error_rate_detector",
  "description": "Detects anomalies in error log rate",
  "time_field": "@timestamp",
  "indices": ["app-logs-*"],
  "feature_attributes": [
    {
      "feature_name": "error_count",
      "feature_enabled": true,
      "aggregation_query": {
        "error_count": {
          "filter": {
            "term": {
              "level": "error"
            }
          }
        }
      }
    }
  ],
  "detection_interval": {
    "period": {
      "interval": 5,
      "unit": "Minutes"
    }
  },
  "window_delay": {
    "period": {
      "interval": 1,
      "unit": "Minutes"
    }
  }
}

RCF עובד היטב על סדרות זמן עם עונתיות ברורה (לילה/יום, יום חול/סוף שבוע) — הוא מסתגל אוטומטית לתבניות ללא כוונון ידני של ספים.

Wazuh לניתוח לוגי אבטחה

לאירועי אבטחה (syslog, Windows Event Log, auditd), Wazuh משלב כללים מבוססי חתימות ומודלי ML לניתוח התנהגותי. לאחר התקנת הסוכן, הוא מנתח אוטומטית # drain3.ini [DRAIN] sim_th = 0.4 depth = 4 max_children = 100 max_clusters = 1024 , log_range_queries ויומני מערכת של Windows, מתאם אירועים ויוצר התראות עם רמות חומרה.

אינטגרציה עם Alertmanager ו-On-Call

זיהוי ML חסר ערך ללא ניתוב התראות נכון. טעות אופיינית: כל החריגות נוחתות בערוץ Slack אחד; אחרי שבוע הצוות מתעלם מהן. אנו מגדירים את Alertmanager עם עץ ניתוב:

---
# alertmanager.yml
route:
  group_by: ['alertname', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'slack-default'
  routes:
    - match:
        severity: critical
        category: security
      receiver: 'pagerduty-security'
    - match:
        severity: critical
      receiver: 'pagerduty-oncall'
    - match:
        anomaly_type: new_log_pattern
      receiver: 'slack-dev-alerts'
      continue: true
receivers:
  - name: 'pagerduty-oncall'
    pagerduty_configs:
      - routing_key: '${PAGERDUTY_KEY}'
        description: '{{ .CommonAnnotations.summary }}'

תבניות לוג חדשות עוברות לערוץ הפיתוח (אולי רק תכונה חדשה), חריגות מדדים קריטיות עוברות ל-PagerDuty.

תהליך ההטמעה ולוחות זמנים

אנו מתחילים בביקורת: כמה לוגים ביום, אילו מערכות מייצרות אותם, האם Elasticsearch/OpenSearch או Loki כבר קיימים. בחירת הכלי תלויה בכך — אין טעם לגרור את Wazuh אם ELK כבר קיים.

אפשרות מינימלית וברת-קיימא — התראות Z-score על גבי Loki קיים תוך 2-3 ימים. גלאי חריגות מלא על OpenSearch עם RCF מוגדר ואינטגרציה ל-PagerDuty — שבועיים. הטמעת מודל embedding לניתוח סמנטי של tracebacks עם כוונון לטכנולוגיה הספציפית שלכם — 4-6 שבועות, זהו פרויקט עם מהנדס ML.

נקודה חשובה: בשבועיים-ארבעה הראשונים לאחר השקת הגלאי יהיו הרבה חיוביים שגויים — התראות על חריגות "נורמליות" כמו פריסות או תחזוקה מתוכננת. יש צורך בזמן להגדיר כללי דיכוי ולאמן את המודל על תעבורה היסטורית. זה נורמלי; אל תשביתו את המערכת בשבוע הראשון.

מה כלול

הזמינו AIOps סוהרי ללוגים: אנו בוחרים את הטכנולוגיה האופטימלית, מגדירים זיהוי חריגות ואינטגרציה עם מערכת ההתראות שלכם. צרו קשר במייל או במסנג'רים — אנו מעריכים את הפרויקט שלכם תוך יום עסקים אחד. אחריות איכות על כל העבודה.