Self-hosted OpenTelemetry Collector

How to forward MCP Manager logs to a self-hosted OpenTelemetry Collector: the OTLP/HTTP receiver on port 4318, the /v1/logs path, adding authentication with collector auth extensions, and using the collector as a universal fallback to any backend.

A self-hosted OpenTelemetry Collector is the universal fallback for MCP Manager log forwarding. The Collector’s OTLP receiver is the reference OTLP implementation — it accepts OTLP/HTTP in both JSON and protobuf natively — so MCP Manager can send to it directly, and you use the Collector’s pipeline to filter, enrich, fan out to multiple backends, or translate to a protocol a backend requires (for example translating OTLP logs to Splunk HEC for Splunk Observability Cloud).

This guide covers the Collector-specific details. For what MCP Manager sends, how forwarding behaves, who can configure it, and general troubleshooting, see Export to SIEM.

Configuring log forwarding requires the Manage OpenTelemetry collector capability and an Enterprise plan that includes the OpenTelemetry integration. If you do not see the Logging → Integrations panel, see Who can set up log export.

What you’ll need

• A running OpenTelemetry Collector reachable from MCP Manager over HTTPS (MCP Manager is a hosted service, so the receiver must be exposed to the public internet or to MCP Manager’s egress).
• The Collector’s OTLP receiver enabled with a logs pipeline.
• Optionally, an authentication extension if you want the receiver to require credentials.
• Access to MCP Manager with the Manage OpenTelemetry collector capability.

Step 1: Determine your collector URL

The Collector’s OTLP receiver listens on 0.0.0.0:4317 for gRPC and 0.0.0.0:4318 for HTTP. MCP Manager sends OTLP/HTTP, so use the HTTP port and the default logs path:

https://<your-collector-host>:4318/v1/logs

The HTTP paths default to /v1/traces, /v1/metrics, and /v1/logs, and the logs path is overridable via the receiver’s logs_url_path setting.

Point MCP Manager at the HTTP port 4318, not the gRPC port 4317. MCP Manager sends OTLP/HTTP, so a URL on 4317 will not work. And because MCP Manager appends nothing to the URL, include the full /v1/logs path (or your overridden logs_url_path).

Step 2: Enable the OTLP receiver and a logs pipeline

In your Collector configuration, enable the OTLP receiver and wire it into a logs pipeline alongside your chosen exporter:

collector-config.yaml

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318

exporters:
  otlphttp:
    endpoint: https://your-backend.example.com/otlp

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

Receiving records is not the same as forwarding them: an exporter that is defined but not listed under service.pipelines.logs.exporters causes the Collector to accept records from MCP Manager and silently drop them.

Step 3: Add authentication (optional)

The OTLP receiver has no authentication by default. Add an auth extension and reference it from the receiver. Common choices live in the Collector-contrib extension/ directory: bearertokenauthextension (an Authorization: Bearer <token> scheme), basicauthextension (HTTP Basic), and oidcauthextension. Because MCP Manager sends arbitrary request headers, whatever scheme you configure is supported — you set the matching header in MCP Manager.

collector-config.yaml

extensions:
  bearertokenauth:
    token: <your-token>

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318
        auth:
          authenticator: bearertokenauth

service:
  extensions: [bearertokenauth]
  pipelines:
    logs:
      receivers: [otlp]
      exporters: [otlphttp]

Step 4: Connect MCP Manager to your Collector

1. Open the OpenTelemetry collector panel

   In MCP Manager, go to Logs → Integrations and find the OpenTelemetry collector panel.

2. Enter the collector URL

   In Collector URL, paste your Collector’s HTTP logs endpoint, for example https://collector.example.com:4318/v1/logs.

3. Add the matching auth header (if configured)

   Under Request headers, add whatever header your auth extension expects — for example an Authorization header with the value Bearer <your-token> to match bearertokenauthextension. Leave the section empty if your receiver accepts unauthenticated traffic.

4. Save the configuration

   Select Save. MCP Manager stores the configuration and encrypts the header values. Saving confirms storage only — it does not confirm delivery.

Step 5: Verify and find your logs

