Getting started with Keep — Observability Alerting with ease
TL;DR:
Creating and maintaining effective alerts, avoiding alert fatigue, and promoting a strong alerting culture can be difficult tasks. Keep addresses these challenges by treating alerts as code, integrating with observability tools, and using LLMs. \
Culled from Keep
Observability is the ability to measure a system’s current state based on the data it generates such as logs, metrics, and traces. It is important for a number of reasons, including identifying problems early on, tracking performance over time, and troubleshooting problems. Observability has become more critical in recent years as engineering environments have gotten more complex.
It is important to have a good understanding of the system being monitored. This knowledge can help engineers to interpret the data collected by monitoring tools and tracing tools.
Alerting allows engineers to be notified of potential problems before they cause major disruptions. By monitoring system metrics and logs, engineers can identify trends that may indicate an impending failure. When these trends are detected, alerts can be sent to engineers so that they can take corrective action before the problem escalates.
For example, an alert could be triggered if a system’s CPU usage exceeds a certain threshold. This would alert engineers that the system is under heavy load and that they may need to scale it up or down to improve performance.
Where does Keep fit in?
Keep, a developer tool that treats alerts as a workflow and integrates with existing observability tools. With Keep, you can manage your alerts just as you manage your tests — stored in the application repository and integrated with your CI/CD.
Getting started with Keep using Docker
The Keep team has some alerts examples already, and we will be running the alerts in this blog. You can check them out on GitHub.
We will use Slack as our provider for this demo:
A provider in this instance is a Keep term for data source
docker run -v ${PWD}:/app -it keephq/cli config provider - provider-type slack - provider-id slack-demo
Config file: providers.yaml
Slack f Url:https://hooks.slack.com/services/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
Note: At the time of reading this blog post, the Slack Webhook Url might have changed, so it’s important you check the KeepHQ Slack for an updated webhook URL
If your Slack webhook URL is correct, you should get a config file success message
You can check out KeepHQ Slack on how to obtain a demo webhook URL.
docker run -v ${PWD}:/app -it keephq/cli config provider - provider-type slack - provider-id slack-demo
Config file: providers.yaml
Slack Webhook Url: https://hooks.slack.com/services/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
Config file created at providers.yaml
If you’re using a Docker desktop, you can see keephq/cli
image in your containers list.
To run your first alert, you can add this to your cli
docker run -v ${PWD}:/app -it keephq/cli -j run - alert-url https://raw.githubusercontent.com/keephq/keep/main/examples/alerts/db_disk_space.yml
Below is a view of the cli output after running the command above.
You have successfully executed Keep demo example “Paper DB has insufficient disk space” alert.
You can check Keep Slack alerts-playground if you used Keep Webhook Url as used in this article.
Congratulations on your first alert!
“I’m Daniel Olabemiwo, a Software Engineer passionate about building high-quality software that solves real problems. I’m also a strong believer in open source software and I enjoy contributing to open source projects.”