datadog-mcp 5.8.0 → 5.8.2

package/README.md

@@ -8,30 +8,88 @@
 
 > **DISCLAIMER**: This is a community-maintained project and is not officially affiliated with, endorsed by, or supported by Datadog, Inc. This MCP server utilizes the Datadog API but is developed independently.
 
-MCP server providing AI assistants with full Datadog observability access. Features grep-like log search, APM trace filtering with duration/status/error queries, smart sampling modes for token efficiency, and cross-correlation between logs, traces, and metrics.
+MCP server providing AI assistants with full Datadog observability access. Features grep-like log search, APM trace filtering with duration/status/error queries, smart sampling modes for token efficiency, and cross-correlation between logs, traces, and metrics. Supports both `stdio` (local) and `http` (remote/Kubernetes) transports.
+
+## Quick Start
+
+Minimal Claude Desktop / VS Code / Cursor config — just the two required keys:
+
+```json
+{
+  "mcpServers": {
+    "datadog": {
+      "command": "npx",
+      "args": ["-y", "datadog-mcp"],
+      "env": {
+        "DD_API_KEY": "your-api-key",
+        "DD_APP_KEY": "your-app-key"
+      }
+    }
+  }
+}
+```
+
+With optional tuning (EU site, custom default limits, longer log windows):
+
+```json
+{
+  "mcpServers": {
+    "datadog": {
+      "command": "npx",
+      "args": ["-y", "datadog-mcp"],
+      "env": {
+        "DD_API_KEY": "your-api-key",
+        "DD_APP_KEY": "your-app-key",
+        "DD_SITE": "datadoghq.eu",
+        "MCP_DEFAULT_LIMIT": "50",
+        "MCP_DEFAULT_LOG_LINES": "200",
+        "MCP_DEFAULT_METRIC_POINTS": "1000",
+        "MCP_DEFAULT_TIME_RANGE": "24"
+      }
+    }
+  }
+}
+```
+
+To run as an HTTP server (e.g. inside a container or Kubernetes pod), add transport variables to the same `env` block:
+
+```json
+"env": {
+  "DD_API_KEY": "your-api-key",
+  "DD_APP_KEY": "your-app-key",
+  "MCP_TRANSPORT": "http",
+  "MCP_PORT": "3000",
+  "MCP_HOST": "0.0.0.0"
+}
+```
 
 ## Configuration
 
-### Required Environment Variables
+### Required environment variables
 
 ```bash
 DD_API_KEY=your-api-key
 DD_APP_KEY=your-app-key
 ```
 
-### Optional Environment Variables
+### Optional environment variables
 
 ```bash
 DD_SITE=datadoghq.com  # Default. Use datadoghq.eu for EU, etc.
 
-# Limit defaults (fallbacks when AI doesn't specify)
+# Limit defaults (fallbacks when the AI doesn't specify)
 MCP_DEFAULT_LIMIT=50              # General tools default limit
 MCP_DEFAULT_LOG_LINES=200         # Logs tool default limit
 MCP_DEFAULT_METRIC_POINTS=1000    # Metrics timeseries data points
 MCP_DEFAULT_TIME_RANGE=24         # Default time range in hours
+
+# Transport (alternative to CLI flags — useful in Kubernetes)
+MCP_TRANSPORT=stdio               # stdio | http
+MCP_PORT=3000                     # HTTP port
+MCP_HOST=0.0.0.0                  # HTTP host
 ```
 
-### Optional Flags
+### Optional flags
 
 ```bash
 --site=datadoghq.com     # Datadog site (overrides DD_SITE)
@@ -42,25 +100,16 @@ MCP_DEFAULT_TIME_RANGE=24         # Default time range in hours
 --disable-tools=synthetics,rum,security    # Comma-separated list of tools to disable
 ```
 
-## Usage
+## Transports
 
-### Claude Desktop / VS Code / Cursor
+| Transport | When to use | Endpoints |
+|-----------|-------------|-----------|
+| `stdio` (default) | Local MCP clients — Claude Desktop, Cursor, VS Code | n/a (process stdin/stdout) |
+| `http` | Remote / container / Kubernetes | `POST /mcp` · `GET /mcp` (SSE) · `DELETE /mcp` · `GET /health` |
 
