הגדרת StackStorm לאוטומציית IT מונעת אירועים

הגדרת StackStorm לאוטומציה מונעת אירועים

אנו משלבים את StackStorm בתשתית שלך כאשר תגובה ידנית לאירועים כבר לא עומדת בקצב. תארו לעצמכם: ב-3 לפנות בוקר Prometheus שולח התראת DiskAlmostFull. ללא אוטומציה — המהנדס התורן קם, מנקה לוגים, כותב דו"ח תחקיר. עם הגדרת StackStorm שלנו — תוך שנייה מההתראה, רץ workflow: ניקוי /var/log, הודעה ב-Slack, עדכון כרטיס Jira. הכל ללא התערבות אנושית. MTTR יורד פי 5-10.

StackStorm משמש כמטפל אירועים מרכזי, ותומך בעשרות אינטגרציות מובנות: Prometheus, PagerDuty, Jira, Slack, GitLab ועוד. לפי התיעוד, StackStorm הוא פלטפורמת אוטומציה מונעת אירועים, המאפשרת שילוב שירותים ו-workflows אוטומטיים. עם rules ו-workflows, אתה מתאר את לוגיקת התגובה ב-YAML — ללא תכנות עבור תרחישים בסיסיים. למקרים מורכבים, אנו משתמשים ב-Python, Ansible או סקריפטים שרירותיים. חיסכון ממוצע בזמן — 15 דקות לכל אירוע, שב-50 אירועים בחודש נותן 12.5 שעות חסכון.

אנו לוקחים על עצמנו את כל המחזור: עיצוב rules, פיתוח packs מותאמים, בדיקות ותיעוד. אנו מעריכים את הפרויקט שלך ביום אחד — צור קשר כדי לדון בתרחישים שלך.

איך StackStorm עובד: ארכיטקטורה ורכיבים

StackStorm הוא לא רק מתזמן. זוהי פלטפורמה מונעת אירועים שבה אירועים מכל מקור (התראת Prometheus, webhook של Jira, הודעת RabbitMQ, תבנית לוג) מפעילים פעולות דרך rules. היא מורכבת מכמה microservices:

• st2api — REST API, נקודת כניסה לממשק CLI ו-web
• st2actionrunner — מבצע פעולות (bash, Python, Ansible playbook, HTTP)
• st2rulesengine — מעבד אירועים, מתאם rules
• st2sensorcontainer — מריץ חיישנים המאזינים למקורות חיצוניים
• st2scheduler — מתזמן rules המופעלים על ידי טיימר
• RabbitMQ — תעבורה בין רכיבים
• MongoDB — אחסון היסטוריה, rules, תצורות packs

Docker Compose טיפוסי ל-dev/staging:

---
version: '3.8'
services:
  stackstorm:
    image: stackstorm/stackstorm:3.8
    env_file: .env
    ports:
      - "443:443"
    volumes:
      - ./packs:/opt/stackstorm/packs.dev
      - ./configs:/opt/stackstorm/configs
    depends_on:
      - mongo
      - rabbitmq
      - redis
  mongo:
    image: mongo:4.4
    volumes:
      - mongo_data:/data/db
  rabbitmq:
    image: rabbitmq:3.9-management
    volumes:
      - rabbit_data:/var/lib/rabbitmq
---

לייצור, אנו פורסים את StackStorm ב-Kubernetes באמצעות Helm chart version: '3.8' services: stackstorm: image: stackstorm/stackstorm:3.8 env_file: .env ports: - "443:443" volumes: - ./packs:/opt/stackstorm/packs.dev - ./configs:/opt/stackstorm/configs depends_on: - mongo - rabbitmq - redis mongo: image: mongo:4.4 volumes: - mongo_data:/data/db rabbitmq: image: rabbitmq:3.9-management volumes: - rabbit_data:/var/lib/rabbitmq עם scaling נפרד של action runners — הם צורכים משאבים בעומס כבד. הניסיון שלנו — 8 שנים באוטומציה מונעת אירועים, מעל 50 פרויקטים. בעומס של 1000+ rules לדקה, אתה צריך לפחות 3 רפליקות של action runner.

כתיבת ה-Pack הראשון שלך: מ-Webhook לפעולה אוטומטית

Pack הוא יחידת הרחבה: קבוצה של חיישנים, פעולות ו-rules. לאוטומציה פנימית, אנו כותבים packs מותאמים. איך ליצור pack משלך צעד אחר צעד:

1. צור את מבנה התיקיות: my_ops/ עם תיקיות actions, rules, sensors וקובץ pack.yaml.
2. ב-pack.yaml, ציין את השם והגרסה.
3. כתוב פעולה — תיאור YAML עם פרמטרים ונקודת כניסה (bash, Python).
4. תאר rule — קשר בין trigger (למשל, webhook מ-Alertmanager) לפעולה.
5. טען את ה-pack לתוך StackStorm עם stackstorm/stackstorm-ha.

