Intro

MCP Manager streams structured MCP logs — who called which tool, how long it took, which server answered, how many tokens were used — to any OpenTelemetry-compatible backend. That includes Grafana, Datadog, Honeycomb, Splunk Observability, New Relic, your own OTEL collector, or anywhere else that speaks OTLP/HTTP.

This article covers setup, verification, and troubleshooting. If you hit a problem not covered below, scroll to the FAQ at the bottom — we add to it whenever a new question comes up during onboarding.

What Gets Sent

For every MCP request that flows through an MCP Manager gateway, we emit log records containing:

• Timing for both the client-facing side and each upstream MCP server
• Who made the request — user email, user name, org, team
• What was called — method, feature name, tool name, server URL
• How much — token counts, response codes, durations
• Correlation IDs so you can trace a single interaction across multiple hops

All records are sent to the OTLP/HTTP logs endpoint you configure, using the OTLP JSON wire format.

Setup

1. In the MCP Manager UI, go to Settings → Logging → Integrations.
2. Find the OpenTelemetry collector panel.
3. Fill in the two (or more) fields described below.

Collector URL (required)

The full HTTPS endpoint for your OTLP logs intake. Example placeholder you'll see in the field:

https://<otel-collector>.<SIEM-URL>.com:<port>/v1/logs

MCP Manager sends to this URL exactly as entered — nothing is appended. If your provider's URL ends in /v1/logs, include it. If their URL ends at a base path (and their exporter docs say "the exporter appends /v1/logs automatically"), you have to add it, because we don't.

Some kind of authorization (required)

The complete value of your authorization HTTP header your collector expects. Include the scheme prefix. Leave blank if your collector accepts unauthenticated traffic.

Bearer abc123...
Basic eyXXXXXX...

The field is a masked password input — your value is never displayed back to you in plaintext after saving and is encrypted.

