Klaudia <> Datadog Integration

Overview

Klaudia is Komodor's AI SRE agent. The Datadog integration lets Klaudia pull observability context from your Datadog account during an investigation. As part of a chat or RCA session, Klaudia can trigger a dedicated Datadog agent that queries Datadog for the traces, metrics, logs, monitors, service dependencies, hosts, and incident context relevant to the issue, so its root cause analysis reflects your APM data alongside the Kubernetes and Komodor signals it already uses.

The integration connects to Datadog through Datadog's MCP server. Because of this, the Datadog Application key used by the integration needs a specific set of read scopes, including the mcp_read scope. See Required permission scopes below.

Note:

• Komodor AI SRE agent ('Klaudia') uses a large language model (LLM) to generate responses. LLMs have the potential to produce inaccurate responses. Always verify critical information before acting on it.
• The Datadog integration is read-only. Klaudia reads context from Datadog to inform its investigation. It does not modify your Datadog configuration.

How it works

1. Connect Datadog to Komodor using a Datadog API key and an Application key that carries the required scopes (steps below).
2. Klaudia investigates an issue as usual, from the Komodor UI, from Slack, or triggered automatically.
3. Klaudia triggers a dedicated Datadog agent when APM context would help the investigation. This happens as part of the chat or RCA session, alongside Klaudia's other specialized agents.
4. The Datadog agent queries your Datadog account through Datadog's MCP server for the relevant signals: APM traces and spans, metrics and timeseries, logs, monitors, the service catalog and service dependencies, hosts, and incidents.
5. Klaudia folds that context into its root cause analysis, so the conclusions and remediation guidance reflect what Datadog is seeing in addition to Komodor's own data.

What Klaudia can do with Datadog

How Klaudia uses Datadog during an investigation

The Datadog agent is context-gathering, not action-taking. During an investigation Klaudia uses it to answer questions that its Kubernetes and Komodor data alone cannot, for example whether latency traces back to a specific downstream service, what a service's spans show around the time of an incident, or which monitors and incidents were active. Queries are scoped to the services and time window relevant to the investigation, and everything the agent does is read-only.

Prerequisites

• A Komodor account with the Datadog integration installed.
• A Datadog API key and an Application key for the account you want Klaudia to investigate against.
• The required read scopes granted on the Application key, including mcp_read. See below.

The Datadog connection (MCP server)

Klaudia communicates with Datadog through Datadog's MCP server, not only through the plain Datadog REST data APIs. The MCP server exposes the tools the Datadog agent uses, and it enforces a broader set of permission scopes than the REST APIs alone.

One consequence is worth understanding, because it is the most common source of setup issues: an Application key can test successfully against Datadog's data APIs and still be rejected by the MCP server for certain tools if it is missing scopes. The usual symptom is an integration that works intermittently, where some requests succeed and others fail or time out with no obvious pattern. This almost always means the Application key is missing one or more required scopes, most importantly mcp_read.

Required permission scopes

Grant the following read scopes on the Datadog Application key tied to the Komodor integration. In Datadog, go to Organization Settings > Application Keys, select the key, and choose Edit scopes (or set them on that key's role).

Important note about Application key scopes: an Application key can only carry scopes that the user who created it holds in their own role. If a scope cannot be added to the key, the key needs to be created (or scoped) by a user or admin who holds those permissions.

Once the scopes are updated, nothing needs to be re-entered in Komodor. Let the Komodor team know and the integration will be re-verified on the Komodor side.

Installation and connecting Datadog

1. In the Komodor platform, go to Integrations.

   

2. Locate Datadog under Available Integrations and click Connect Integration.
3. Enter your Datadog API key and Application key.
   
4. Save the integration. Komodor verifies the connection and scopes.

Permission model

• Klaudia's actions are scoped to the invoking user's Komodor RBAC. Data the user is not authorized to see in Komodor is not surfaced.
• The Datadog integration is read-only. Klaudia can query your Datadog account for context but cannot modify Datadog configuration, monitors, or data.

Audit log

Klaudia's Datadog actions are recorded in the Komodor audit log, including:

• Action taken (for example "queried Datadog for APM context")
• The user whose investigation triggered the action
• Timestamp
• Triggered by: Klaudia or User

FAQ

The integration works, but only intermittently. Some requests succeed and others time out. Why? This is almost always a missing permission scope on the Datadog Application key. Klaudia talks to Datadog through Datadog's MCP server, which requires a broader set of scopes than the plain REST data APIs. A key can test fine against the data APIs while the MCP server rejects certain tools. Confirm all the scopes under Required permission scopes are granted, especially mcp_read.

Do I need to re-enter anything in Komodor after updating the scopes? No. Once the scopes are updated on the Datadog side, nothing needs re-entering in Komodor. Let the Komodor team know and the integration will be re-verified.

Does Klaudia change anything in my Datadog account? No. The integration is read-only. Klaudia reads context to inform its investigation and does not modify Datadog.

Why does the integration use Datadog's MCP server instead of the REST APIs? The MCP server exposes the tools the Datadog agent uses to gather context during an investigation. It enforces its own set of read scopes, which is why the Application key needs the full scope list above rather than only the data-API scopes.

I can't add a required scope to the Application key. What do I do? An Application key can only carry scopes that the user who created it holds in their own role. Ask a user or admin who holds the required permissions to create or scope the key.