title |
---|
Telemetry Types |
Odigos supports the producing and correlation of the following telemetry types:
- Distributed 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.
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:
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.)
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
processor.
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-related metrics are collected via the host metrics receiver
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.