Настройка StackStorm для event-driven автоматизации IT-операций

Настройка StackStorm для Event-Driven автоматизации

Мы интегрируем StackStorm в вашу инфраструктуру, когда ручная реакция на инциденты перестаёт успевать. Представьте: в 3 ночи Prometheus зажигает алерт DiskAlmostFull. Без автоматизации — дежурный встаёт, чистит логи, пишет постмортем. С нашей настройкой StackStorm — через секунду после алерта запускается workflow: очистка /var/log, уведомление в Slack, обновление тикета в Jira. Всё без участия человека. MTTR снижается в 5-10 раз.

StackStorm работает как центральный обработчик событий, поддерживая десятки интеграций из коробки: 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 часов сэкономленного времени.

Мы берём на себя полный цикл: проектирование правил, разработку 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.

Пишем первый pack: от webhook до автоматического действия

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. Это 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"

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 дней в зависимости от количества сценариев. Стоимость — индивидуально после обсуждения конкретных задач автоматизации. Мы гарантируем результат: ваша команда получит документацию, доступ к репозиторию и часовую сессию по передаче знаний.

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