Automatic troubleshooting of failed network devices is just one practical example of automating network processes. For example, a sensor could continuously monitor the availability of a router by Simple Network Management Protocol (SNMP). If this router fails, an event is triggered and StackStorm [1] automatically starts a predefined workflow. The workflow, in turn, can include the following steps:

1. Launch a ping test to ensure that this is not just a temporary connection error.
2. If this contact attempt fails, restart the service.
3. If this step fails, too, StackStorm sends a notification to the administrator containing the log data of the problem device.

Such event-driven automation allows the detection of failures in real time and automatic initiation of actions, such as restarting services or blocking suspicious activities. These actions translate to a significant reduction in downtime and manual intervention. However, StackStorm not only helps you resolve network outages more quickly, it also adds efficiency to recurring tasks.

StackStorm is a particularly good choice for handling complex tasks. One of the tool's key advantages is that it combines automation and orchestration. Whereas automation takes care of repetitive tasks such as configuring hundreds of servers, orchestration takes things a step further by making decisions on the basis of conditions or thresholds, which means you can create workflows that react dynamically to events. Before I show you exactly how this works with the free open source tool, which is available under the Apache 2.0 license, I'll take a brief look at its structure.

Architecture and Components

StackStorm works on the principle of "if A, then B," which means that any event on a network or system, be it the addition of a new server or the receipt of a specific message, can trigger a series of actions. The actions can be as diverse as creating a new virtual local area network (VLAN) or starting an Ansible playbook. The software lets you to use existing RESTful APIs, and you can extend them with pre-configured integration packs to minimize the DIY code overhead.

Another of StackStorm's advantages is its flexibility. Local and remote scripts can be called with the help of runners – execution environments for actions – which means you can combine different automation actions, such as automatically creating a ticket in an IT service management tool (e.g., ServiceNow) after executing an Ansible playbook. The large number of available integrations makes it easier to integrate existing tools and quickly implement automation across a variety of IT systems. Keep in mind, however, that you will need some basic knowledge of Python and data structures such as JSON for StackStorm, because they both make it easier to write and manage workflows.

StackStorm has a modular architecture. The central functionality comes courtesy of the event bus, which processes incoming events and triggers actions. The following are the four most important components of StackStorm:

• Sensors monitor certain systems and event sources (e.g., network devices or applications). Sensors log events and forward them to StackStorm. One example is a sensor that monitors CPU utilization of a router and triggers an event if a defined threshold value is exceeded.
• Triggers link sensors with actions and define which events will initiate an action, one example being restarting a service if a network connection is interrupted.
• Actions carry out the automation steps and can be simple scripts or complex programs. A typical case is executing a script to configure network devices.
• Workflows orchestrate several actions in a defined sequence. They allow the implementation of complex automation workflows, such as the automatic configuration and monitoring of new network devices after they are installed. An example would be a workflow that performs several steps after a device failure; for example, restarting the device, testing the network connection, and, if this test fails, notifying the administrator. In StackStorm, you can use YAML to define workflows.

Installation and Basic Configuration

StackStorm can be installed on various platforms, including popular Linux distributions or Docker environments. On Linux (e.g., Ubuntu), the developers offer a script that lets you install StackStorm with a single command:

bash <(curl -sSL https://stackstorm.com/packages/install.sh) --user=st2admin --password=Ch@ngeMe

The script creates separate passwords for different access types, such as MongoDB or RabbitMQ. If you need these for various actions, say, to access the databases directly, you will find the information in the /etc/st2/st2.conf file. The command-line interface (CLI) is a good place to get started; just run the commands,

st2 --version
st2 -h

for example, to display the installed version and help (Figure 1).

Figure 1: You can access the StackStorm installation from the CLI immediately after installing on a Ubuntu system.

You can also use Docker for the setup. If Docker is available on the system, the first step is to clone the StackStorm repository to a directory of your choice:

git clone https://github.com/stackstorm/st2-docker

After downloading, change to the directory and start the containers:

sudo docker-compose up -d

The processes take some time, but all the containers should be available in your environment when done. You can use a terminal window to connect to the StackStorm client container and work on the CLI with the command

docker-compose exec st2client bash

when deploying with Docker. StackStorm is mainly managed on the command line. For your first login in a standard installation, type

st2 login st2admin -p "Ch@ngeMe"

To display the current list of actions, triggers, and rules, use:

st2 action list --pack=core
st2 trigger list
st2 rule list

You can also test the execution of commands over the network at this point. To do this, you will need SSH configured for passwordless access on the respective host. If you want to run the command on the local server instead, use:

st2 run core.remotehosts="localhost" --uname -a

Go to the StackStorm web interface by entering https://<IP address> in your browser's address bar. To log in, use the same login data as for the CLI (i.e., st2admin as the username and Ch@ngeMe as the password). The GUI can be used to perform any action that you can also initiate in the CLI.

Setting Up Sensors

In StackStorm, sensors have the task of monitoring and triggering events. You can configure a sensor so that it checks certain conditions, say, every five minutes. Once the condition is met, the associated trigger is activated, which in turn calls up a rule. This rule then executes the defined actions. A typical example is a sensor that logs alerts from a system and checks every five minutes to see whether any new alerts need to be forwarded to a system such as ServiceNow. In other words, sensors are the links between external events and downstream automation.

Another practical scenario is setting up a sensor that monitors syslog messages from network devices. To do this, you can either use predefined sensors or write your own. You can display the predefined sensors by typing

st2 sensor list

To enable an existing sensor, use either the CLI or the web GUI. To enable a syslog sensor, for example, use:

st2 sensor enable syslog_sensor

If you want to create a user-defined sensor, you will need to code a YAML file that defines the sensor, which then waits for a specific event (e.g., an error message or an error). Listing 1 contains an example of a YAML file for a sensor. This file configures the sensor to ping the specified IP address, in this case 192.168.1.1, every 60 seconds.

class_name: "PingSensor"
description: "Monitors an IP address and checks whether it is online"
enabled: true
trigger_types:
    - name: "ip.ping"
        description: "Triggers if the IP address is not reachable"
        payload_schema:
            type: "object"
            properties:
                ip_address:
                    type: "string"
                status:
                    type: "string"
                    enum: ["online", "offline"]
poll_interval: 60 # Checks every 60 seconds
sensor:
    module: "ping_sensor"
    class_name: "PingSensor"
    config:
        ip_address: "192.168.1.1" # IP address to check
        timeout: 5 # Ping timeout in seconds
        retries: 3 # Number of ping attempts before the host is considered to be offline

If the IP address cannot be reached after three attempts, the sensor triggers the ip.ping trigger, which in turn sends the status of the IP address (online or offline). The sensor can then be linked to other actions or workflows to provide an automatic response to the IP address failure, which could mean notifying an admin or starting a troubleshooting process.