Trigger an MCP call through a gateway (a tools/list call is enough). A correctly configured OTLP/HTTP receiver returns 2xx with a body of {"partialSuccess":{}} for an accepted batch. Where the records end up depends on your downstream exporter; the OTLP service.name resource attribute (in production, mcp-manager) is preserved through the pipeline, so filter on it in your final backend. If nothing arrives, check Alerts in MCP Manager.

Encoding constraint: OTLP/HTTP with JSON must use protobuf-JSON serialization, with bytes fields base64-encoded. The reference OTLP receiver accepts this natively, so MCP Manager’s JSON encoding works against a standard Collector. If you place a non-standard receiver in front, confirm it accepts protobuf-JSON.

Long-term retention to object storage

A self-hosted Collector is also how you keep MCP logs for any duration — well beyond your MCP Manager plan’s retention period, including indefinitely for compliance. The pattern is MCP Manager → your Collector → your object store: point MCP Manager at your Collector as above, then add an exporter that writes to object storage such as Amazon S3, and control how long the data lives with your bucket’s own lifecycle rules. Because the data sits in your storage, the retention period is entirely yours to set.

The Collector-contrib awss3exporter writes the log records it receives to an S3 bucket. Add it to the logs pipeline alongside (or instead of) your other exporters:

collector-config.yaml

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318

exporters:
  awss3:
    s3uploader:
      region: us-east-1
      s3_bucket: your-mcp-log-archive
      s3_prefix: mcp-manager
      s3_partition_format: '%Y/%m/%d/%H'

service:
  pipelines:
    logs:
      receivers: [otlp]
      exporters: [awss3] # add other exporters here to fan out as well

The exporter writes objects under the s3_prefix, partitioned by time, so logs land as your-mcp-log-archive/mcp-manager/2026/05/29/14/.... Set the retention you need with an S3 lifecycle policy on the bucket — keep objects for a fixed number of years, transition them to colder storage classes, or never expire them. Equivalent exporters exist for other clouds (for example googlecloudstorageexporter for Google Cloud Storage and azureblobexporter for Azure Blob Storage); the pattern is the same.

The awss3exporter archives raw log records to object storage; it is not a query engine. To search archived logs, run a query layer over the bucket (for example Amazon Athena over the S3 objects) or keep a parallel exporter to your SIEM for live querying while S3 holds the long-term archive.

Troubleshooting

Nothing arrives and there is no clear error

Confirm MCP Manager is pointed at the HTTP port 4318 and the /v1/logs path, not the gRPC port 4317. Confirm the Collector host is reachable from the public internet (a Collector bound only to a private network is not reachable by the hosted MCP Manager service).

Records are accepted but never reach the backend

The exporter is not wired into the logs pipeline. Ensure your exporter is listed under service.pipelines.logs.exporters; otherwise the Collector receives records and drops them.

Authentication failures return an unclear response

The OTLP/HTTP receiver does not always return a clean status when an authenticator rejects a request — the client may report an unparseable response rather than a clear 401. If exports fail right after you enable an auth extension, suspect the credentials or header name before chasing a transport bug, and confirm the header MCP Manager sends matches what the extension expects.

Test the connection manually

From any machine with outbound HTTPS access:

terminal

curl -v -X POST "https://<your-collector-host>:4318/v1/logs" \
  -H "Authorization: Bearer <your-token>" \
  -H "Content-Type: application/json" \
  -d '{}'

A 2xx with {"partialSuccess":{}} confirms the receiver is reachable and authenticated; a 404 means a wrong or overridden path; a 400 means a malformed body.

Further reading

Export to SIEM

What MCP Manager sends, how forwarding behaves, and general troubleshooting.

Splunk Observability Cloud

The backend that needs this collector to translate OTLP logs to Splunk HEC.

Audit & Observability

Why forwarding logs to your own store completes the audit and retention story.

External sources

OTLP receiver reference

Default ports and paths, logs_url_path, and the protobuf-JSON encoding constraint.

Collector auth extensions

The bearertokenauth, basicauth, and oidcauth extensions, each with its own README.

OTLP specification

The protocol spec, including the success and partial-success response contract.

AWS S3 exporter

Archive log records to Amazon S3 for long-term retention; see also the GCS and Azure Blob exporters.