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 NameTypeExample
summarytextCPU Utilization Spiking
bodytextThe production server is experiencing greater than 99% utilizations of compute.
statusenumEither OPEN (0) or CLOSED (1)
levelenumAny of:

- INFO (0)
- WARN (1)
- ERROR (2)
- FATAL (3)
annotationsobject{ “randomNumber”: 1234 }
imagesarray[ { "src": "https://site.com/images/123.png', "alt": "A simple, sample image" } ]
linksarray[ { "href": "https://site.com/monitors/123', "text": "Monitoring Source" } ]
tagsarray["tag1", "service:your-service-slug", "environment:production"]
idempotency_keytextA unique identifier used to group/deduplicate open alerts

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 idempotency_key has been resolved or dismissed, 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.

Where to find the slug on a component's details page

Where to find the slug on a component's details page

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"],
}