יצירת אירועים אוטומטית: מניטורינג ל-Jira Service Management

תארו לעצמכם: שירות ייצור קורס באמצע הלילה. Alertmanager שולח התראה ל-PagerDuty, אבל המהנדס התורן יוצר ידנית קריאה ב-Jira Service Management. בזמן שהם מחפשים תבנית, ממלאים חומרה ומקצים SLA, חולפות דקות — כל התראה הופכת לעשרות הודעות. נתקלנו באתגר הזה בזמן תחזוקת תשתית עם 200+ מיקרוסרוויסים עבור לקוח במגזר הפינטק. תוצאת האוטומציה: זמן התגובה קטן ב-60%, והעלויות התפעוליות לאירועים נחתכו בחצי על ידי ביטול העבודה השגרתית. עם ניסיון של למעלה מ-5 שנים ב-ITSM וניטור (30+ הטמעות), פיתחנו סכמות אינטגרציה אופטימליות.

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

כיצד עובדת אינטגרציית ה-Webhook של Alertmanager עם JSM

הדרך הגמישה ביותר היא מקלט webhook ב-Alertmanager שקורא ל-Jira REST API:

---
# alertmanager.yml
receivers:
  - name: jira-incidents
    webhook_configs:
      - url: http://jsm-bridge:8080/alert
        send_resolved: true
        http_config:
          bearer_token_file: /etc/alertmanager/jsm_token
route:
  group_by: ['alertname', 'namespace', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 6h
  routes:
    - match:
        severity: critical
      receiver: jira-incidents
    - match:
        severity: warning
      receiver: jira-incidents
      continue: false

שירות ה-webhook יוצר קריאה באמצעות POST /rest/api/3/issue עם שדות: סיכום, תיאור, עדיפות, תוויות. כאשר # alertmanager.yml receivers: - name: jira-incidents webhook_configs: - url: http://jsm-bridge:8080/alert send_resolved: true http_config: bearer_token_file: /etc/alertmanager/jsm_token route: group_by: ['alertname', 'namespace', 'service'] group_wait: 30s group_interval: 5m repeat_interval: 6h routes: - match: severity: critical receiver: jira-incidents - match: severity: warning receiver: jira-incidents continue: false , Alertmanager שולח בקשה שנייה עם סטטוס resolved — השירות מוצא את הקריאה הפתוחה לפי JQL וסוגר אותה. לפי התיעוד של Atlassian, שיטה זו מאפשרת שליטה על כל שדה באירוע.

טיפול בהסרת כפילויות התראות

ללא הסרת כפילויות, תקלה אחת יוצרת עשרות קריאות. שתי שכבות הגנה:

ברמת Alertmanager: send_resolved: true מקבץ התראות קשורות ל-webhook אחד. group_by: ['alertname','namespace','service'] אוסף התראות חוזרות לפני הקריאה הראשונה.

ברמת שירות ה-webhook: לפני יצירת קריאה, השירות מבצע שאילתת JQL: group_wait: 30s. אם נמצאה קריאה, מתווספת תגובה; לא נוצרת קריאה חדשה. זה מבטיח שאירוע אחד = תקרית אחת.

אינטגרציה מקורית דרך Grafana OnCall

אם הסט הטכנולוגי שלכם כולל Grafana OnCall, ניתן להגדיר את מחבר JSM תוך שעה. OnCall תומך ביצירת תקרית JSM כאשר מופעלת הסלמה, סגירה אוטומטית בעת resolve, וסנכרון סטטוס דו-כיווני. זה פשוט יותר מ-webhook מותאם אישית, אבל הגמישות נמוכה יותר: לא ניתן להתאים אישית מיפוי שדות לתרחישים מורכבים. Grafana OnCall מהיר ב-50% להטמעה בהשוואה לגישת ה-webhook.

אינטגרציה ישירה של Grafana Alerting

בגרסאות האחרונות של Grafana, זמין Contact Point מסוג Jira. הגדרה: כתובת Jira, שם משתמש, API token, פרויקט, סוג קריאה, סיכום. המגבלה היא שאין יצירה מותנית (רק כללי ניתוב) ואין שדות מותאמים אישית.

הגדרת JSM לאירועי ניטור

ב-JSM, נדרש:

• פרויקט שירות עם מדיניות SLA ותור כוננות.
• סוג בקשה "התראת ניטור" עם שדות: חומרה, שירות_מושפע, קישור_התראה.
• כללי אוטומציה להקצאה אוטומטית למהנדס התורן (באמצעות רוטציית כוננות של JSM) ומעבר סטטוסים לפי עדיפות.

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

const express = require('express');
const axios = require('axios');
const app = express();
app.use(express.json());
app.post('/alert', async (req, res) => {
  const { alerts } = req.body;
  for (const alert of alerts) {
    // поиск существующего issue по JQL
    const existing = await jira.search(`project = INFRA AND status != Done AND labels = "alert:${alert.labels.alertname}"`);
    if (existing.length === 0) {
      // создание нового issue
      await jira.createIssue({
        summary: alert.annotations.description,
        issueType: 'Incident',
        priority: alert.severity === 'critical' ? 'Highest' : 'High',
        labels: [`alert:${alert.labels.alertname}`]
      });
    } else {
      // добавление комментария
      await jira.addComment(existing[0].id, 'Повторный алерт');
    }
  }
  res.send('ok');
});
app.listen(8080);

השוואת שיטות הטמעה

מה כלול בעבודה

הטמעת האוטומציה כוללת:

• ביקורת של סכמת הניטור הנוכחית ותהליכי ITSM.
• בחירת שיטת אינטגרציה עם נימוק.
• הגדרת webhook/מחבר עם הסרת כפילויות ומיפוי שדות.
• בדיקת מחזור מלא: מהתראה ועד סגירת קריאה.
• תיעוד תצורה והוראות למהנדסים תורנים.
• תמיכה לאחר שחרור למשך שבועיים.

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

אנחנו מתחילים ביישור: פרויקט, סוג קריאה, שדות מותאמים אישית, מדיניות SLA. זה לוקח יום אחד. הטמעה טכנית אורכת 1 עד 2 ימים, כולל פריסה ובדיקות. לוחות הזמנים נעים בין 2 ל-3 ימים. העלות מחושבת באופן פרטני, בהתאם למורכבות ההיקף.

מתי לבחור Webhook לעומת Grafana OnCall?

• Webhook — אם אתם צריכים התאמה אישית מלאה, כללי הסרת כפילויות לא סטנדרטיים, או אינטגרציה עם מערכות legacy.
• Grafana OnCall — אם הסט הטכנולוגי שלכם כבר כולל Grafana והצוות רוצה חסם כניסה מינימלי וסנכרון דו-כיווני.
• מחבר ישיר — לתרחישים פשוטים ללא שדות מורכבים ולוגיקה מותנית.

למה זה משתלם?

אוטומציה של יצירת אירועים מהניטור חוסכת עד 10 שעות בשבוע למהנדס התורן ומפחיתה את MTTR ב-50% (מספרים אמיתיים מאחת ההטמעות שלנו). חיסכון ממוצע בתקציב על אירועים הוא 40% לאחר הפריסה. אנחנו מבטיחים איכות: כל התצורות נבדקות בסביבת staging לפני פריסה לייצור.

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