The following sequence describes how application spans become available for investigation in OpsRamp.

From application to OpsRamp

  1. Instrument the application. An OpenTelemetry SDK or supported service-mesh integration creates spans.
  2. Propagate context. Trace and parent-span identifiers cross service boundaries with application requests or messages.
  3. Export spans. The application sends OTLP over gRPC or HTTP to the OpsRamp trace proxy, optionally through an OpenTelemetry Collector.
  4. Process at the collection tier. A Collector can batch and process traffic before the trace proxy. The required trace proxy assembles traces, applies trace-aware sampling rules, and forwards accepted trace data to OpsRamp.
  5. Use the correct settings. Configure applications and Collectors with the proxy’s application-facing endpoint. Configure OpsRamp authentication and client settings only on the trace proxy.
  6. Verify arrival. Trigger a representative request and find its service or trace ID in OpsRamp using a time range that includes the request.

Investigate the result

  1. Select the intended client and open the trace views with an authorized user account.
  2. Filter by service, operation, trace ID, or available attributes.
  3. Inspect span timing, parent-child relationships, status, and recorded attributes or events.
  4. Compare service and operation metrics to understand whether the issue affects a single request or a wider population.

Manage availability and volume

Sampling can remove traces before they reach OpsRamp. Export batching can delay visibility, and retention limits how long accepted data remains available. Review these settings and client usage notifications when investigating missing data or planning production volume.