Use Datadog with Sazabi: Agent logs, MCP tools and the pup CLI

Last verified on Nov 8, 2026.

Datadog holds a lot of what you already know about production: logs from the Agent, monitors, dashboards, incidents and APM data. Sazabi, the AI-native observability and security platform, can use Datadog in three separate ways. It can receive the Agent's logs, it can query Datadog through the hosted MCP server, and it can run the pup CLI in its sandbox.

You pick the methods you need. Connecting one does not turn on the others.

What each source sends

Datadog Agent logs. The Agent forwards its logs pipeline to your Sazabi intake. In dual-ship mode Sazabi is an extra endpoint under logs_config.additional_endpoints. In Sazabi-only mode a dedicated Agent or sidecar sets DD_LOGS_CONFIG_LOGS_DD_URL. Sazabi keeps message, status, timestamp, hostname, service and tags. Datadog's own docs call host, source, status, service, trace_id and message reserved attributes, so a service that already tags logs for Datadog arrives with the same labels. Metrics and APM traces are not forwarded by this source.

MCP connector. Datadog runs a hosted MCP server. Sazabi stores your API key and Application Key and sends them as DD_API_KEY and DD_APPLICATION_KEY headers. It builds the endpoint from your site URL, such as https://us3.datadoghq.com, so the agent reaches the right region. The agent can query metrics, logs and distributed traces, browse monitors, dashboards and alert policies, search and manage incidents, and read APM service maps.

Sandbox CLI. The pup command ships in the agent's sandbox. You supply DD_API_KEY and DD_APP_KEY, plus DD_SITE if your account is outside datadoghq.com. The agent can then run pup to check credentials and query your account.

Questions it answers

• Which Datadog monitor was in alert when this error rate started?
• Does the service tag on these logs match the service in Datadog's APM service map?
• What changed in Datadog incidents on the same day as this deploy?
• Are the logs reaching Datadog and Sazabi with the same status values?
• Which dashboards does the team already use for this service?

A worked example: one log line, two destinations

You run the Agent in dual-ship mode and want to confirm both copies match. Datadog's transport docs say the Agent sends HTTPS batches of up to 1,000 logs, 1MB per batch and 900kB per log, on port 443. A line that stays under those limits shows up in Sazabi like this:

{
  "message": "payment declined: card_expired",
  "status": "error",
  "timestamp": "2026-11-08T14:02:11Z",
  "hostname": "ip-198-51-100-24",
  "service": "checkout-api",
  "tags": ["env:prod", "version:4.12.0"]
}

Ask Sazabi about it from the CLI:

sazabi logs ask "Show checkout-api error logs from the Datadog Agent source in the last hour, grouped by tag"

If service or tags look wrong, the fix is on the Agent side, because Sazabi preserves what the Agent sends. If logs are missing, check that additional_endpoints is nested under logs_config. A YAML indentation slip makes the Agent skip the extra endpoint without an error. Once the logs match, ask the agent in a thread whether a Datadog monitor fired for checkout-api in the same window. That question uses the MCP connector, not the log source.

How it fits with other integrations

Datadog logs often travel with other collectors. If you already run a pipeline, see Vector or Fluent Bit for the same logs without the Agent. The OpenTelemetry path works for services you instrument directly. For other tools in this space, browse observability tools or the full integrations list. See pricing for plan details.