הגדרת התראות מבוססות לוגים: שיטות וכלים

הגדרת התראות מבוססות לוגים: שיטות וכלים

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

צרו קשר—נעזור לכם להגדיר התראות מבוססות לוגים לתשתית שלכם.

איך להגדיר התראות מבוססות לוגים בלי עייפות התראות?

האתגר המרכזי הוא סינון רעש. התראה על כל ERROR? זו דרך בטוחה לעייפות התראות. אנו משתמשים בכללים גמישים עם ספים, הסרת כפילויות והחרגה של אירועים צפויים. התוצאה: לא יותר מ-2–3 התראות ביום לכל שירות קריטי.

תהליך ההגדרה כולל מספר שלבים:

1. ניתוח לוגים: זיהוי דפוסי שגיאה אופייניים. לדוגמה, בלוגי גישה של Nginx אנו מסננים רק 5xx; בלוגי backend, Java stacktraces.
2. הגדרת שירותים קריטיים וספים (למשל, >10 שגיאות בדקה).
3. כתיבת כללים עם הסרת כפילויות (realert) והחרגות.
4. בדיקה על נתונים היסטוריים (לפחות שבועיים).
5. כיול ספים כדי לשמור על תוצאות חיוביות שגויות מתחת ל-2%.

ElastAlert2 עבור Elasticsearch/OpenSearch

ElastAlert2 הוא הפתרון הגמיש ביותר להתראות מבוססות כללים. לפי תיעוד ElastAlert2, הוא תומך במספר סוגי כללים. דוגמה לכלל תדירות עבור שירות תשלומים:

---
# rules/payment-errors.yaml
name: "Payment service critical errors"
type: frequency
index: k8s-logs-production-*
num_events: 3
timeframe:
  minutes: 5
filter:
  - term:
      kubernetes.labels.app: "payments-api"
  - terms:
      level: ["error", "fatal", "critical"]
  - bool:
      must_not:
        term:
          message: "validation error"
query_key: "error_code"
alert:
  - "slack"
slack_webhook_url: !ENV SLACK_WEBHOOK_URL
slack_channel_override: "#alerts-production"
slack_msg_color: "danger"
alert_text_type: alert_text_only
alert_text: |
  *Payment service errors*
  {num_matches} events in last 5 minutes
  Error code: {error_code}
  Latest message: {message}
realert:
  minutes: 30
---

סוג מורכב יותר—# rules/payment-errors.yaml name: "Payment service critical errors" type: frequency index: k8s-logs-production-* num_events: 3 timeframe: minutes: 5 filter: - term: kubernetes.labels.app: "payments-api" - terms: level: ["error", "fatal", "critical"] - bool: must_not: term: message: "validation error" query_key: "error_code" alert: - "slack" slack_webhook_url: !ENV SLACK_WEBHOOK_URL slack_channel_override: "#alerts-production" slack_msg_color: "danger" alert_text_type: alert_text_only alert_text: | *Payment service errors* {num_matches} events in last 5 minutes Error code: {error_code} Latest message: {message} realert: minutes: 30 —לצמיחת שגיאות חריגה:

---
name: "Error rate spike detection"
type: spike
index: k8s-logs-production-*
spike_height: 3
spike_type: up
timeframe:
  minutes: 10
threshold_ref: 5
filter:
- terms:
    level: ["error", "fatal"]
alert:
- "pagerduty"
pagerduty_service_key: !ENV PAGERDUTY_KEY
pagerduty_client: "ElastAlert2"
---

התראות Grafana על גבי Loki

עבור מחסנית Loki + Grafana, כלל מוגדר ישירות ב-Grafana:

---
# Provisioning через grafana/provisioning/alerting/rules.yaml
apiVersion: 1
groups:
  - name: log-based-alerts
    folder: Production Alerts
    interval: 1m
    rules:
      - uid: db-connection-errors
        title: "Database connection errors"
        condition: threshold
        data:
          - refId: errors_count
            datasourceUid: loki
            relativeTimeRange:
              from: 300
              to: 0
            model:
              expr: |
                sum(count_over_time( {namespace="production"} | json | message =~ ".*connection refused.*|.*ECONNREFUSED.*|.*could not connect to server.*" [5m] ))
          - refId: threshold
            datasourceUid: "-100"
            model:
              conditions:
                - evaluator:
                    params: [5]
                    type: gt
                  reducer:
                    type: last
                  type: query
              query:
                params: [errors_count]
        for: 2m
        labels:
          severity: critical
          team: backend
        annotations:
          summary: "DB connection errors: {{ $values.errors_count.Value }} in last 5min"
          runbook_url: "https://wiki.internal/runbooks/db-connection"

למה ElastAlert2 עדיף לכללים מורכבים?

