This page describes the collector side of the OpsRamp tracing solution. The opsramp-tracing-proxy receives OpenTelemetry trace data from instrumented applications or collector gateways, enriches spans with additional metadata required by OpsRamp trace analysis, performs trace-metric processing when enabled, and forwards telemetry to the OpsRamp tracing backend.

Purpose

The tracing proxy acts as the customer-side collection layer for distributed tracing. It is deployed close to the workloads, usually inside the Kubernetes cluster, so applications can send traces to a local endpoint instead of sending directly to the OpsRamp backend.
At a high level, the tracing proxy is responsible for:

• Receiving trace payloads over OpenTelemetry-compatible endpoints.
• Handling both OTLP HTTP and OTLP gRPC traffic from instrumented services or upstream collectors.
• Enriching spans with deployment and cluster metadata required by OpsRamp trace analysis.
• Supporting trace metrics processing so service throughput, latency, and error views can be populated.
• Forwarding sampled traces and generated/enriched signals to the OpsRamp tracing backend.

Where it fits in the tracing flow

The typical flow is:

1. Applications are instrumented with OpenTelemetry, either manually or through auto-instrumentation such as Odigos, and trace data is forwarded to opsramp-tracing-proxy.
2. The tracing proxy enriches, batches, and forwards data to the OpsRamp tracing backend.
3. OpsRamp uses the received data to power Trace Explorer, service overview, operation insights, dependency views, and trace detail pages.

Collection endpoints

The tracing proxy should be exposed internally to the cluster so workloads and collector components can send OTLP traffic to it. In a Kubernetes deployment, the service is commonly referenced using the in-cluster DNS name.

Metrics handler usage: The metrics handler can be enabled together with disabling trace-metrics computation on the proxy. This is useful when sampling is enabled at the source and trace-derived metrics are already generated upstream, for example by a span metrics connector or another collector-side metrics pipeline.

Example in-cluster endpoint used by the collection layer:

http://opsramp-tracing-proxy.opsramp-tracing-proxy.svc.cluster.local:8082

Integration with instrumentation collectors

The tracing proxy is designed to receive telemetry from instrumentation collectors or from instrumented applications directly. Application instrumentation can be manual, SDK-based, auto-instrumented, or managed through tools such as Odigos. The collector layer can normalize, sample, and route telemetry to the tracing proxy using the endpoint that matches the configured pipeline.

For an Odigos or OpenTelemetry Collector setup, configure the collector export pipeline to forward spans to the trace ingestion endpoint on 8082 or 9090. For metrics handler usage, when source-side sampling is enabled and trace-derived metrics are generated upstream, configure the metrics export pipeline to send metrics to 4317 or 4318 and disable trace-metrics computation on the proxy.

http://opsramp-tracing-proxy.opsramp-tracing-proxy.svc.cluster.local:8082

After this destination is created, sampled spans are routed to the tracing proxy, enriched, and pushed to the OpsRamp backend.

Trace metrics behavior

The tracing proxy participates in producing trace-derived metrics used by the OpsRamp tracing UI. These metrics power service and operation views such as throughput, latency, and error-rate analysis.
Common trace metric outputs include:

• trace_operations_total — throughput counts.
• trace_operations_latency — Prometheus histogram for tracking latency.

Important labels include service_name, app, transaction_category, transaction_sub_category, operation, status_code, kind, and transaction_type.