Export to SIEM

How MCP Manager forwards structured MCP request logs to any OpenTelemetry (OTLP/HTTP) collector or SIEM — what gets sent, how to set the collector URL and request headers, how to verify delivery, and how to troubleshoot export failures.

MCP Manager records every request and response that flows through your MCP gateways as logs, and can forward those logs to your own observability or SIEM (Security Information and Event Management) platform over OpenTelemetry (OTEL). Once forwarding is configured, MCP Manager streams each log record to an OTLP/HTTP endpoint you supply — so you can correlate MCP tool usage with the rest of your operational data, build dashboards, and keep a single audit trail across your stack.

A SIEM (Security Information and Event Management) system — such as Splunk, Microsoft Sentinel, or Elastic Security — centralizes security logs for monitoring, alerting, and compliance. The term is sometimes misheard or mistranscribed as “SIM”; if you came here looking for a “SIM” integration, this is the page you want.

MCP Manager sends to any backend that speaks OTLP/HTTP with JSON-encoded log records: Grafana Cloud, New Relic, Honeycomb, Datadog, your own OpenTelemetry Collector, or anywhere else with an OTLP logs intake. Each MCP Manager organization forwards to one collector.

Export to SIEM is an Enterprise capability, and configuring it is gated by the Manage OpenTelemetry collector capability. If you do not see a Logging → Integrations tab at Logs → Integrations, or you see only a promotional panel instead of the configuration form, then either your plan does not include the OpenTelemetry integration or your role lacks the capability. See Who can set up log export.

What MCP Manager sends to your collector

For every MCP request that flows through an MCP Manager gateway, MCP Manager emits structured OTLP log records describing that request. The full record carries the same data you see on the Viewing Logs page, including:

• Timing — durations for the client-facing leg and each upstream MCP server leg.
• Who — the acting user’s email and name, plus the organization and team.
• What — the JSON-RPC method, the MCP feature type and feature name, the tool or resource involved, and the inbound server name and URL.
• How much — estimated token counts, HTTP response codes, and durations.
• Correlation — a correlation_id shared across the (typically four) records that make up one message, so you can reconstruct a single interaction end-to-end. See Log types and the correlation model.

Records are sent as OTLP/HTTP, JSON-encoded log records to the endpoint you configure. Every record also carries two OpenTelemetry resource attributes that identify the source: service.name (in production, mcp-manager) and service.version (1.0.0). Use these to filter MCP Manager’s logs in your backend — they are also shown to you in the configuration panel after you save (see Verify that logs are flowing).

MCP Manager forwards log records as they are produced; it does not filter or mask them based on your gateway rules. If a request or response contains PII or other sensitive data, that data is logged and forwarded to your collector even when a rule blocks or masks it elsewhere. Confirm that your collector is a secure, compliant destination before connecting it.

Set up the OpenTelemetry collector

You configure forwarding from the Integrations tab of the Logging section. You need two things from your collector or backend: the collector URL and any request headers it requires for authentication.

MCP Manager sends to the collector URL exactly as you enter it — nothing is appended. You must paste the full signal path (for most backends, the part ending in /v1/logs), not a base URL. Pasting a base URL and expecting MCP Manager to add /v1/logs is the single most common setup mistake, and it results in a 404 on every export. Confirm the exact, complete URL with your provider.

1. Open the OpenTelemetry collector settings

   Go to Logs → Integrations and find the OpenTelemetry collector panel. If the tab or panel is not visible, see Who can set up log export.

2. Enter the collector URL

   In Collector URL, paste the full HTTPS endpoint for your OTLP logs intake, including the complete signal path. For example:

   https://<your-otlp-host>/v1/logs
   

   Replace <your-otlp-host> with the host (and port, if required) from your provider. MCP Manager sends to this URL verbatim — if your provider’s documented OTLP logs URL ends in /v1/logs (or a vendor-specific path such as Grafana Cloud’s /otlp/v1/logs), include that path here.

3. Add request headers

   Under Request headers, add the header name/value pairs your collector expects for authentication. Each row has a header field name and a field value — for example an Authorization header with the value Bearer <your-token>, or a vendor-specific header such as New Relic’s api-key. Because the headers are an open key/value list, MCP Manager supports both standard Authorization schemes and custom headers. Add as many pairs as your backend requires; leave the section empty only if your collector accepts unauthenticated traffic. Each pair must have both a name and a value, or both blank.