לאינטגרציה עם Alertmanager, השתמש ב-webhook trigger המובנה st2 pack install —z my_ops.zip, שאינו דורש כתיבת חיישן משלך. דוגמה ל-rule לניקוי דיסק אוטומטי:

---
# rules/on_disk_alert.yaml
name: disk_full_cleanup
pack: my_ops
description: "Trigger disk cleanup when Prometheus fires DiskAlmostFull alert"
trigger:
  type: core.st2.webhook
  parameters:
    url: alertmanager
criteria:
  trigger.body.alerts[0].labels.alertname:
    type: equals
    pattern: DiskAlmostFull
action:
  ref: my_ops.cleanup_disk
  parameters:
    host: "{{ trigger.body.alerts[0].labels.instance }}"
    threshold_gb: 5
enabled: true
---

פעולה לניקוי:

---
# actions/cleanup_disk.yaml
name: cleanup_disk
pack: my_ops
runner_type: remote-shell-script
entry_point: cleanup_disk.sh
parameters:
  host:
    type: string
    required: true
  threshold_gb:
    type: integer
    default: 5
---

#!/bin/bash
# actions/cleanup_disk.sh
HOST=$1
THRESHOLD=$2
find /var/log -name "*.log" -mtime +7 -delete
find /tmp -mtime +1 -delete
journalctl --vacuum-size=${THRESHOLD}G
echo "Cleanup completed on $HOST"

ה-rule מתאים את ה-webhook, מחלץ את שם המארח מה-payload של Alertmanager, ומעביר אותו לפעולה. כל הנתיב מההתראה לביצוע לוקח שניות.

למה Orquesta Workflow עדיף על שרשרת פעולות?

הערה: כאשר פעולה אחת לא מספיקה, אנו משתמשים ב-Orquesta workflow. זהו תיאור YAML עם תנאים, ענפים מקבילים וטיפול בשגיאות. השווה: שרשור פעולות דרך rules דורש מספר rules ולוגיקה נוספת. Workflow מתאר את כל התרחיש בקובץ אחד:

---
# actions/workflows/incident_response.yaml version: 1.0 description: Automated incident response for disk full alert input: - host - alertname tasks: check_disk: action: core.remote input: hosts: <% ctx(host) %> cmd: df -h / | tail -1 | awk '{print $5}' next: - when: <% succeeded() and int(result().stdout.replace('%', '')) > 85 %> do: cleanup_and_notify - when: <% succeeded() and int(result().stdout.replace('%', '')) <= 85 %> do: resolve_alert cleanup_and_notify: action: my_ops.cleanup_disk input: host: <% ctx(host) %> next: - do: send_slack_notification send_slack_notification: action: slack.post_message input: channel: "#ops-alerts" message: "Disk cleanup executed on <% ctx(host) %>, alert: <% ctx(alertname) %>" resolve_alert: action: slack.post_message input: channel: "#ops-alerts" message: "Alert <% ctx(alertname) %> on <% ctx(host) %> resolved automatically" 
---

ה-workflow מבצע בדיקה, ורק אם השימוש הוא >85% הוא מפעיל ניקוי והודעה. אחרת, הוא פותר את ההתראה מיד. זהו מודל טיפוסי לאוטומציה של פעולות שגרתיות.

RBAC וביקורת: בקרת גישה ושקיפות

ל-StackStorm יש RBAC מובנה — הקצאת תפקידים ברמת packs, פעולות, rules. עבור צוות של כמה מהנדסים, זה חשוב: אחד יכול רק לצפות בהיסטוריית ביצועים, אחר יכול להריץ פעולות ידנית, שלישי יכול לנהל rules. אנו מגדירים RBAC לפי המבנה הארגוני שלך.

כל הביצועים מתועדים ב-MongoDB עם קלט/פלט מלא. core.st2.webhook — אתה רואה את ההיסטוריה של כל ריצה עם זמן, תוצאה ומי יזם אותה. זה מספק ביקורת מלאה ומפשט תחקירים.

השוואה: StackStorm לעומת Cron לעומת ביצוע ידני

שלבי פריסה ומה כלול

אנו פורסים את StackStorm, מגדירים אינטגרציות עם המערכות הנדרשות (Prometheus, PagerDuty, Jira, Slack — לכל אחת יש pack מוכן ב-Exchange). אנו מפתחים packs מותאמים לפרטי התשתית שלך, מתארים rules אוטומציה, בודקים ב-staging עם אירועים אמיתיים.

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

לוחות זמנים: פריסה בסיסית עם כמה אינטגרציות מוכנות — 2-3 ימים. Packs מותאמים ו-workflows מורכבים — 3-5 ימים תלוי במספר התרחישים. העלות אישית לאחר דיון במשימות אוטומציה ספציפיות. אנו מבטיחים תוצאות: הצוות שלך יקבל תיעוד, גישה ל-repository, וסשן העברת ידע של שעה.

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