Налаштування StackStorm для event-driven автоматизації IT-операцій

Налаштування StackStorm для Event-Driven автоматизації

Ми інтегруємо StackStorm у вашу інфраструктуру, коли ручна реакція на інциденти перестає встигати. Уявіть: о 3 ночі Prometheus запалює алерт DiskAlmostFull. Без автоматизації — черговий встає, чистить логи, пише постмортем. З нашим налаштуванням StackStorm — через секунду після алерту запускається workflow: очищення /var/log, повідомлення в Slack, оновлення тікету в Jira. Все без участі людини. MTTR знижується в 5-10 разів, що дає економію до $2,000 на місяць. Маємо 8 років досвіду та понад 50 впроваджень.

StackStorm — платформа event-driven автоматизації, яка забезпечує оркестрацію подій з будь-якого джерела: Prometheus, PagerDuty, Jira, Slack, GitLab та інші. Згідно з документацією, StackStorm — event-driven automation platform, that enables integration of services and automated workflows. Завдяки правилам та workflow ви описуєте логіку реакції в YAML — без програмування для базових сценаріїв. Для складних — використовуємо Python, Ansible або довільні скрипти. Середня економія часу — 15 хвилин на інцидент, що при 50 інцидентах на місяць дає 12.5 годин зекономленого часу. Автоматизація IT за допомогою StackStorm знижує ручну роботу до 90%.

Ми беремо на себе повний цикл: проектування правил, розробку custom pack'ів, тестування та документування. Оцінюємо проєкт за один день — зв'яжіться, щоб обговорити ваші сценарії.

Як працює StackStorm: архітектура та компоненти

StackStorm — це не просто планувальник. Це event-driven платформа, де події з будь-якого джерела (алерт Prometheus, webhook Jira, повідомлення RabbitMQ, лог-патерн) запускають дії за правилами. Вона складається з декількох мікросервісів:

• st2api — REST API, точка входу для CLI та веб-інтерфейсу
• st2actionrunner — виконує action'и (bash, Python, Ansible playbook, HTTP)
• st2rulesengine — обробляє події, матчить правила
• st2sensorcontainer — запускає сенсори, що слухають зовнішні джерела
• st2scheduler — планування timer-triggered правил
• RabbitMQ — транспорт між компонентами
• MongoDB — зберігання історії, правил, конфігурацій pack'ів

Типовий 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
---

Для production ми розгортаємо StackStorm в Kubernetes через Helm chart stackstorm/stackstorm-ha з окремим масштабуванням actionrunner'ів — саме вони споживають ресурси при інтенсивному навантаженні. Наш досвід — 8 років в event-driven автоматизації, понад 50 проєктів. Під навантаженням в 1000+ правил на хвилину потрібно мінімум 3 репліки actionrunner. Система здатна обробляти 500+ подій за хвилину.

Як написати перший pack?

Pack — одиниця розширення: набір sensor'ів, action'ів та rule'ів. Для внутрішньої автоматизації пишемо custom pack. Як створити свій pack покроково:

1. Створіть структуру директорій: my_ops/ з папками actions, rules, sensors та файлом pack.yaml.
2. У pack.yaml вкажіть name та version.
3. Напишіть action — YAML-опис з параметрами та точкою входу (bash, Python).
4. Опишіть rule — зв'яжіть тригер (наприклад, webhook від Alertmanager) з action'ом.
5. Завантажте pack у StackStorm командою st2 pack install —z my_ops.zip.

Для інтеграції з Alertmanager використовуйте вбудований webhook-тригер core.st2.webhook, що не вимагає написання власного сенсора. Приклад 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
---

Action для очищення:

---
# 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'а та передає в action. Весь шлях від алерту до виконання — секунди.

Чому Orquesta workflow кращий за ланцюжок action'ів?

Зауважимо: коли одного action'у недостатньо — використовуємо Orquesta workflow. Workflow Orquesta в 3 рази простіше за ланцюжок action'ів, оскільки в одному YAML-файлі описується весь сценарій з умовами, паралельними гілками та обробкою помилок. Порівняйте: ланцюжок action'ів через 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" 
---
# 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 — призначення ролей на рівні pack'ів, action'ів, rule'ів. Для команди з декількох інженерів це важливо: один може тільки переглядати execution history, інший — запускати action'и вручну, третій — керувати правилами. Ми налаштовуємо RBAC під вашу оргструктуру.

Всі execution'и логуються в MongoDB з повним input/output. st2 execution list --action my_ops.cleanup_disk — видно історію кожного запуску з часом, результатом, хто ініціював. Це забезпечує повний аудит та спрощує постмортеми.

Порівняння StackStorm, Cron та ручного виконання

Етапи розгортання та що входить в роботу

Ми розгортаємо StackStorm, налаштовуємо інтеграції з потрібними системами (Prometheus, PagerDuty, Jira, Slack — у кожного є готовий pack в Exchange). Розробляємо custom pack'и під специфіку інфраструктури, описуємо правила автоматизації, тестуємо в staging з реальними подіями.

Зауважимо: Що входить в роботу:

Терміни: базове розгортання з декількома готовими інтеграціями — 2-3 дні. Розробка custom pack'ів та складних workflow — 3-5 днів залежно від кількості сценаріїв. Вартість — від $2,000 за базове впровадження, повний пакет з кастомізацією від $5,000. Ми гарантуємо результат: ваша команда отримає документацію, доступ до репозиторію та годинну сесію з передачі знань.

Для оцінки вашого проєкту та отримання консультації з впровадження StackStorm залиште заявку — ми зв'яжемося протягом робочого дня. Також ви можете замовити пілотне впровадження на одному сценарії.