HONEYCOMB WITH SWAMP

The @hivemq/honeycomb extension provides this. It contains two behavior types:

• @hivemq/honeycomb works with one dataset at a time, set by the datasetSlug global argument. Its methods create and update SLOs and SLI derived columns, add and remove exhaustion-time and budget-rate burn alerts, create queries and query annotations, and create, refresh, update and delete triggers.
• @hivemq/honeycomb/datasets works across a whole team. Its methods find datasets that have had no writes for a given number of days, or whose names match pentester probe patterns. It can list them for review or delete them.

Both types authenticate with a Honeycomb Configuration Key, which is sent as the X-Honeycomb-Team header, and a region argument that selects the us or eu instance. The key is kept in a vault and referenced with ${{ vault.get('honeycomb', 'config-key') }}, so it does not appear in any behavior definition. Storing Secrets covers how vaults work.

Each run records what it changed as a resource, for example slo, derivedColumn, burnAlert, trigger or datasetCleanupRun. You can query these resources as Swamp data. Later runs also read them: the burn alert delete methods get the alert ID from the stored burnAlert resource, and the SLO ID that createSlo returns is kept in the slo resource.

To start, follow the getting started tutorial. It creates a derived column and a 99.9 percent SLO for a checkout dataset. Once an SLO exists, you can add burn rate alerts to it. Query thresholds use triggers. Unused datasets are removed with the dataset cleanup guide. Some methods can safely run more than once and some cannot. Understanding Honeycomb automation in Swamp explains why and how the methods fit into workflows.