This matrix summarizes tracing collection and investigation capabilities. “OpenTelemetry path” means OpsRamp accepts the resulting OTLP telemetry, while framework-level compatibility is maintained by the upstream OpenTelemetry project.

Instrumentation

CapabilityStatusNotes
Manual OpenTelemetry SDK instrumentationSupportedDocumented for C++, .NET, Erlang, Go, Java, JavaScript, PHP, Python, Ruby, Rust, and Swift.
Framework and library instrumentation packagesOpenTelemetry pathCompatibility depends on the selected language, runtime, package, and OpenTelemetry release.
Manual instrumentation on non-Linux platformsOpenTelemetry pathDepends on the selected language SDK and exporter support.

Collection and transport

CapabilityNotes
OTLP/gRPC tracesPrimary path for exporters, collectors, and trace proxy.
OTLP/HTTP tracesAvailable through applicable exporter or trace-proxy endpoints.
OpenTelemetry CollectorCentralized batching, retry, TLS, OAuth2, and export configuration.
Application-to-proxy exportApplications send OTLP traces to the required trace proxy.
Trace proxy, single instanceProvides trace consolidation, sampling, and derived metrics.
Trace proxy, clusteredIntended for higher availability and throughput; requires peer and load-balancer planning.
Host-based manual instrumentationApplications export to host-accessible gRPC or HTTP trace-proxy endpoints.

Processing and analysis

CapabilityNotes
Trace-aware rule samplingDeterministic, dynamic, and throughput-oriented samplers are implemented.
Span attributes and eventsPreserved for detail, filtering, and event reconstruction.
Service and operation insightsIncludes latency, error, throughput, and performance views.
Service topologyDerived from observed span relationships.
Tenant ingestion usage notificationsWarning and critical notifications; limits do not block ingestion.
Trace retention policiesSupports periods of 7, 15, or 30 days; confirm available values for your deployment.