A way to integrate AIOps with your infrastructure

The real test for AIOps comes when you try to integrate it with your existing systems – each with its own unique constraints and requirements. While developing Keep, we encountered this challenge and developed a solution: a workflow engine that brings unprecedented flexibility to system integration.

Imagine these common scenarios:

• Your team needs a custom ServiceNow integration that goes beyond basic ticket creation.
• Your support team manages incidents in Jira, and you need bidirectional synchronization with Keep to prevent duplicates.
• You want to configure PagerDuty notifications based on customer tier data stored in MySQL.
• ... and countless other unique integration requirements that arise in complex environments

In this guide, we'll cover the core concepts and build a first working Workflow together.

It’s a technical quick run with an ETA of about 10 minutes.

I like thinking of workflows as a glue that helps with Keep’s integration. Others say it’s helping to thread the needle — carefully weaving it into your organization's existing systems. Whatever metaphor works best for you, we needed one as a reason to put an image to the blog post 🤭

YAML, a nature of the workflow

The first thing you notice once you open a workflow in Keep is a UI builder, but it’s essential to know that every change you will make there is reflected in the underlying YAML and vice versa. 

Yes, we did it to simplify managing Workflows via code.

Quick syntax overview

In this tutorial, we will focus on building workflows using YAML. Don’t worry! The syntax is simple.

Btw, the full workflow syntax is documented here: https://docs.keephq.dev/workflows/overview 

Triggers:

This section is simple, examples speak for themselves:

Steps, Actions, and Their Relationships with Providers

Following triggers, there are two sections:

1. Steps: for querying data. 
2. Actions: for triggering 3rd party, notifying, etc…

In those two sections, workflows leverage installed providers. Notice {{ providers.click }}:

Here, the workflow uses the provider with id = click to make a query. This allows workflows to be stored as code without secrets because the username, password, and host are properties of the provider.

Now, take a look at the “with” section. It will be different for each step and action depending on the provider. Check provider documentation or the massive list of workflow examples at GitHub.

And lastly, let’s take a look at the data flow between steps using this example:

Notice {{ steps.clickhouse-step.results.something }} being re-used in the ntfy-action.

Getting practical: workflow debug loop.

Let’s talk briefly about the practical approach to debugging workflows and ensuring they work nicely.

I use VS Code to create a .yml file locally (file):

‍

As the next step, I copy large pieces of code from examples.

To upload workflows to Keep from the local machine, I use Keep CLI. It makes the iteration much quicker, so I highly suggest spending a few minutes to install and configure it first:

1. Install using this manual: https://docs.keephq.dev/cli/installation 
2. Go to Keep -> Settings -> API Keys, issue one
3. Use “keep config new” to add the key to the CLI https://docs.keephq.dev/cli/commands/cli-config-new#cli-help (check & edit ~/.keep.yaml file if smth is not working for you here).

Once you have Keep CLI, use this command to upload the workflow:

keep workflow apply -f ../matvey/mongo_workflow.yaml

‍

Finally, I suggest using UI to Run the workflow manually:

That’s all. Now, you are ready to write your first workflow 🎉

One last step left is to join our Slack, where our team is helping those adopting Keep: https://slack.keephq.dev/  We will be super happy to learn more about your use case!