Skip to content
Start free

Solutions · Use case

Standardize on OpenTelemetry, one service at a time

Instrument with upstream OpenTelemetry SDKs, your own OpenTelemetry Operator or zero-code eBPF on Linux, and send OTLP straight to your workspace. The Instrumentation view shows each service's SDK, version and signals, and what still needs attention.

Talk to our teamRead the instrumentation docs

What changes

Four problems teams bring to an OpenTelemetry rollout

  • Every team instruments differently

    The Instrumentation view lists each service's SDK or agent, its versions against the latest release, the signals it sends and what needs attention, such as mixed versions or older span attributes.

  • Services nobody can change yet

    Turn on eBPF tracing in the collector on Linux, kernel 5.8 or later with BTF, for request spans with no code changes, or let your OpenTelemetry Operator inject agents for Java, .NET, Node.js and Python.

  • Collectors configured by hand on every host

    The Tracix Collector is an OpenTelemetry Collector distribution. Each one enrolls with a policy, receives signed configuration and upgrades from the console, on Linux, macOS, Windows, Docker and Kubernetes.

  • Signals that never connect

    Traces, metrics and logs land in one workspace. A trace opens its logs and the pod it ran on, and browser and mobile spans carry trace context into your backend traces.

Products

The products behind each answer

Each product reads the same OpenTelemetry data, with the attribute names your SDKs send.

Rollout

Start with one service, then the fleet

Our solutions engineers plan each phase with your platform and application teams.

  1. 01Instrument one serviceCreate an ingest key, point an OpenTelemetry SDK at your workspace's OTLP endpoint, and confirm the first trace on the Setup page.
  2. 02Roll out collectors by policyInstall the Tracix Collector on hosts and clusters, enroll each with a policy, and turn on host metrics, logs and eBPF tracing where you need them.
  3. 03Close the gapsWork through the Instrumentation view: upgrade older agents, rename deprecated attributes, and export the logs and runtime metrics services are missing.

Resources

FAQ

Questions platform teams ask first

Ask a solutions engineer
Do we need the Tracix Collector to send OpenTelemetry data?
No. SDKs and your own OpenTelemetry Collector can send OTLP over HTTP or gRPC straight to your workspace with an ingest key. The Tracix Collector adds host metrics, logs, eBPF tracing, network data and management by policy.
Is eBPF tracing a replacement for SDKs?
Not on its own. eBPF tracing sees each request at one service, so traces don't follow requests across services, and its runtime metrics cover only Go and the JVM. Use it for coverage now, and add SDKs where you need distributed traces.
Which languages are covered?
Setup has instructions for OpenTelemetry's twelve languages, plus an Other option for any SDK that reads the standard OTEL_* variables. The OpenTelemetry Operator can inject agents for Java, Kotlin, .NET, Node.js and Python.
Can Tracix query our Prometheus metrics?
The collector scrapes Prometheus endpoints, and the metrics explorer, dashboards and monitors query what it collects. Tracix doesn't run Prometheus's own query language or accept pushed Prometheus data.

Plan your OpenTelemetry rollout

Bring your service list and your collector plans. We will map the first phase with you.

Talk to our teamStart free