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.
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.
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.
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.
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-demoConfig file: providers.yamlSlack 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-demoConfig file: providers.yamlSlack 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.
Alert on KeepHq slack channel.
Congratulations on your first alert!
.png)
