Skip to main content

Writing Your Own Custom Playbook Action in Robusta

In this second installment of our Robusta blog series, we will delve deeper into the capabilities of this powerful open-source tool. Robusta is an open-source tool that enables Kubernetes troubleshooting and automation in multi-cluster environments. More precisely, we will discuss Robusta automation and how it works and we will write our own custom playbook action. We’ll look at how Robusta can automate and simplify the process of running Kubernetes clusters.

Introduction to Robusta

Robusta is a platform for monitoring and remediation that offers insightful information into Kubernetes clusters and integrates with a variety of monitoring and alerting tools.
It sits on top of your monitoring stacks, such as Prometheus or Elasticsearch, and explains why and how to fix alerts.

Robusta automates all processes that take place after your application is deployed. It’s similar to Zapier/IFTTT for DevOps, focusing on prebuilt automation rather than “build your own.”

How Robusta Automation Works

The division of YAML-defined automation into triggers, actions, and sinks simplifies things conceptually. This distinct division may lessen the entry barrier, particularly if you’re looking for accessible locations to start integrating your tooling.

Every automation consists of 3 distinct steps

Figure: Automation Basics


Simply put, a trigger represents a specific situation that initiates a response.

Example triggers

  • on_pod_create
  • on_deployment_create
  • on_pod_update
  • on_deployment_update
  • on_pod_delete

Action-trigger Compatibility:

Now we need to understand how triggers are bound to actions.
There are two types of actions in robusta.

  • Simple actions.
  • Resource-related actions.

Simple Actions:

Simple actions require no particular parameters (as shown in figure A below) and can therefore be executed in response to any trigger. Eg:

Figure A: Simple actions with no parameters

This action checks network connectivity in your cluster using ping. Pings a hostname from within the cluster. So we do not need to give any Kubernetes resources to this action.

Resource-related Actions:

These actions require Kubernetes resources as input.

For example, a pod is required as input for the logs_enricher action.

As a result, logs_enricher can only be linked to triggers that output a pod. As an example, Figure B shows resource-related actions:

Figure B: Resource-related actions with parameters

These actions can provide context for any pod-related event, such as on Prometheus alert or pod update.


Playbook results (findings) can be sent to one or more sinks (destinations).

The following sinks are supported:

  • Robusta UI
  • Slack
  • MS Teams

Sending Findings to Specific Sinks:

You can set up a sink to only accept particular findings. For example, depending on the namespace, you can send notifications to multiple Slack channels, Figure C shows add findings in the values file:

Figure C:Sending findings to the slack channel

Events and Triggers:

Events are Robusta objects that hold information on a particular resource in your cluster. When configuring Robusta as a user, triggers are defined in YAML ( generated_values.yaml ), but events are dealt with while writing playbook actions.

The basic concept is that triggers create event objects, which are then passed to action functions. Below is Figure D illustrates the lifecycle of robusta events.

Figure D:Event lifecycle

Compatibility of Actions and Events

Let’s examine this from the viewpoint of a developer creating a Python playbook action.

By selecting the first parameter of your playbook’s Python function, you can specify which events your playbook is compatible with. As shown in Figure E below.

Figure E: Action taking parameter PrometheusKubernetesAlert

Since no other trigger can generate the event object for the above action because it requires PrometheusKubernetesAlert as input, it can only be connected to an on_prometheus_alert trigger.

However, since it doesn’t do anything with the alert itself, this action doesn’t really require a Prometheus alert as input. This action can be changed to take a PodEvent as input. As shown in Figure F below.

Figure F: Action taking parameter PodEvent

PrometheusKubernetesAlert is a subclass of PodEvent.Therefore, general object-oriented principles are applicable here. So, wherever a PodEvent is anticipated, PrometheusKubernetesAlert can be used.

Here is the illustration of the robusta event hierarchy for Prometheus in Figure G:

Figure G: Event Hierarchy

The Robusta triggers are arranged in a hierarchy. If a particular trigger is supported by action, all descendants of that trigger are also supported.

Writing Our First Playbook Action

Creating Your Own Playbook Repository

A playbook repository consists of the following directory structure as shown in Figure H below:

Figure H: Playbook repository

As an example, consider the following pyproject.toml in Figure I:

Figure I:Toml file

Note: The name of the inner playbooks directory must match the package name in your pyproject.toml file.

List any additional Python dependencies that your playbook needs in your pyproject.toml file. They’ll be installed by Robusta.

Write a Playbook Action in Python:

let’s take an example of a Python playbook action in Figure J

Figure J:Action in python

You must package the code as a playbook repository and import it into Robusta. It’s time to load our playbook action.

Loading Playbook Repository

You have two options for loading your playbook:

  1. From a git repository
  2. Using robusta playbooks push

From a Git Repository:

  1. Git playbook loading via HTTPS

You can load your playbook action from the Git repository via HTTPS as shown in Figure K below:

Figure K:Loading playbook from git via HTTPS

  1. Git playbook loading via SSH

You can also load your playbook action from the Git repository via SSH as shown in Figure L below:

Figure L:Loading playbook from git via SSH

Using Robusta Playbooks Push:

In the Robusta configuration file, first allow persistent playbooks storage by setting the helm value as shown in figure M below.

Figure M:Enabling persistent volume

Once your repository is loaded, use the Robusta CLI and run the below command:

This mounts a persistent volume on the Robusta runner at /etc/robusta/playbooks/storage and copies the repository to it. Now that the actions in the repository are loaded, they can be used.

Using Your Custom Playbook Action

You can use your action once the playbook package has been loaded.

(generated_values.yaml). Below is Figure N showing how you can add a custom action in the Robusta configuration file.

Figure N:Adding our custom action in generated.yaml 

The action above receives a PodEvent. As a result, it can be used for pod-related triggers.


This blog delved into the workings of robusta custom playbook action, which forms an integral part of the infrastructure-as-code solution for monitoring and maintaining K8s applications, along with alert management. Just as Docker is a platform for deploying applications using infrastructure-as-code principles, Robusta applies the same approach to Kubernetes observability, enabling easier analysis of events and enabling actions to be taken more efficiently. With its capability to correlate events, Robusta simplifies the process of enhancing Kubernetes observability, reliability and streamlines the overall management of K8s applications.

We welcome your insightful comments and suggestions. Please share your thoughts in the section provided below if you found the blog useful. Furthermore, we’d like to know how useful Robusta was for you. More tutorials that explore Robust further will be released in the future!

About The Author(s)


Related Articles

Related Articles