-```json
-{
-  "mcpServers": {
-    "datadog": {
-      "command": "npx",
-      "args": ["-y", "datadog-mcp"],
-      "env": {
-        "DD_API_KEY": "your-api-key",
-        "DD_APP_KEY": "your-app-key",
-        "DD_SITE": "datadoghq.com"
-      }
-    }
-  }
-}
-```
+Select with `--transport=http` or `MCP_TRANSPORT=http`.
+
+## Deployment
 
 ### Docker
 
@@ -88,7 +137,7 @@ MCP_DEFAULT_TIME_RANGE=24         # Default time range in hours
 
 ### Kubernetes
 
-**Use environment variables instead of container args:**
+Use environment variables — not container args — for transport configuration:
 
 ```yaml
 env:
@@ -106,15 +155,6 @@ env:
 
 > **Note:** Kubernetes `args:` replaces the entire Dockerfile CMD, causing Node.js to receive the flags instead of your application. Environment variables avoid this issue.
 
-### HTTP Transport
-
-When running with `--transport=http`:
-
-- `POST /mcp` — MCP protocol endpoint
-- `GET /mcp` — SSE stream for responses
-- `DELETE /mcp` — Close session
-- `GET /health` — Health check
-
 ## Tools
 
 | Tool | Action | Category | Description | Required Scopes |
@@ -124,7 +164,7 @@ When running with `--transport=http`:
 | `monitors` | search | Alerting | Search monitors by query | `monitors_read` |
 | `monitors` | create | Alerting | Create a new monitor; `config` is validated against a typed schema covering documented options (notifyNoData, renotifyInterval, thresholds, …) — unknown keys surface in `warnings`. Pass `dry_run: true` to validate without creating (uses `/api/v1/monitor/validate`, allowed in read-only mode). | `monitors_write` |
 | `monitors` | update | Alerting | Update an existing monitor; same validated schema as `create`; partial configs accepted; validation errors short-circuit before any HTTP call as `EINVALID_MONITOR_CONFIG:` | `monitors_write` |
-| `monitors` | preview | Alerting | Render a monitor template (inline `message` or by `monitor_id`/`id`) with optional `context` of variables and conditionals. Returns `{rendered, variablesUsed, variablesMissing, conditionalsResolved}`. Supports Datadog Mustache subset: variable substitution + six documented conditionals (`is_alert`, `is_warning`, `is_no_data`, `is_recovery`, `is_alert_to_warning`, `is_warning_to_alert`); `{{#each}}`/partials throw `EUNSUPPORTED_TEMPLATE_SYNTAX`. Read-only. | `monitors_read` |
+| `monitors` | preview | Alerting | Render a monitor template (inline `message` or by `monitor_id`/`id`) with optional `context` of variables and conditionals. Returns `{rendered, variablesUsed, variablesMissing, conditionalsResolved, tagConditionalsResolved}`. Supports Datadog Mustache subset: variable substitution + six documented conditionals (`is_alert`, `is_warning`, `is_no_data`, `is_recovery`, `is_alert_to_warning`, `is_warning_to_alert`) + tag conditionals `{{#is_match "tag" "val"}}`/`{{#is_exact_match "tag" "val"}}` (and `^` negations); `{{#each}}`/partials throw `EUNSUPPORTED_TEMPLATE_SYNTAX`. Read-only. | `monitors_read` |
 | `monitors` | test_notification | Alerting | **Known limitation**: returns `ENOT_SUPPORTED` — Datadog has no public REST endpoint for triggering a test notification. Documentation pointer in response. | n/a |
 | `monitors` | delete | Alerting | Delete a monitor | `monitors_write` |
 | `monitors` | mute | Alerting | Mute a monitor | `monitors_write` |
@@ -147,7 +187,7 @@ When running with `--transport=http`:
 | `logs_archives` | list, get | Logs Config | Inspect log archives (S3 / GCS / Azure destinations); per-provider credential fields are forwarded unchanged | `logs_read_archives` |
 | `logs_archives` | create, update, delete, reorder | Logs Config | Manage archive destinations; `destination.type` validated against `s3 | gcs | azure_storage` before SDK call | `logs_write_archives` |
 | `logs_archives` | get_order | Logs Config | Read archive evaluation order | `logs_read_archives` |
-| `metrics` | query | Metrics | Query timeseries data. Response `meta` now includes `rollupRequested` (parsed from `rollup(method, seconds)` in the query, with `methodInferred` flag), `rollupEffective` (interval derived from returned pointlist intervals + deduped `intervalsObserved` for multi-series), and `rollupOverridden: boolean` so callers can detect when Datadog silently downsampled. | `metrics_read`, `timeseries_query` |
+| `metrics` | query | Metrics | Query timeseries data. Response `meta` includes `rollupRequested` (parsed from `rollup(method, seconds)`, with `methodInferred` flag), `rollupEffective` (interval derived from returned pointlist intervals + deduped `intervalsObserved` for multi-series), and `rollupOverridden: boolean` so callers can detect when Datadog silently downsampled. | `metrics_read`, `timeseries_query` |
 | `metrics` | search | Metrics | Search for metrics by name | `metrics_read` |
 | `metrics` | list | Metrics | List active metrics | `metrics_read` |
 | `metrics` | metadata | Metrics | Get metric metadata | `metrics_read` |
@@ -158,7 +198,7 @@ When running with `--transport=http`:
 | `events` | get | Events | Get event by ID | `events_read` |
 | `events` | create | Events | Create an event | `events_read` |
 | `events` | search | Events | Search events with v2 API and cursor pagination. Optional `transitionType` filter (e.g. `["alert","alert recovery"]`) restricts to monitor state-transition events — without it, `source:alert` includes renotifies. For monitor-specific fires use `monitors action=history`. Optional `timezone` adds `*Local` ISO 8601 siblings to every timestamp. Zero-result responses include a `diagnostics` array hinting at the cause (`UNINDEXED_TAG_PREFIX`, `NARROW_TIME_RANGE`, `RESTRICTIVE_SOURCE_FILTER`). | `events_read` |
-| `events` | histogram | Events | Server-side bucketing of events by `hour_of_day`, `day_of_week`, or `day_of_month` in an IANA `timezone` (DST-safe via `Intl.DateTimeFormat`). Cursor-paginates the underlying search; cap at `limits.maxEventsForHistogram` (default 5000, `MCP_MAX_EVENTS_HISTOGRAM` env var). When the cap is hit, returns `bucketCountIncomplete: true` and `nextCursor` for continuation. | `events_read` |
+| `events` | histogram | Events | Server-side bucketing of events by `hour_of_day`, `day_of_week`, or `day_of_month` in an IANA `timezone` (DST-safe via `Intl.DateTimeFormat`). Accepts the same `transitionType` filter as `search` so monitor histograms can exclude renotifies. Cursor-paginates the underlying search; cap at `limits.maxEventsForHistogram` (default 5000, `MCP_MAX_EVENTS_HISTOGRAM` env var). When the cap is hit, returns `bucketCountIncomplete: true` and `nextCursor` for continuation. | `events_read` |
 | `events` | aggregate | Events | Client-side aggregation by monitor_name, source, etc. | `events_read` |
 | `events` | top | Events | Top N event groups by count with generic groupBy support (deployments, configs, alerts, etc.). Groups without context tags are included as "no_context" | `events_read` |
 | `events` | timeseries | Events | Time-bucketed alert trends (hourly/daily counts) | `events_read` |
@@ -169,8 +209,8 @@ When running with `--transport=http`:
 | `incidents` | create | Incidents | Create an incident | `incident_write` |
 | `incidents` | update | Incidents | Update an incident | `incident_write` |
 | `incidents` | delete | Incidents | Delete an incident | `incident_write` |
-| `slos` | list | SLOs | List SLOs | `slos_read` |
-| `slos` | get | SLOs | Get SLO by ID | `slos_read` |
+| `slos` | list | SLOs | List SLOs. Each item exposes `query`, `monitorIds`, `monitorTags`, `groups`, and a UI `url` so round-trips (get → edit → update) preserve definition fields. | `slos_read` |
+| `slos` | get | SLOs | Get SLO by ID (same projection as `list`). | `slos_read` |
 | `slos` | create | SLOs | Create an SLO | `slos_write` |
 | `slos` | update | SLOs | Update an SLO | `slos_write` |
 | `slos` | delete | SLOs | Delete an SLO | `slos_write` |
@@ -223,11 +263,9 @@ When running with `--transport=http`:
 | `usage` | ingested_spans | Billing | Ingested spans usage | `usage_read` |
 | `auth` | validate | Auth | Test API and App key validity | — |
 
-## Token Efficiency
-
-### Limit Control
+## Limit Control
 
-AI assistants have full control over query limits. The environment variables set what value is used when the AI doesn't specify a limit. They do NOT cap what the AI can request.
+AI assistants have full control over query limits. The `MCP_DEFAULT_*` environment variables only set the fallback used when the AI doesn't specify a limit — they do NOT cap what the AI can request.
 
 | Tool | Default | Parameter | Description |
 |------|---------|-----------|-------------|
@@ -235,292 +273,22 @@ AI assistants have full control over query limits. The environment variables set
 | Metrics (timeseries) | 1000 | `pointLimit` | Data points per series (controls resolution) |
 | General tools | 50 | `limit` | Results to return |
 
-Defaults can be configured via `MCP_DEFAULT_*` environment variables:
-
-```json
-{
-  "mcpServers": {
-    "datadog": {
-      "command": "npx",
-      "args": ["-y", "datadog-mcp"],
-      "env": {
-        "DD_API_KEY": "your-api-key",
-        "DD_APP_KEY": "your-app-key",
-        "MCP_DEFAULT_LIMIT": "50",              // General fallback for most tools
-        "MCP_DEFAULT_LOG_LINES": "200",         // Logs search only
-        "MCP_DEFAULT_METRIC_POINTS": "1000",    // Metrics query timeseries only
-        "MCP_DEFAULT_TIME_RANGE": "24"          // Default time range in hours
-      }
-    }
-  }
-}
-```
-
-### Compact Mode (Logs)
-
-Use `compact: true` when searching logs to reduce token usage. Strips custom attributes and keeps only essential fields:
-
-```
-logs({ action: "search", status: "error", compact: true })
-```
-
-Returns: `id`, `timestamp`, `service`, `status`, `message` (truncated), `traceId`, `spanId`, `error`
-
-### Sampling Modes (Logs)
-
-Control how logs are sampled with the `sample` parameter:
-
-| Mode | Description | Use Case |
-|------|-------------|----------|
-| `first` | Chronological order (default) | Timeline analysis, specific events |
-| `spread` | Evenly distributed across time range | See patterns over time |
-| `diverse` | Deduplicated by message pattern | Error investigation (distinct error types) |
-
-Example - find distinct error patterns:
-```
-logs({ action: "search", status: "error", sample: "diverse", limit: 25 })
-```
-
-The `diverse` mode normalizes messages (strips UUIDs, timestamps, IPs, numbers) to identify unique error patterns instead of returning duplicates.
-
-## Events Aggregation
-
-### Top Monitors Report (Monitor-Specific)
-
-**Use `monitors` tool for monitor alerts with real monitor names:**
-
-```
-monitors({ action: "top", from: "7d", limit: 10 })
-```
-
-Returns monitors with **real names** (including {{template.vars}}) from monitors API:
-```json
-{
-  "top": [
-    {
-      "rank": 1,
-      "monitor_id": 67860480,
-      "name": "High number of ready messages on {{queue.name}}",
-      "message": "Queue {{queue.name}} has {{value}} ready messages",
-      "total_count": 50,
-      "by_context": [
-        {"context": "queue:email-notifications", "count": 30},
-        {"context": "queue:payment-processing", "count": 20}
-      ]
-    },
-    {
-      "rank": 2,
-      "monitor_id": 134611486,
-      "name": "Nginx some requests on errors (HTTP 5XX) on {{ingress.name}}",
-      "message": "Nginx request on ingress {{ingress.name}} contains some errors (HTTP 5XX)",
-      "total_count": 42,
-      "by_context": [
-        {"context": "ingress:api-gateway", "count": 29},
-        {"context": "ingress:admin-panel", "count": 13}
-      ]
-    }
-  ]
-}
-```
-
-### Top Events Report (Generic)
-
-**Use `events` tool for any event type** (deployments, configs, custom events):
-
-```
-events({ action: "top", from: "7d", limit: 10, groupBy: ["service"] })
-```
-
-Returns event groups by custom fields:
-```json
-{
-  "top": [
-    {
-      "rank": 1,
-      "service": "api-server",
-      "message": "Deployment completed",
-      "total_count": 30,
-      "by_context": [
-        {"context": "env:prod", "count": 20},
-        {"context": "env:staging", "count": 10}
-      ]
-    }
-  ]
-}
-```
-
-**Key Differences:**
-- `monitors top`: Fetches real monitor names from monitors API (slower, monitor-specific)
-- `events top`: Fast generic grouping, returns event message text (any event type)
-
-Context tags are auto-extracted: `queue:`, `service:`, `ingress:`, `pod_name:`, `kube_namespace:`, `kube_container_name:`
-
-### Tag Discovery
-
-Discover available tag prefixes in your alert data:
-
-```
-events({ action: "discover", from: "7d", tags: ["source:alert"] })
-```
-
-Returns: `{tagPrefixes: ["queue", "service", "ingress", "pod_name", "monitor", "priority"], sampleSize: 150}`
-
-### Custom Aggregation
-
-For custom grouping patterns, use `aggregate`:
-
-```
-events({
-  action: "aggregate",
-  from: "7d",
-  tags: ["source:alert"],
-  groupBy: ["monitor_name", "priority"]
-})
-```
-
-Supported groupBy fields: `monitor_name`, `priority`, `alert_type`, `source`, `status`, `host`, or any tag prefix
-
-The aggregation uses v2 API with cursor pagination to stream through events efficiently (up to 10k events).
-
-## Alert Trends (Timeseries)
-
-Visualize alert patterns over time with time-bucketed aggregation:
-
-```
-events({ action: "timeseries", from: "7d", interval: "1d" })
-```
-
-Returns hourly/daily alert counts grouped by monitor:
-```json
-{
-  "timeseries": [
-    { "timestamp": "2024-01-15T00:00:00Z", "counts": { "High CPU": 5, "Low Disk": 2 }, "total": 7 },
-    { "timestamp": "2024-01-16T00:00:00Z", "counts": { "High CPU": 3 }, "total": 3 }
-  ]
-}
-```
-
-| Interval | Use Case |
-|----------|----------|
-| `1h` | Recent incident analysis (default) |
-| `4h` | Daily patterns |
-| `1d` | Weekly trends |
-
-Combine with `groupBy` to see trends per monitor, source, or priority.
-
-## Incident Deduplication
-
-Consolidate noisy alert floods into logical incidents:
-
-```
-events({ action: "incidents", from: "24h", dedupeWindow: "5m" })
-```
-
-Groups repeated triggers within the dedupe window and pairs with recovery events:
-```json
-{
-  "incidents": [
-    {
-      "monitorName": "High CPU Usage",
-      "firstTrigger": "2024-01-15T10:00:00Z",
-      "lastTrigger": "2024-01-15T10:15:00Z",
-      "triggerCount": 4,
-      "recovered": true,
-      "recoveredAt": "2024-01-15T10:30:00Z",
-      "duration": "30m"
-    }
-  ],
-  "meta": { "totalIncidents": 15, "recoveredCount": 12, "activeCount": 3 }
-}
-```
-
-| Dedupe Window | Use Case |
-|---------------|----------|
-| `5m` | Flapping detection (default) |
-| `15m` | Alert storm consolidation |
-| `1h` | Incident grouping |
-
-## Monitor Enrichment
-
-Add monitor metadata to search results for deeper context:
-
-```
-events({ action: "search", tags: ["source:alert"], from: "1h", enrich: true })
-```
-
-Returns events with monitor details (type, thresholds, tags):
-```json
-{
-  "events": [{
-    "id": "...",
-    "title": "[Triggered on {host:prod-1}] High CPU Usage",
-    "monitorMetadata": {
-      "id": 12345,
-      "type": "metric alert",
-      "message": "CPU is above threshold",
-      "tags": ["team:platform", "env:prod"],
-      "options": { "thresholds": { "critical": 90 } }
-    }
-  }]
-}
-```
-
-Note: Enrichment adds latency (fetches monitor list). Use for detailed investigation, not bulk analysis.
-
-## Cross-Correlation
-
-### Logs → Traces → Metrics
-
-1. **Find errors in logs**: `logs({ action: "search", status: "error", sample: "diverse" })`
-2. **Extract trace_id** from log attributes (`dd.trace_id`)
-3. **Get full trace**: `traces({ action: "search", query: "trace_id:<id>" })`
-4. **Query APM metrics** (avg): `metrics({ action: "query", query: "avg:trace.express.request.duration{service:my-service}" })`
-5. **Query APM latency percentiles** (p95): `metrics({ action: "query", query: "p95:trace.express.request{service:my-service}" })` — note: use root metric without `.duration` suffix for percentiles
-
-## Deep Links
-
-All query responses include a `datadog_url` field that links directly to the Datadog UI, allowing AI assistants to provide evidence links back to the source data.
-
-### Example Response
-
-```json
-{
-  "logs": [...],
-  "meta": {
-    "count": 25,
-    "query": "service:api status:error",
-    "from": "2024-01-15T10:00:00Z",
-    "to": "2024-01-15T11:00:00Z",
-    "datadog_url": "https://app.datadoghq.com/logs?query=service%3Aapi%20status%3Aerror&from_ts=1705312800000&to_ts=1705316400000"
-  }
-}
-```
-
-### Supported Tools
+Tool-level token reduction features (`compact: true` on logs, `sample: "diverse" | "spread" | "first"`, field projections, diagnostics) are surfaced in each tool's MCP description and chosen by the AI at call time.
 
-| Tool | URL Type |
-|------|----------|
-| `logs` | Logs Explorer with query and time range |
-| `metrics` | Metrics Explorer with query and time range |
-| `traces` | APM Traces with query and time range |
-| `events` | Event Explorer with query and time range |
-| `monitors` | Monitor detail page (get) or Manage Monitors (list/search) |
-| `rum` | RUM Explorer or Session Replay |
+## Notable behaviors
 
-### Multi-Region Support
+A handful of patterns worth knowing about — the AI can discover the rest from tool descriptions.
 
-URLs are automatically generated for your configured Datadog site:
+- **Renotifies vs real fires.** `monitors top` and `events search` with `source:alert` count every renotify Datadog emits (one every `renotify_interval` while a monitor is Alert). To get actual state transitions, use `monitors history` (defaults to `transitionType: ["alert","alert recovery"]`) or pass `transitionType` to `events search`.
+- **DST-safe time buckets.** `events histogram` buckets by `hour_of_day` / `day_of_week` / `day_of_month` in any IANA `timezone` via `Intl.DateTimeFormat`. Cursor-paginates the underlying search; cap controlled by `MCP_MAX_EVENTS_HISTOGRAM` (default 5000) with `bucketCountIncomplete` + `nextCursor` on overflow.
+- **Validate before create.** `monitors create` with `dry_run: true` calls `/api/v1/monitor/validate` instead of persisting. Allowed in `--read-only` mode.
+- **Monitor template preview.** `monitors preview` renders a notification against a `context` payload — variable substitution + Datadog's six documented conditionals (`is_alert`, `is_warning`, `is_no_data`, `is_recovery`, `is_alert_to_warning`, `is_warning_to_alert`) + the tag conditionals `{{#is_match "tag" "val"}}` (substring) and `{{#is_exact_match "tag" "val"}}` (exact), with `^` negations and OR'd multiple comparison values (resolved against `context.variables`; case-sensitive). `{{#each}}` and partials throw `EUNSUPPORTED_TEMPLATE_SYNTAX`.
+- **SLO round-trip.** `slos get` projects `query`, `monitorIds`, `monitorTags`, `groups`, and a UI `url` so you can edit and feed back into `slos update` without dropping definition fields.
+- **Cross-correlation.** `logs(sample:"diverse")` → pull `dd.trace_id` → `traces(query:"trace_id:<id>")` → `metrics(query:"p95:trace.express.request{service:...}")` (root metric without `.duration` for percentiles).
 
-| Site | App URL |
-|------|---------|
-| `datadoghq.com` (default) | `https://app.datadoghq.com` |
-| `datadoghq.eu` | `https://app.datadoghq.eu` |
-| `us3.datadoghq.com` | `https://us3.datadoghq.com` |
-| `us5.datadoghq.com` | `https://us5.datadoghq.com` |
-| `ap1.datadoghq.com` | `https://ap1.datadoghq.com` |
-| `ddog-gov.com` | `https://app.ddog-gov.com` |
+## Deep links
 
-Configure your site via the `DD_SITE` environment variable or `--site` flag.
+Every query response includes a `datadog_url` field built for your configured `DD_SITE` — `datadoghq.com` (default), `.eu`, `us3` / `us5` / `ap1.datadoghq.com`, or `ddog-gov.com`. Supported on `logs`, `metrics`, `traces`, `events`, `monitors`, `rum`, `slos`.
 
 ## Contributing