OpsRamp supports trace ingestion through the OpsRamp trace proxy. Manually instrumented applications send OTLP spans to the trace proxy, optionally through an OpenTelemetry Collector.
Application-to-proxy model
Flow: Manually instrumented application or SDK → OpsRamp trace proxy → OpsRamp.Use this model when applications can reach the trace proxy and do not require a separate collection tier. Configure each SDK with the application-facing OTLP endpoint exposed by the trace proxy. Keep the proxy’s OpsRamp credentials in its protected configuration.
Collector-to-proxy model
Flow: Manually instrumented application or SDK → OpenTelemetry Collector → OpsRamp trace proxy → OpsRamp
Use an OpenTelemetry Collector when you need centralized receiver, processing, batching, retry, TLS, or egress configuration. Configure its trace exporter to send spans to the application-facing endpoint of the OpsRamp trace proxy. The Collector is an optional upstream component and does not replace the trace proxy.
Trace proxy deployment
The trace proxy is required in both models. It receives OTLP spans, consolidates traffic, applies the configured trace-aware sampling rules, and forwards accepted trace data to OpsRamp. Deploy it according to the availability, throughput, network, and security requirements documented for your environment.
Choosing a model
| Requirement | Application to Trace Proxy | Collector to Trace Proxy |
|---|---|---|
| Minimal components | Best | Additional Collector tier |
| Central SDK egress | Limited | Best |
| Standard OpenTelemetry processing before the proxy | Limited | Best |
In both models, keep OpsRamp authentication material in the trace proxy’s protected configuration. Do not embed it in application or SDK configuration.