Exporting Metrics & Data via Prometheus
This page describes the v1 version of the Prometheus exporter. If you are just starting with our Prometheus integration, we recommend using our v2 version.
💡 Check out our blog post on using this integration with Prometheus and Grafana for some cool real-life applications.
Checkly exposes the following metrics in a Prometheus-compatible format.
Metric | Description |
---|---|
checkly_check_status |
Whether a check is passing or failing. 1 means the check is passing, 0 means the check is failing. |
checkly_check_degraded_status |
Whether a check is degraded. 1 means the check is not-degraded, 0 means the check is degraded. |
checkly_check_result |
The last collected response time for a check in a specific region. This means you get one checkly_check_result stanza for each region the check is configured to run in. |
checkly_private_location_queue_size |
The number of check runs scheduled to a private location and waiting to be executed. In particular, this metric reports the maximum count of scheduled check runs over the past 10 minutes. |
checkly_private_location_oldest_scheduled_check_run |
The age in seconds of the oldest scheduled job in the private location’s queue. In particular, this metric reports the maximum age from the past 10 minutes. |
checkly_private_location_agent_count |
The number of connected Checkly Agents connected for a private location. An Agent is considered as connected if it’s communicated with the Checkly infrastructure in the past 10 minutes. |
Each checkly_check
metric has the following labels:
check_name
, the name of your check.check_type
, eitherapi
orbrowser
.tags
, this check’s tags.
You can set key:value
tags in your checks/groups and they will be exported as custom labels in Prometheus. For instance the tag env:production
will be exposed as a custome label env="production"
. You can disable this by adding the query param disableTagParsing=true
.
The checkly_private_location
metrics contain the labels:
private_location_name
, the name of the private location.private_location_slug_name
, the private location’s human readable unique identifier.private_location_id
, the private location’s UUID.
If a private location has no check runs for six hours, it will be considered inactive and checkly_private_location
metrics won’t be reported for it.
Here is an example:
Notice that:
- The check for “Email login” is failing.
- The check for “Customer API” is degraded, but not failing.
- The
checkly_check_status
metric hasmuted
andactivated
labels, reflecting if a check is sending out alerts or is actually running. - The
checkly_check_result
metric has aregion
label. - The private location “Internal CI” has one Checkly Agent connected. From
checkly_private_location_queue_size
andcheckly_private_location_oldest_scheduled_check_run
, we see that there’s no backlog of check run jobs.
Activating this integration is simple.
-
Navigate to the integrations tab on the account screen and click the ‘Create Prometheus endpoint’ button.
-
We directly create an endpoint for you and provide its URL and the required Bearer token.
-
Create a new job in your Prometheus
prometheus.yml
config and set up a scraping interval. We recommend an interval between 30 seconds and 60 seconds. Add the URL (divided intometrics_path
,scheme
andtarget
) andbearer_token
. Here is an example
Now restart Prometheus and you should see metrics coming in.
Last updated on December 13, 2024. You can contribute to this documentation by editing this page on Github