ElastAlert2 מציע הסרת כפילויות מובנית (realert), שחסרה ב-Grafana Alerting. עבור לוגיקה מורכבת—שילוב של תדירות וקפיצה—ElastAlert2 גמיש פי 3 בהתאמת כללים. אם אתם כבר משתמשים ב-Elasticsearch, ElastAlert2 הוא הבחירה הטבעית. עבור צוותים על מחסנית Grafana + Loki, ההתראות המובנות קלות יותר להתחלה, אבל ככל שהדרישות גדלות, תצטרכו לבצע מיגרציה.

על מה להתריע ומה לא?

מועמדים טובים להתראות:

• דפוסים שאסור שיופיעו בפעולה רגילה: spike, panic, OOM killed, segfault.
• חריגות סף ליחידת זמן: >10 שגיאות/דקה בשירות תשלומים.
• היעדר אירועים צפויים: אין name: "Error rate spike detection" type: spike index: k8s-logs-production-* spike_height: 3 spike_type: up timeframe: minutes: 10 threshold_ref: 5 filter: - terms: level: ["error", "fatal"] alert: - "pagerduty" pagerduty_service_key: !ENV PAGERDUTY_KEY pagerduty_client: "ElastAlert2" במשך 15 דקות (התראת heartbeat).
• קודי שגיאה ספציפיים הדורשים פעולה: # Provisioning через grafana/provisioning/alerting/rules.yaml apiVersion: 1 groups: - name: log-based-alerts folder: Production Alerts interval: 1m rules: - uid: db-connection-errors title: "Database connection errors" condition: threshold data: - refId: errors_count datasourceUid: loki relativeTimeRange: from: 300 to: 0 model: expr: | sum(count_over_time( {namespace="production"} | json | message =~ ".*connection refused.*|.*ECONNREFUSED.*|.*could not connect to server.*" [5m] )) - refId: threshold datasourceUid: "-100" model: conditions: - evaluator: params: [5] type: gt reducer: type: last type: query query: params: [errors_count] for: 2m labels: severity: critical team: backend annotations: summary: "DB connection errors: {{ $values.errors_count.Value }} in last 5min" runbook_url: "https://wiki.internal/runbooks/db-connection" עם קצב > קו בסיס.

מועמדים גרועים:

• 404 Not Found בלוגי גישה—זה נורמלי.
• FATAL מלקוחות API—לוגיקה עסקית, לא תקרית.
• כל WARN—WARN ראוי לדשבורד ייעודי, לא להתראה.

השוואה: ElastAlert2 לעומת Grafana Alerting

דפוסי שגיאה נפוצים וסוגי התראות

התהליך שלנו להגדרת התראות מבוססות לוגים

אנו מטפלים בכל ההגדרה:

• ביקורת על מקורות הלוגים הנוכחיים ומבנה ההודעות.
• עיצוב כללי התראה (טריגרים, ספים, החרגות).
• יישום תצורות ElastAlert2 או Grafana (YAML, provisioning).
• הגדרת ערוצי התראות: Slack, PagerDuty, Telegram, אימייל.
• בדיקה על נתונים היסטוריים (מינימום שבועיים).
• כיול ספים למזעור תוצאות חיוביות שגויות (יעד <2%).
• תיעוד כללים ו-runbook למהנדסי כוננות.
• הדרכת צוות: איך לטפל בהתראות ולהוסיף חדשות.
• שבועיים של תמיכה לאחר השחרור.

למה להפקיד בידינו את ההגדרה?

אנחנו צוות של מהנדסי DevOps עם שנים של ניסיון מעשי. יישמנו התראות מבוססות לוגים ל-50+ פרויקטים. אנו משתמשים ב-GitOps—כל הכללים חיים ב-Git, ושינויים עוברים ביקורת קוד. אנו מבטיחים שאחרי היישום, שיעור התוצאות החיוביות השגויות יישאר מתחת ל-5%. בפרויקט אחד, צמצמנו עלויות תקרית ב-30% בזכות התראות מדויקות.

לוחות זמנים ותמחור

עבור 5–15 שירותים קריטיים, ההגדרה אורכת 1 עד 2 שבועות. התמחור מותאם אישית, בהתבסס על מורכבות הכללים ומספר מקורות הלוגים. נעריך את הפרויקט שלכם ביום אחד—פשוט פנו אלינו.

מקרה בוחן: שירות תשלומים עם דיוק התראות של 99.9%

מהניסיון שלנו: שירות רכישה אינטרנטי המטפל ב-5000+ בקשות בדקה. הגדרנו ElastAlert2 עם כללי קפיצה: אם שגיאות PAYMENT_DECLINED קפצו פי 3 ב-5 דקות, נשלחה התראה ל-PagerDuty. במהלך חודש, זיהינו 4 תקרית שמדדי זמן השהיה פספסו. עייפות התראות? אפס. תוצאות חיוביות שגויות? מתחת ל-1%. כל זה בזכות סינון מדויק והסרת כפילויות. מהנדסי הכוננות חסכו כ-20 שעות בחודש.

קבלו ייעוץ—נעזור לכם למיין את ההתראות ולחסל רעש לוגים. פשוט שלחו לנו הודעה.