StackStorm Setup for Event-Driven IT Automation

StackStorm Setup for Event-Driven Automation

We integrate StackStorm into your infrastructure when manual incident response no longer keeps up. Picture this: at 3 AM Prometheus fires a DiskAlmostFull alert. Without automation — the on-call engineer gets up, cleans logs, writes a postmortem. With our StackStorm setup — within a second after the alert, a workflow runs: cleanup /var/log, notify in Slack, update the Jira ticket. Everything without human intervention. MTTR drops 5-10x.

StackStorm acts as a central event handler, supporting dozens of integrations out of the box: Prometheus, PagerDuty, Jira, Slack, GitLab, and others. According to the documentation, StackStorm is an event-driven automation platform, that enables integration of services and automated workflows. With rules and workflows, you describe response logic in YAML — no programming for basic scenarios. For complex cases, we use Python, Ansible, or arbitrary scripts. Average time savings — 15 minutes per incident, which at 50 incidents per month gives 12.5 hours saved.

We take on the full cycle: rule design, custom pack development, testing, and documentation. We evaluate your project in one day — contact us to discuss your scenarios.

How StackStorm Works: Architecture and Components

StackStorm is not just a scheduler. It is an event-driven platform where events from any source (Prometheus alert, Jira webhook, RabbitMQ message, log pattern) trigger actions via rules. It consists of several microservices:

• st2api — REST API, entry point for CLI and web interface
• st2actionrunner — executes actions (bash, Python, Ansible playbook, HTTP)
• st2rulesengine — processes events, matches rules
• st2sensorcontainer — runs sensors listening to external sources
• st2scheduler — schedules timer-triggered rules
• RabbitMQ — transport between components
• MongoDB — stores history, rules, pack configurations

Typical Docker Compose for 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

For production, we deploy StackStorm in Kubernetes using the Helm chart stackstorm/stackstorm-ha with separate scaling of action runners — they consume resources under heavy load. Our experience — 8 years in event-driven automation, over 50 projects. Under a load of 1000+ rules per minute, you need at least 3 action runner replicas.

Writing Your First Pack: From Webhook to Automated Action

A pack is an extension unit: a set of sensors, actions, and rules. For internal automation, we write custom packs. How to create your own pack step by step:

1. Create the directory structure: my_ops/ with folders actions, rules, sensors, and a pack.yaml file.
2. In pack.yaml, specify the name and version.
3. Write an action — YAML description with parameters and an entry point (bash, Python).
4. Describe a rule — link a trigger (e.g., webhook from Alertmanager) to an action.
5. Load the pack into StackStorm with st2 pack install --z my_ops.zip.

For integration with Alertmanager, use the built-in webhook trigger core.st2.webhook, which does not require writing your own sensor. Example rule for automatic disk cleanup:

# 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 for cleanup:

---
# 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"

The rule matches the webhook, extracts the host name from the Alertmanager payload, and passes it to the action. The entire path from alert to execution takes seconds.

Why Orquesta Workflow Beats a Chain of Actions?

Note: When a single action is not enough, we use an Orquesta workflow. It is a YAML description with conditions, parallel branches, and error handling. Compare: chaining actions via rules requires multiple rules and extra logic. A workflow describes the entire scenario in one file:

---
# 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" 
---

The workflow performs a check, and only if usage is >85% does it trigger cleanup and notification. Otherwise, it resolves the alert immediately. This is a typical model for automating routine operations.

RBAC and Audit: Access Control and Transparency

StackStorm has built-in RBAC — role assignment at the level of packs, actions, rules. For a team of several engineers, this matters: one can only view execution history, another can run actions manually, a third can manage rules. We configure RBAC according to your organizational structure.

All executions are logged in MongoDB with full input/output. st2 execution list --action my_ops.cleanup_disk — you see the history of each run with time, result, and who initiated it. This provides full audit and simplifies postmortems.

Comparison: StackStorm vs Cron vs Manual Execution

Deployment Stages and What's Included

We deploy StackStorm, configure integrations with the necessary systems (Prometheus, PagerDuty, Jira, Slack — each has a ready pack in Exchange). We develop custom packs for your infrastructure specifics, describe automation rules, test in staging with real events.

Note: What is included in the work:

Timelines: basic deployment with several ready integrations — 2-3 days. Custom packs and complex workflows — 3-5 days depending on the number of scenarios. Cost is individual after discussing specific automation tasks. We guarantee results: your team will get documentation, access to the repository, and a one-hour knowledge transfer session.

For evaluating your project and getting a consultation on StackStorm implementation, leave a request — we will get back to you within one business day. You can also order a pilot implementation on a single scenario.