4. Save the configuration

   Select Save. MCP Manager stores the collector URL and headers (the header values are encrypted at rest and are not shown back to you in plaintext) and confirms that the configuration was saved.

   A confirmation appears and the panel switches to a read-only view showing your collector URL and the header names you configured.

   Saving only stores the configuration — it does not verify that logs reach your collector. A saved configuration is not proof that logs are flowing. Continue to Verify that logs are flowing.

Verify that logs are flowing

Saving the configuration confirms only that MCP Manager stored it, not that records are successfully reaching your collector. To verify actual delivery:

1. Trigger an MCP call

   From any connected MCP client (Claude, Claude Code, Cursor, ChatGPT, and so on), make any call through one of your gateways. A tools/list call is a safe choice. A single MCP message produces several log records — at minimum a proxy_request_success and a proxy_response_success — that should now export to your collector.

2. Filter your backend by the service name

   After saving, the OpenTelemetry collector panel shows a Filter your logs by section listing the exact service.name and service.version MCP Manager is sending (in production, mcp-manager and 1.0.0). Use those values to filter in your logs backend. The OTLP service.name resource attribute typically surfaces as a service_name field or label in your backend.

3. If nothing arrives, check Alerts first

   If no records appear, open Alerts in MCP Manager. Export failures surface there as a warning-level alert before anything else — see Where export failures surface. If there is no alert, work through Troubleshooting.

Per-vendor setup guides

The exact endpoint URL, the authentication header, and where to find your logs differ by backend. Use the vendor guide for your platform:

New Relic

A License (ingest) key and the api-key header; query with NRQL.

Grafana Cloud

The /otlp/v1/logs gateway and an instance-ID/token Basic header; logs land in Loki.

Datadog

The per-site OTLP endpoint and the dd-api-key header; verify JSON acceptance.

Honeycomb

The US or EU endpoint and the x-honeycomb-team ingest key.

Splunk Observability Cloud

No OTLP logs intake — requires a Collector to translate to Splunk HEC.

Self-hosted Collector

The universal fallback: receive OTLP logs and forward to any backend.

Not every observability platform accepts OTLP logs directly. Splunk Observability Cloud, for example, has no OTLP logs intake at all — it accepts only OTLP traces and metrics — so forwarding MCP Manager logs to it requires an OpenTelemetry Collector in front to translate OTLP logs into Splunk’s HEC format (see the Splunk Observability Cloud guide). When a backend cannot accept OTLP/HTTP logs natively, point MCP Manager at your own self-hosted Collector and forward onward from there.

Troubleshooting

Before diving into vendor-specific details, rule out the most common causes. Export failures almost always come down to the URL path or the authentication header.

404 Not Found — the URL is missing a path segment

Because MCP Manager appends nothing to the collector URL, a 404 almost always means the path is incomplete. A stock OTLP/HTTP receiver accepts logs at /v1/logs, but many hosted backends mount the OTLP endpoint under a prefix — for example Grafana Cloud uses /otlp/v1/logs. Confirm the exact, complete URL with your provider and paste it in full. Whatever they tell you to put in an OTLP exporter’s url field is what belongs in Collector URL.

401 Unauthorized or 403 Forbidden — the authentication header is wrong

A 401 or 403 means the URL is reaching the backend but the credentials are rejected. Common causes:

• A doubled scheme prefix. If your provider gives you a value that already starts with Bearer or Basic , paste it as-is — do not add another prefix. A value of Basic Basic <token> fails.
• A missing scheme prefix. If the header is Authorization, most backends expect Bearer <token> or Basic <encoded>, not a bare token.
• Raw credentials used for Basic auth. HTTP Basic expects the base64 encoding of username:password; a raw username:password value fails.
• A rotated or revoked token. If forwarding worked before and now fails, check whether the token was rotated or revoked in your provider’s dashboard, and update the header value.

Some backends use a custom header instead of Authorization (for example New Relic’s api-key). Make sure the header name matches exactly what your provider documents.

Your own collector is reachable but not forwarding

If you run an OpenTelemetry Collector between MCP Manager and your backend, receiving records is not the same as forwarding them. Make sure your exporter is wired into the logs pipeline:

collector-config.yaml

service:
  pipelines:
    logs:
      receivers: [otlp]
      exporters: [otlphttp] # the exporter must be listed here

If an exporter is defined but not listed under service.pipelines.logs.exporters, the collector accepts records from MCP Manager and silently drops them.

You are querying the wrong datasource

In a unified observability platform, logs and metrics usually live in separate backends. MCP Manager sends logs, not metrics or traces. Make sure you are querying the logs datasource (for example Loki in Grafana, or the Logs view in your platform), not the metrics store. Querying the wrong datasource returns nothing and looks identical to logs not arriving.

