Odigos supports the producing and correlation of the following telemetry types:
  • Traces
  • Metrics
  • Logs
For a telemetry type to be collected, a destination that accepts it must be configured. In addition, users can enable or disable the collection of a telemetry type on a per-application basis. If none of the applications are configured to collect a telemetry type, the telemetry type will not be collected.

​
Traces

Distributed traces collected by Odigos will automatically include spans for popular open source projects such as HTTP clients and servers, gRPC clients and servers, Database clients, and many more. In addition, users can enrich their distributed traces with manually created spans by using the relevant OpenTelemetry APIs. The collection of traces is achieved by combining two open source technologies:
  • OpenTelemetry for languages with JIT compilation such as Python, Java,.NET and Javascript.
  • eBPF for compiled languages such as Go.
Being based on popular open-source standards allows Odigos to automatically support a huge number of libraries and frameworks. Below is a list of supported libraries for every language:

Go

opentelemetry-go-instrumentation/ pkg/ instrumentors/ bpf/

Javascript

opentelemetry-js-contrib/ plugins/ node/

Python

opentelemetry-python-contrib/ instrumentation/

Java

opentelemetry-java-instrumentation/ instrumentation/

PHP

opentelemetry-php-contrib/ src/ Instrumentation/

Ruby

opentelemetry-ruby-contrib/ instrumentation/

.NET

opentelemetry-dotnet-instrumentation/ docs/ config.md

​
Metrics

There are three kinds of metrics that Odigos supports:
  • Metrics related to the running of the application (number of HTTP requests, latency, DB connections, etc.)
  • Metrics related to the language runtime (GC, threads, heap, etc.)
  • Metrics related to the host environment (CPU, memory, disk, etc.)

​
Applicative Metrics

Application-related metrics are derived from the distributed traces described above. Many observability vendors automatically compute application metrics according to the distributed traces. For example, the number of requests served by the application is computed by counting the number of spans with the http.server label. In case a destination that does not automatically compute application metrics (like Prometheus + Tempo) is configured, Odigos will compute them on its own by invoking the spanmetrics connector.

​
Runtime Metrics

Those metrics describe the behavior of the language runtime, such as garbage collection, threads, heap, etc. Runtime metrics are collected by the same mechanism that collects distributed traces.

​
Host Metrics

Host-related metrics are collected via the host metrics receiver

​
Logs

Currently, Odigos will ship logs written by the application to the stdout or stderr of the process. Correlation to other telemetry types will be done according to timestamp and resource. We are in the process of shipping logs using the same mechanism that collects distributed traces, this would allow users to correlate logs to distributed traces and metrics in a more accurate way.