Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 2. Observing MCP gateway connections
You can use observability in MCP gateway to debug things such as silent failures, track destructive annotations, track latencies, and make an audit trail.
2.1. Enabling Red Hat build of OpenTelemetry for the MCP gateway Copier lienLien copié sur presse-papiers!
The MCP gateway uses Red Hat build of OpenTelemetry throughout all components to give you consistent logging, distributed tracing, and metrics. By using observability, you can achieve the following goals:
- Discover which component generated an error, such as Envoy, an MCP gateway component, or a backend MCP server.
- Understand how requests flow through the system components.
- See which tools were called and which MCP servers executed those tools.
- Understand where to find relevant logs for each component.
- Examine metrics about tool call patterns, success rates, and error rates.
- Examine distributed tracing across the request path.
Prerequisites
- You installed MCP gateway.
- You installed Connectivity Link.
-
You configured a
Gatewayobject. -
You are logged into a running OpenShift Container Platform cluster with an
adminrole. - You installed Red Hat build of OpenTelemetry.
- You configured the Red Hat OpenShift Distributed Tracing Platform for traces.
- You installed the OpenShift Logging Operator (Loki).
- You configured an S3-compatible persistent storage volume for Loki to store long-term MCP tool call logs.
Procedure
Use the following example YAML to create a collector in your MCP gateway deployment namespace:
Example OpenTelemetryCollector custom resource (CR)
apiVersion: opentelemetry.io/v1beta1 kind: OpenTelemetryCollector metadata: name: <mcp_otel_collector> namespace: <mcp_gateway_system> spec: mode: deployment config: receivers: otlp: protocols: http: endpoint: 0.0.0.0:4318 grpc: endpoint: 0.0.0.0:4317 exporters: otlp/tempo: endpoint: tempo-gateway-http.openshift-tracing.svc.cluster.local:4317 tls: insecure: true debug: verbosity: basic service: pipelines: traces: receivers: [otlp] exporters: [otlp/tempo, debug] logs: receivers: [otlp] exporters: [debug]-
Replace the value of
metadata.name:with the name you want to assign to this collector. -
Replace the value of
metadata.namespace:with the namespace of your MCP gateway deployment. -
The
spec.config.exporters:field value points to distributed tracing. -
The setting,
spec.config.exporters.otlp/tempo.tls.insecure: trueis for internal cluster communication without TLS.
-
Replace the value of
Apply the following environment variables to your OpenShift Container Platform cluster by running the following command:
$ oc set env deployment/mcp-gateway \ OTEL_EXPORTER_OTLP_ENDPOINT="http://<mcp_otel_collector>-collector.<mcp_gateway_system>.svc.cluster.local:4318" \ OTEL_EXPORTER_OTLP_INSECURE="true" \ OTEL_SERVICE_NAME="mcp-gateway"-
Replace
<mcp_otel_collector>with the name you used in yourOpenTelemetryCollectorCR. When Red Hat build of OpenTelemetry creates a collector, the service name is[metadata.name]-collector. -
Replace
<mcp_gateway_system>with the namespace of your MCP gateway deployment.
-
Replace
Optional. If you want to send traces to one collector and logs to a different one, set the following additional environment variables:
$ oc set env deployment/mcp-gateway \ OTEL_EXPORTER_OTLP_TRACES_ENDPOINT="http://trace-collector.tracing-namespace.svc:4317" \ OTEL_EXPORTER_OTLP_LOGS_ENDPOINT="http://log-collector.logging-namespace.svc:4317"-
Set
OTEL_EXPORTER_OTLP_TRACES_ENDPOINTto override the endpoint for traces. -
Set
OTEL_EXPORTER_OTLP_LOGS_ENDPOINTto override the endpoint for logs.
-
Set
-
If you are using Red Hat OpenShift Distributed Tracing Platform, select your stack name as the data source in the OpenShift Web Console Observe > Traces dashboard. For example,
tempo-mcp. After you select the stack name, you can consult an attribute in your OpenShift Web Console OpenShift Observe > Traces dashboard to find where errors have occurred or to gather information for trend identification.
-
You can also filter by
service.name="mcp-gateway".
-
You can also filter by
-
When using Loki, use the Observe > Logs view and toggle the Structured view to filter by
mcp.session.id. -
When using Loki, use the Trace timeline view, look for the
Logicon next tospansto jump directly to the relevant logs.
Troubleshooting
-
If you do not see any traces, check if the
NetworkPolicyCR in your namespace allows traffic from the MCP gateway to the Red Hat build of OpenTelemetry collector service.
2.1.1. MCP gateway router spans for observability Copier lienLien copié sur presse-papiers!
When enabled, the MCP router, ext_proc, emits trace spans for every request and can export structured logs through Red Hat build of OpenTelemetry.
With traces, you can see one continuous timeline of traffic events across different pods and services. This can help you identify bottlenecks and conduct root-cause analysis.
Spans show one part of the journey. The attributes attached to those spans give you the contextual metadata that you need to have searchable and meaningful traces. The attributes are simple key: value pairs attached to each span.
The MCP gateway uses the following router spans:
| Span | When | Description |
|---|---|---|
|
|
Every | Root span. Starts when request headers arrive, ends after response headers are processed. |
|
| The request body is parsed |
Routing decision: |
|
|
Non- |
Pass-through to broker: |
|
|
| Full tool call handling including session and server resolution. |
|
|
Inside | Call out to broker to resolve which backend server owns the tool. |
|
|
Inside | Call out to session cache to look up an existing backend session. |
|
|
Cache miss during |
Hairpin |
|
|
After | Call out to session cache to store the new backend session. |
The attributes in the following tables use OpenTelemetry MCP Semantic Conventions.
| Attribute | Source | Description |
|---|---|---|
|
|
|
HTTP method, |
|
|
|
Request path, |
|
|
| Envoy request ID |
|
|
JSON-RPC |
MCP method, |
|
|
JSON-RPC |
Tool name, only for |
|
|
JSON-RPC | JSON-RPC request ID |
|
|
JSON-RPC | Always "2.0" |
|
|
JSON-RPC |
Same as |
|
|
| Gateway session ID |
|
|
| Client IP address |
|
|
| Response status code |
| Attribute | Description |
|---|---|
|
| MCP method |
|
|
Routing decision: |
| Attribute | Description |
|---|---|
|
| Tool name from the request |
|
| Gateway session ID |
|
| Resolved backend server name |
|
| Resolved backend server hostname |
| Attribute | Description |
|---|---|
|
|
Error classification, such as |
|
| Component that generated the error, such as`ext-proc` |
|
| HTTP status code returned |
When there is an error, spans include these attributes.