Test the collector URL manually

From any machine with outbound HTTPS access, POST an empty body to your collector URL with your authentication header:

terminal

curl -v -X POST "<your-collector-url>" \
  -H "<your-auth-header-name>: <your-auth-header-value>" \
  -H "Content-Type: application/json" \
  -d '{}'

Interpret the response:

• 400 Bad Request mentioning an invalid or malformed payload — the URL and authentication are both correct; the backend just rejected the empty test body. This is the result you want.
• 404 Not Found — the URL path is wrong. You are reaching the host but not the OTLP logs endpoint (often a missing path prefix).
• 401 / 403 — the URL is right but the authentication header is wrong.
• Could not resolve host — a DNS or hostname typo.
• Connection refused or timeout — the host is unreachable (a self-hosted collector not exposed to MCP Manager, or a wrong port).

Where export failures surface

When an export fails, MCP Manager records it in two places so you can diagnose it without watching the gateway in real time:

• The Alerts tab. MCP Manager raises a warning-level alert titled “Failed to export telemetry logs to OTEL collector” the first time an export fails for a given collector URL and error. The alert message names the collector URL, the number of records, and the HTTP status or error code. To avoid flooding the workspace, the alert is deduplicated for one hour per unique combination of collector and error, so a persistently broken configuration produces one alert per hour rather than one per failed request. Open Alerts to see it.
• The gateway logs. Each failed export is logged on the gateway by the OtlpLoggerExporter, including the target URL, the HTTP status, and the error message.

A green or saved state on the configuration panel only reflects that the configuration is stored — delivery problems surface as alerts, not as errors on the configuration form.

Who can set up log export

Two conditions govern access to log forwarding, and they are separate from the ability to view logs.

• Plan. The OpenTelemetry integration is an Enterprise capability. On plans that do not include it, the Integrations tab shows a promotional panel with a contact prompt instead of the configuration form.
• Capability. Configuring, editing, and removing the collector is controlled by the Manage OpenTelemetry collector capability, found in the Logging group under the Capabilities tab when managing a role (in People). When a user’s role has this capability, the OpenTelemetry collector panel is available to them; when it does not, the panel is hidden. Capabilities are assigned per role and are fully configurable — including on any custom roles you create — so access depends on the capabilities granted to a person’s role, not on any fixed role name.

The separate View and export logs capability controls who can read and download logs inside MCP Manager, as described in Viewing Logs. A person can have one capability without the other.

Frequently asked questions

Do I need to run my own OpenTelemetry Collector?

No. MCP Manager sends logs directly to whatever OTLP/HTTP endpoint you configure. If your platform exposes a native OTLP logs intake (Grafana Cloud, New Relic, Honeycomb, and others), point MCP Manager straight at it. Run your own collector only if you need to filter, enrich, or fan out before logs reach their final destination — or if your backend does not accept OTLP logs natively.

Can I forward logs to more than one destination?

Not directly. MCP Manager supports a single collector URL per organization. To deliver to multiple destinations, point MCP Manager at your own OpenTelemetry Collector and use its pipeline to fan out to each backend.

Can I forward only certain log events?

No. MCP Manager forwards every log record the gateway produces. To send only a subset, terminate at your own collector and filter in the collector’s pipeline before exporting onward.

Does MCP Manager buffer logs if my collector is down?

No. Each record is exported as it is created; there is no buffering and no replay. If the collector is unreachable when a record is emitted, that record is not delivered. This keeps the gateway latency-neutral. If durable buffering matters to you, run an OpenTelemetry Collector close to MCP Manager with a persistent queue and point MCP Manager at that collector.

Will a broken collector configuration slow down MCP requests?

No. Log export is fire-and-forget: the gateway completes the request to the client and emits the log record asynchronously, so a slow or failing collector does not add latency to MCP calls. Repeated export failures are surfaced as alerts rather than affecting request handling.

I saved the configuration but no logs appear. What is wrong?

A saved configuration only confirms storage, not delivery. Check Alerts first for a “Failed to export telemetry logs to OTEL collector” alert — its message includes the HTTP status code. If there is no alert, confirm you triggered an MCP call after saving, that you are querying the logs datasource in your backend, and work through Troubleshooting.

Further reading

New Relic

The first per-vendor guide — License key, regional endpoint, and NRQL.

Self-hosted Collector

The universal fallback for any backend that can’t take OTLP logs directly.

Viewing Logs

The log model and the data each forwarded record carries.

Audit & Observability

Why forwarding logs to your SIEM completes the audit story.