Skip to main content
MCP Manager records every request and response that flows through your MCP gateways, and can forward that telemetry — logs and request traces — 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, and a span for each proxied request, to the OTLP/HTTP endpoints you supply — so you can correlate MCP tool usage with the rest of your operational data, build dashboards, see a request waterfall, 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 records: Grafana Cloud, New Relic, Honeycomb, Datadog, your own OpenTelemetry Collector, or anywhere else with an OTLP intake. Each MCP Manager organization forwards to one collector, and you configure a logs endpoint, a traces endpoint, or both — at least one is required. The two signals use separate OTLP paths (typically /v1/logs and /v1/traces), which is why each has its own URL field.
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.
  • Trace context — every record carries a trace_id and a span_id, and (on the legs that have one) a traceparent, so each log can pivot to its distributed trace. These are stamped onto every record whether or not you configure a traces endpoint. See Traces and trace-correlated logs.
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).

​
Traces and trace-correlated logs

Trace correlation is always on — it does not depend on a traces endpoint. For every proxied MCP request, the gateway mints one OpenTelemetry trace and the spans within it, and stamps the trace identifiers onto every log record that request produces:
  • trace_id — the W3C trace ID (32 hex characters) for the whole request, identical on every log leg of that request. It is the key you filter on to pull back all the logs of one interaction.
  • span_id — the span that log leg represents (16 hex characters): the gateway span on the client- and server-facing legs, and a distinct child span for each rule-engine evaluation.
  • traceparent — the W3C traceparent in play on that leg (see the determinism rule below).
Because the gateway mints in-process, the log legs of a request group under one trace ID in your backend even when no traces endpoint is set. Minting and stamping are not configurable and cannot be disabled. Configuring a traces endpoint adds export, nothing more. When a traces URL is set, MCP Manager also sends the spans themselves over OTLP/HTTP, so you get a request waterfall in your tracing backend — the gateway span as the root, with each rule-engine evaluation and the upstream MCP server hop as children. Each span records the JSON-RPC method, the organization, the outbound gateway, the tool name where applicable, and the final HTTP status (a 4xx/5xx response marks the span as an error). Without a traces URL you still get the IDs on every log; you just don’t get the exported span waterfall. The gateway continues an incoming trace when the client sends W3C traceparent context, and otherwise starts a fresh root. A client can supply it two ways: the HTTP traceparent header, or the JSON-RPC body at params._meta.traceparent. When both are present, the body value (params._meta.traceparent) wins. MCP Manager then propagates the context downstream to the upstream MCP server on both the HTTP traceparent header and params._meta.traceparent, so the gateway → upstream hop stitches into the same trace. The body value carries the gateway span — the same trace ID as the inbound request, with MCP Manager’s own span ID — so MCP-native and multi-hop servers can link their own records to the trace.
Received vs. minted — how to tell which happened. The traceparent column makes the origin of a trace deterministic from the logs alone. On the client-facing leg (proxy_request_success), a present traceparent means the client sent it and MCP Manager adopted that trace; an absent traceparent means MCP Manager minted the trace itself — and in that case only the gateway ↔ upstream (mcp_*) legs carry a traceparent. The server-facing mcp_* legs always carry the outbound traceparent MCP Manager forwarded, because MCP Manager always mints downstream context.
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 the endpoint URL(s) from your collector or backend — a logs collector URL, a traces collector URL, or both — and any request headers the backend requires for authentication. The headers you configure are sent with both signals.
MCP Manager sends to each collector URL exactly as you enter it — nothing is appended. Paste the full signal path: for most backends the logs URL ends in /v1/logs and the traces URL ends in /v1/traces. Pasting a base URL and expecting MCP Manager to add the path is the single most common setup mistake, and it results in a 404 on every export. Confirm the exact, complete URLs with your provider — the logs and traces paths are different.
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 logs and/or traces collector URLs

In Logs collector URL, paste the full HTTPS endpoint for your OTLP logs intake; in Traces collector URL, paste the endpoint for your OTLP traces intake. Each must include the complete signal path. For example:
Replace <your-otlp-host> with the host (and port, if required) from your provider. MCP Manager sends to each URL verbatim — if your provider’s documented OTLP URLs end in /v1/logs and /v1/traces (or vendor-specific paths such as Grafana Cloud’s /otlp/v1/logs), include those paths here.You must fill in at least one of the two URLs — the form rejects a save with both blank. Set only the logs URL to forward logs (still trace-correlated, see Traces and trace-correlated logs); set only the traces URL to forward spans; set both to forward everything.
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.
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.
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.
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
If an exporter is defined but not listed under service.pipelines.logs.exporters, the collector accepts records from MCP Manager and silently drops them.
In a unified observability platform, logs, traces, and metrics usually live in separate backends. MCP Manager sends logs and traces (not metrics). Make sure you are querying the right datasource — the logs view (for example Loki in Grafana) for log records, and the traces/APM view for spans — not the metrics store. Querying the wrong datasource returns nothing and looks identical to data not arriving.
From any machine with outbound HTTPS access, POST an empty body to your collector URL with your authentication header:
terminal
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 the first time an export fails for a given collector URL and error — titled “Failed to export telemetry logs to OTEL collector” for the logs signal, or “Failed to export telemetry traces to OTEL collector” for the traces signal. The alert message names the collector URL, the number of records or spans, and the HTTP status or error code. To avoid flooding the workspace, the alert is deduplicated for one hour per unique combination of collector, signal, 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 for logs and the OtlpTracerExporter for traces — 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

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.
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.
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.
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.
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.
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.