Documentation forSolarWinds Observability

Migrate the Ruby Library from AppOptics to SolarWinds Observability

Before you start

Verify the following to ensure the library can collect and transmit data:

  • The platform where your APM library will be installed is supported.

  • Your application components are supported by the library.

  • Your firewall configuration permits TCP/HTTPS/TLS outbound connections to (where xx-yy is determined by the URL you use to access SolarWinds Observability, described in Data centers and endpoint URIs) using port 443. See Firewall or access control requirements.

    If your firewall or access control requirements do not allow such connections, configure the library to send data through a proxy.

Remove other APM libraries from your Ruby application before using the SolarWinds Observability Ruby Library. See Remove other APM libraries.

Migrate from AppOptics

AppOptics users can use the following information to migrate to SolarWinds Observability.

  1. Remove any references to the AppOptics custom instrumentation API in your application code.

    Save a list detailing your application's usage so it can be updated for the SolarWinds Observability Ruby Library's instrumentation API.

  2. Uninstall the AppOptics agent from your application by following the instructions in Uninstalling the Agent.

  3. Install the SolarWinds Observability Ruby Library.

    • Code Profiling is currently not supported.

    • The AppOptics configuration file should not be reused. Instead, generate a new SolarWinds Observability Ruby Library configuration file. See Configure the Ruby Library.

  4. Set the collector configuration option to the AppOptics endpoint Use an environment variable to override the default APM collector endpoint.

  5. Update to use the new instrumentation API if needed.

    The SolarWinds Observability Ruby Library has been updated to use the W3C Trace Context Headers for distributed trace propagation. This update has required a few changes to the Ruby Library SDK and impacts how to receive and how to propagate trace context to external spans. The following changes are of particular note:

    • Tracing.start_trace() parameter names have been refactored. If an upstream W3C Trace Context should be continued, it should be passed in the headers parameter and consist of two identifiers, where one is the traceparent and the other is the tracestate.

      The new TraceContextHeaders module can also be used to manually inject the W3C Trace Context into outbound HTTP headers.

    • CurrentTrace module has been renamed to CurrentTraceInfo and now provides a W3C Trace Context for injection into logs as the three attributes trace_id, span_id and trace_flags.

    See Ruby Library instrumentation SDK.