DataDog

The DataDog integration treats DataDog as a system that detects for itself: ISE ingests DataDog’s own monitor alerts as signals rather than re-analysing raw metrics. Hosts and services are discovered into the estate, and metrics, logs, and events are available as on-demand evidence during an investigation — never polled speculatively.

Capabilities

Discovery. Hosts and APM services are enumerated into the estate as entities, carrying their DataDog tags into ISE’s unified tag pool with per-integration provenance. Cross-source identity resolution joins them onto entities known from other integrations (for example an EC2 host discovered by the AWS integration).

Alerts. ISE polls monitor state and raises an alert signal per firing monitor group. The alert’s tags are the monitor’s own tags plus scope tags derived from the firing group, so signals participate in tag-derived groups and estate context like everything else. When the monitor group recovers in DataDog, the signal recovers in ISE and its incident resolves through the ordinary recovery path.

Ignore rules. Whole classes of alert can be dropped at ingest — before a signal is ever created — with integration-scoped tag rules (key:value, OR of exact matches, case-insensitive). Use these for environments you have disowned (for example env:sandbox): matched alerts never enter ISE, and previously-ingested signals they cover recover naturally on the next sync. The integration screen previews how many current alerts a rule would ignore before you save it.

Evidence. During an incident investigation, ISE can query metrics, search logs, search events, and list active metrics on demand. Evidence is fetched when an investigation asks for it and recorded against the incident — nothing is streamed in the background.

Actions. The governed catalogue, each through the tiered approval pipeline:

Action	Tier	Notes
ack_event	T0	Posts a correlated acknowledgement event; the event stream is append-only, so this is additive and cannot be undone.
mute_monitor	T1	Implemented as a scoped DataDog downtime; a duration is required and capped at one week, so a mute always expires.
unmute_monitor	T1	Cancels the monitor’s active downtimes.
set_host_tag	T1	Writes a tag at the source — keeps DataDog, not ISE, the owner of tag truth.
edit_monitor	T2	Changes the monitor definition; requires approval.

Where DataDog’s write model lacks a primitive (there is no native “mute” or “ack”), the action does what the table says and nothing more — ISE never invents an operation the system doesn’t have.

Setup

1. In DataDog, create an API key and an application key. For a read-only deployment the application key needs only read scopes: monitors_read, dashboards_read, metrics_read, events_read, apm_service_catalog_read.
2. In ISE, add a DataDog integration (Settings → Integrations) and supply the API key, application key, and your DataDog site (e.g. datadoghq.com, datadoghq.eu). Credentials are encrypted at rest and redacted from logs; they are never shown again after entry.
3. The connection health check runs immediately and the System card shows status and last sync. Monitors sync on a short interval (about every two minutes) by default.
4. Optionally add ignore rules on the integration screen for alert classes that should never reach ISE.

Actions use the same credential; grant write scopes only if you intend to enable the action catalogue.

Examples

A monitor alert becomes an incident. A CPU monitor fires for the group host:web-01. ISE ingests an alert signal keyed to that monitor group, attributes it to the web-01 host entity (joined with its AWS/Kubernetes identities if present), maps the monitor severity onto the canonical ladder, and — above the auto-incident threshold — opens an incident with the alert attached.

Evidence during investigation. Investigating that incident, ISE (or you) pulls the relevant CPU metrics series and searches recent logs for the host on demand. The queries and their results are recorded on the incident as evidence.

Silencing a noisy class. Sandbox monitors keep alerting. Add the ignore rule env:sandbox on the DataDog integration: new matching alerts are dropped at ingest and the existing ones recover on the next sync — no per-signal muting, and the rule is audited on the System.