This section describes downloading and installing the trace proxy in various platforms and pointing to your trace-instrumented application.

Follow the steps below for more information on trace collection:

  1. Log in to the OpsRamp Portal.

  2. Navigate to Infrastructure > Traces.

  3. On the Traces Configuration page, click LET’S GET STARTED.

  4. You can also access the Traces Configuration from the Menu icon on the left side of this page as shown below.

  5. Follow the instructions to set up the trace collection under the Set up Traces Collection section.

At present, OpsRamp supports two types of environments where you can setup the trace proxy: Kubernetes and Host Based.

Configure Trace proxy

This section details about configuring the trace proxy based on user needs. The trace proxy consists of three main resources:

  • Listener: The purpose of a listener is to collect, store, and route tracing messages. Listeners direct the tracing output to an appropriate target, such as a down sampler.
  • Down Sampler: As a trace is a representation of the life cycle of a particular operation, most of the data may not be useful to the user. The downsampling is the process of reducing the sampling rate of the data received from the listener. The trace proxy handles the task of downsampling all the traces to reduce the traffic in the portal.
  • Exporter: Each time a trace span arrives at the exporter, the exporter sends the traces to the OpsRamp cloud and then to the storage to store the data.

Follow the steps below to find out the details about trace collection:

  1. Log in to the OpsRamp Portal.

  2. Navigate to Infrastructure > Traces.

  3. On the Traces Configuration page, click LET’S GET STARTED.

  4. You can also access the Traces Configuration from the Menu icon on the left side of this page.
    Follow the instructions to configure the trace proxy under Configure Trace Proxy section.

    The trace proxy is configured.

Handle Trace Events

Trace events, within the context of a tracing system, denote the instances or actions recorded during the tracing process. In the context of distributed tracing, trace or span events are a part of span which details more about the span’s journey as it traverses through various components.

Events within OpenTelemetry protocol (OTLP) trace payloads ingested into OpsRamp are now accessible for viewing on the Logs Explorer page. By applying a query filter with source as trace and type as events, you can easily locate and examine these trace events.

Below configurations have been made to the trace proxy configuration file to forward span events as logs:

  • LogsEndpoint refers to the URL to push events as logs.

  • SendEvents when set to true, sends the span events as logs, allowing them to be viewed in the Logs explorer.

    Note: You can set the SendEvents parameter to false to stop sending the span events as logs.

Multiple Proxy configurations support

OpsRamp Tracing Solution has a fallback system which is designed to route traffic through a series of proxy servers to ensure continuous service availability. If one proxy fails, the system automatically reroutes the traffic to the next available proxy in the list.

In the OpsRamp tracing solution, multiple proxy configurations can indeed be specified by delimiting the values with a pipe symbol "|".

For example:

Single proxy configuration

Multiple proxy configuration

In the multiple proxy configuration, the pipe symbol "|" is used to separate the different proxy server addresses. Each address represents a separate proxy server that the system uses for routing or forwarding requests.

Span Classification

The information associated with each span has been enhanced by introducing additional attributes. These attributes can provide more context and details about the nature of the spans.

AttributeDescriptionPossible Values
transaction.typeTypically classifies the spans as web transactions (such as REST API calls, RPC calls from different frameworks, interactions with load balancers, and requests handled by web servers) and non-web transactions (internal scheduled jobs, cleanup tasks, and other operations not directly associated with external-facing web services).
  • web
  • non-web
transaction.categoryThe classification of spans is based on their originating sources; if a span originates from a database, it is categorized as a "Database," and if it originates from an RPC system, it is classified as an "RPC System,".
  • HTTP
  • Database
  • etc.
transaction.sub_categoryThe spans are further categorized based on attributes. For spans originating from a database, the classification is determined by the specific database it originated from, utilizing the db.system attribute. Similarly, for spans originating from an RPC system, the classification is based on the rpc.system attribute.
  • MySQL
  • Kafka
  • etc.