Click Connect collector (or Save if you're editing an existing configuration). A Connected status appears once the configuration is stored, alongside a reminder to confirm your collector is actually receiving logs — delivery issues surface as alerts, not UI errors, so a green pill is not proof that logs are flowing.

Verifying Logs Are Flowing

The Connected status means your configuration was saved — not that logs are successfully reaching the collector. To verify actual delivery:

1. From a connected MCP client (Cursor, Claude Desktop, etc.), trigger any MCP call. tools/list is a safe choice.
2. Once saved, the panel shows a Filter your logs by section with the exact service.name and service.version MCP Manager is sending. Use those values to filter in your logs backend.
3. Over the last minute, you should see at least two records per call — a proxy_request_success and a proxy_response_success.

If nothing appears, check the Alerts tab in MCP Manager first — delivery issues surface there as warning-level alerts with the HTTP error code included. The OpenTelemetry panel links directly to Alerts for admins. If there's no alert, work through the troubleshooting section below.

General Troubleshooting

Before diving into vendor-specific details, rule out the four most common causes.

1. The URL Is Missing a Path Segment

The OTEL spec lets collectors accept logs at different paths depending on how the operator set it up. Common variants:

• /v1/logs — default for a stock OTLP/HTTP receiver
• /otlp/v1/logs — for gateways with an /otlp mount prefix (most SaaS OTLP providers)
• /api/v1/otlp/v1/logs — for collectors behind a versioned ingress

If the URL is wrong, the gateway responds 404 Not Found and every export fails. MCP Manager surfaces this as an alert in the Alerts tab titled "Failed to export telemetry logs to OTEL collector" with the error code and status included.

Fix: confirm the exact URL with your provider. Whatever they tell you to paste into an OTLP exporter's url field is what goes into Collector URL.

2. The Authorization Header Is Formatted Wrong

The Authorization field is sent verbatim as the Authorization HTTP header. That means:

If your provider gives you a value labeled as "the full Authorization header," paste it as-is. If they give you raw credentials (username/password or API key/secret), build the Basic value yourself:

Basic <base64 of "username:password">

A wrong auth header shows up as 401 Unauthorized or 403 Forbidden in MCP Manager's alert. If your provider supports API keys or bearer tokens, those won't be base64-encoded at all — just paste Bearer <your-token>.

3. Your Own Collector Is Reachable but Not Forwarding

If you run an OTEL collector between MCP Manager and your logs backend, make sure the logs pipeline is wired up in your collector config:

exporters:
  otlphttp:
    endpoint: https://your-backend.example.com/otlp
    auth:
      authenticator: basicauth/yourauth

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

Receiving logs is not the same as forwarding them. If an exporter is defined but not wired into the logs pipeline, records are accepted from MCP Manager and silently dropped.

4. You're Querying the Wrong Datasource

In a unified observability platform, logs and metrics usually live in separate backends. Make sure you're querying the logs datasource, not metrics. The Grafana Cloud section below calls out the specific trap.

Grafana Cloud Specifics

Grafana Cloud is the most common destination we see. A few specifics that trip up most new integrations.

Endpoint URL — Watch the /otlp/ Prefix

Grafana Cloud's OTLP gateway exposes logs at /otlp/v1/logs, not /v1/logs:

https://otlp-gateway-prod-us-east-2.grafana.net/otlp/v1/logs

Your region will differ — prod-us-east-0, prod-eu-west-0, etc. Grab the exact URL from Grafana Cloud → Connections → Add new connection → OpenTelemetry (OTLP).

If you miss the /otlp/ prefix and paste https://otlp-gateway-prod-us-east-2.grafana.net/v1/logs, every export 404s. This is by far the most common Grafana setup mistake.

Authorization — It's Already Base64-Encoded

Grafana Cloud uses HTTP Basic auth. The connection page gives you a pre-encoded value labeled GRAFANA_CLOUD_BASIC_AUTH_HEADER that looks like:

Basic eyXXXXXX...

Paste the entire value (including Basic ) into the Authorization field. Do not base64-encode it again — it's already encoded. That encoded blob is your instance ID plus your API token, concatenated with a colon and base64'd.

If you prefer to build it yourself:

Basic <base64 of "instanceId:apiToken">

Logs Live in Loki, Not Prometheus

In Grafana Explore, switch the datasource selector to your Loki datasource (typically named grafanacloud-<stack>-logs) before querying. Querying Prometheus for log data returns nothing and looks indistinguishable from logs not arriving.

Finding Logs in Loki

Once logs arrive, query by the service_name label — OTEL translates the service.name resource attribute into this label:

{service_name="<the service name MCP Manager shows in the Filter panel>"}

To discover what labels exist, open the label browser in Grafana Explore or use the Logs Drilldown app.

Running Your Own Collector in Front of Grafana Cloud?

If you sit an OTEL collector between MCP Manager and Grafana Cloud, make sure:

1. The OTLP receiver is enabled and listening on the port MCP Manager points at.
2. Your Grafana Cloud exporter points at https://otlp-gateway-.../otlp (or .../otlp/v1/logs depending on which config key you use — see the OTEL docs' note about OTEL_EXPORTER_OTLP_ENDPOINT vs OTEL_EXPORTER_OTLP_LOGS_ENDPOINT).
3. The exporter is explicitly listed under service.pipelines.logs.exporters.

FAQ

I don't see a way to connect with OpenTelemetry inside of MCP Manager at /settings/logging/integrations.

If you do not see a way to connect to your OTEL collector, you may not have adequate permissions to do so. Please check if you have the "Manage OpenTelemetry collector" capability in your /people/roles/capabilities tab. By default, Super Admins are allowed to manage logging integrations.

Do I need to run my own OTEL collector?

No. MCP Manager sends logs directly to whatever OTLP/HTTP endpoint you paste in. If your logging provider exposes an OTLP endpoint (Grafana Cloud, Honeycomb, New Relic, Datadog with OTLP enabled, Splunk Observability, etc.), point MCP Manager straight at them. Run your own collector only if you need to filter, enrich, or fan out before logs reach their final destination.

Can I forward logs to more than one destination?

Not directly. MCP Manager supports a single collector URL per organization. The usual pattern is to point us at your own OTEL collector and use its pipeline to fan out to multiple backends.

I see "Connected" but no logs are appearing. What's happening?

The Connected status only means your configuration is saved — it doesn't mean exports are succeeding. Check Settings → Alerts for an alert titled "Failed to export telemetry logs to OTEL collector"; if one exists, the alert's debug context will contain the HTTP status code and response. If there's no alert, check your collector's ingest logs or your logs backend directly. If the problem is at our end, the alert will name it.

Can I send only certain types of events?

Not at the MCP Manager side today — we send every log event produced by the proxy. If you only want a subset, terminate in your own OTEL collector and filter in the collector's pipeline.

My Authorization worked yesterday, now it's failing

API tokens can be rotated or revoked. Check your provider's dashboard — for most providers, tokens show a "last used" timestamp and a status. For Grafana Cloud, API tokens don't expire by default but can be revoked manually. If the token has been rotated, update the Authorization field in MCP Manager.

How do I verify my Collector URL without waiting for a real request?

From any machine with outbound HTTPS access, run:

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

Possible outcomes:

• 404 Not Found — URL path is wrong. You're hitting the host but not the right endpoint. Most often means a missing /otlp prefix.
• 401 Unauthorized / 403 Forbidden — URL is right, auth is wrong. See the Authorization troubleshooting section.
• 400 Bad Request with a JSON error mentioning "protobuf" or "invalid request" — URL and auth are both right; the backend just rejected an empty body. This is the response you want — it confirms MCP Manager would reach the collector successfully on a real request.
• Could not resolve host — DNS/URL typo. Double-check the hostname.
• Connection refused / timeout — the host is unreachable from the public internet (self-hosted collector not exposed) or wrong port.

Why am I seeing 401 even though the token looks right?

By far the most common cause is a duplicated scheme prefix. If the value your provider gives you already starts with Basic or Bearer , do not add another prefix when pasting it into the Authorization field. Check for Basic Basic ... or Bearer Bearer ... in the field.

Does MCP Manager buffer logs if my collector is down?

No. Each log record is exported as it's created. If the collector is down when a record is emitted, that record is lost — we don't replay. This is intentional to keep the gateway latency-neutral. If durable buffering matters to you, run an OTEL collector locally (or in the same network) with a file storage extension, and point MCP Manager at that collector.

Will a broken OTEL configuration slow down MCP requests?

No. Log export is fire-and-forget — the MCP proxy completes the request to the client and then emits the log asynchronously. A slow or failing collector will not add latency to MCP calls themselves. It will, however, increase CPU load slightly if exports fail thousands of times per minute, which is why we ship alerts when the collector rejects traffic.

Where do export failures surface in MCP Manager?

Two places:

• Alerts tab — a warning-level alert titled "Failed to export telemetry logs to OTEL collector" is created the first time an export fails for a given collector URL + error combination, deduped for one hour so a broken config doesn't flood your inbox. The OpenTelemetry panel on the Integrations page links admins directly here.
• Gateway logs — if you have access to the MCP Manager gateway logs directly, each failed export shows up as a line starting with [OtlpLoggerExporter] Failed to export, including the target URL, HTTP status, and error message.

Will sensitive data appear in my OTEL collector?

Sensitive data may appear in your collector if users are accessing PII or other confidential data. Since we send logs from both your clients and servers, even if you have rules set that block or mask that data, that sensitive data will still be logged. Please confirm your OTEL collector is a secure and compliant data storer before connecting. 

This is a living document. If you encounter an OTEL configuration issue not covered here, let us know — we'll add it to the FAQ so the next customer can find it.