> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mcpmanager.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# 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](/enterprise/export-to-siem/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](/enterprise/export-to-siem).

<Info>
  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](/enterprise/export-to-siem#who-can-set-up-log-export).
</Info>

## 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:

```text theme={null}
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.

<Warning>
  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`).
</Warning>

## 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:

```yaml collector-config.yaml theme={null}
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.

```yaml collector-config.yaml theme={null}
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

<Steps>
  <Step title="Open the OpenTelemetry collector panel">
    In MCP Manager, go to [Logs → Integrations](https://app.mcpmanager.ai/settings/logging/integrations) and find the **OpenTelemetry collector** panel.
  </Step>

  <Step title="Enter the collector URL">
    In **Logs collector URL**, paste your Collector's HTTP logs endpoint, for example `https://collector.example.com:4318/v1/logs`. (To also export traces, set **Traces collector URL** to the Collector's `/v1/traces` endpoint and wire a `traces` pipeline; this guide covers logs.)
  </Step>

  <Step title="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.
  </Step>

  <Step title="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>
</Steps>

## 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](https://app.mcpmanager.ai/settings/alerts) in MCP Manager.

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

## 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:

```yaml collector-config.yaml theme={null}
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.

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

## Troubleshooting

<AccordionGroup>
  <Accordion title="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).
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="Test the connection manually">
    From any machine with outbound HTTPS access:

    ```bash terminal theme={null}
    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.
  </Accordion>
</AccordionGroup>

## Further reading

<CardGroup cols={2}>
  <Card title="Export to SIEM" icon="tower-broadcast" href="/enterprise/export-to-siem">
    What MCP Manager sends, how forwarding behaves, and general troubleshooting.
  </Card>

  <Card title="Splunk Observability Cloud" icon="triangle-exclamation" href="/enterprise/export-to-siem/splunk-observability-cloud">
    The backend that needs this collector to translate OTLP logs to Splunk HEC.
  </Card>

  <Card title="Audit & Observability" icon="magnifying-glass-chart" href="/security/audit-and-observability">
    Why forwarding logs to your own store completes the audit and retention story.
  </Card>
</CardGroup>

## External sources

<CardGroup cols={2}>
  <Card title="OTLP receiver reference" icon="arrow-up-right-from-square" href="https://github.com/open-telemetry/opentelemetry-collector/blob/main/receiver/otlpreceiver/README.md">
    Default ports and paths, `logs_url_path`, and the protobuf-JSON encoding constraint.
  </Card>

  <Card title="Collector auth extensions" icon="arrow-up-right-from-square" href="https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/extension">
    The `bearertokenauth`, `basicauth`, and `oidcauth` extensions, each with its own README.
  </Card>

  <Card title="OTLP specification" icon="arrow-up-right-from-square" href="https://opentelemetry.io/docs/specs/otlp/">
    The protocol spec, including the success and partial-success response contract.
  </Card>

  <Card title="AWS S3 exporter" icon="arrow-up-right-from-square" href="https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/awss3exporter">
    Archive log records to Amazon S3 for long-term retention; see also the GCS and Azure Blob exporters.
  </Card>
</CardGroup>