Skip to main content

External Alert Ingestion

Lumetry can receive alarm state changes from monitoring systems such as Alertmanager, Grafana Alerting, and Zabbix, map them to topology, and correlate them with Lumetry-generated alerts.

External systems remain responsible for detecting the condition. Lumetry is responsible for normalizing the alarm identity, attaching service/CI context, tracking the operational alert, and correlating it into an incident.

State transitions, not polling​

An external alert source sends a webhook when an alarm enters Firing or Resolved. Repeated delivery is safe: Lumetry deduplicates provider events and applies lifecycle changes by occurrence.

Each transition carries two important identities:

  • Definition key: the stable provider-side alarm definition. This is what you map to a topology node.
  • Occurrence key: one firing-to-recovery lifecycle. A later recurrence uses a new occurrence key and creates a new operational alert.

Mapping alarms to topology​

An external alert definition connects one source and definition key to a Lumetry topology node. When a matching firing transition arrives, the operational alert inherits that topology context and enters the normal service/CI incident-correlation flow.

Transitions without a definition are retained as unmapped external alerts. They do not create operational alerts or incidents until an operator registers the definition and selects the affected topology node. If the latest retained state is still firing, Lumetry replays it after registration.

The source view shows the percentage and counts of processed events that matched a definition versus entering the unmapped queue.

Ingest health​

Each source reports:

  • the last successfully received event time;
  • accepted event and rejected request counts;
  • the most recent ingest error, cleared by the next successful webhook;
  • mapped and unmapped event counts with mapping coverage.

This allows operators to distinguish a silent source, a malformed integration, and an onboarding backlog without reading server logs.

Lifecycle ownership​

External monitoring remains authoritative for firing and recovery:

  • Firing opens or refreshes the occurrence.
  • Resolved closes the matching occurrence.
  • Operators may acknowledge the alert in Lumetry.
  • Operators cannot manually close an external alert; the source must send recovery.

External alerts appear in the same alert and incident views as metric-rule and fleet detector alerts.

Supported source types​

  • Generic webhook: sends Lumetry's canonical transition shape.
  • Alertmanager: normalizes the native webhook alert array.
  • Grafana Alerting: normalizes the default webhook contact-point payload.
  • Zabbix: normalizes trigger/problem and recovery event identities.

See External Alerts API for configuration and payloads.