Events Data Model
Signals Events are stored in FireHydrant when a webhook is sent to FireHydrant that matches the correct data model. This guide will help you understand the data model that FireHydrant uses to define Events.
Data Model
Field Name | Type | Example |
---|---|---|
summary | text | CPU Utilization Spiking |
body | text | The production server is experiencing greater than 99% utilizations of compute. |
status | enum | either OPEN or CLOSED |
level | enum | any of INFO , WARN , ERROR , FATAL |
annotations | object | { “randomNumber”: 1234 } |
images | array | [ { "src": "https://site.com/images/123.png', "alt": "A simple, sample image" } ] |
links | array | [ { "href": "https://site.com/monitors/123', "text": "Monitoring Source" } ] |
tags | array | ["tag1", "service:your-service-slug", "environment:production"] |
Understanding the Idempotency Key
The idempotency_key
is FireHydrant's way of identifying incoming events that need to be grouped together. For instance, if your monitoring tool sends two webhooks to FireHydrant with a matching idempotency_key
, Signals will not create a new alert if an alert is already Open. If an alert from an event with that idempotentcy
has been acknowledged, Signals will create a new one.
Another use of the idempotency_key
grouping is to auto-resolve flappy alerts. If your monitoring tool sends an OPEN
and then CLOSED
event to FireHydrant, the system will auto-resolve any alerts that were generated from the original event.
Tags and the Service Catalog
Using the service-tagging convention, you can automatically associate any Service Catalog component with your alerts and the incidents that get opened from those alerts.
To reference a service, use the service:
prefix combined with the slug of your service in FireHydrant. These slugs can be found in your Service Catalog on each respective component's page in the Details section.
For example, let's take a service called API Gateway
with a slug of api-gateway
. It is in the Production
environment (slug production
) that has associated functionality called Public API
with a slug of public-api
.
The tags to automatically pull these components in would be: service:api-gateway
, environment:production
, and functionality:public-api
. When you include a catalog component in your payload, any incidents that are opened from Alerts created by that payload will automatically mark those catalog components as impacted when the incident is opened. Below is the example payload:
{
"summary": "CPU Utilization Spiking",
"body": "The production server is experiencing greater than 99% utilizations of compute.",
"level": "ERROR",
"status": "OPEN",
"idempotency_key": "ad98rb3b2b",
"images": [
{
"src": "https://site.com/images/123.png",
"alt": "A simple, sample image"
}
],
"links": [
{
"href": "https://site.com/monitors/123",
"text": "Monitoring Source"
}
],
"annotations": {
"policy": "escalatable"
},
"tags": ["service:api-gateway", "environment:production", "functionality:public-api", "random-tag"],
}
Updated 3 days ago