Odigos

Name: Odigos
Brand: Odigos

AI Native

Observability built to conquer outages

Est 2023|Raised $13.5M

LinkedIn 2K|Web traffic 6K|FTEs 36|HQ Boston, Massachusetts, US

MarketsObservability Platform Application Performance Monitoring (APM)

Published Sep 26, 2026

01Common complaints

1. **Requirement for a fully integrated, end-to-end commercial observability suite** - If an organization requires a single-vendor suite that includes unified billing, mature alerting and incident workflows, RUM/synthetics, and integrated analytics, commercial APM providers may be a better fit. 2. **Environments that are incompatible with eBPF (kernel/version fragmentation, locked-down nodes)** - If kernels cannot be standardized or the platform restricts the required kernel versions, eBPF-based strategies may create extended troubleshooting and operational risk. 3. **Procurement that requires publicly documented security certifications prior to shortlisting** - If SOC 2 Type II or ISO 27001 documentation is a gating item and Odigos cannot provide it early in procurement, organizations may need to consider vendors with clearer public compliance documentation. 4. **Requirement for explicit application-level instrumentation for richer business context** - Auto-instrumentation often generates generic spans; if the primary value depends on high-quality, domain-specific spans, manual instrumentation using OpenTelemetry SDKs may still be necessary.

Deal disqualifiers (poor fit)

Procurement policies that require publicly available security/compliance attestations (e.g., SOC 2 or ISO certifications) before evaluation.
Highly heterogeneous or legacy environments where eBPF rollout is impractical due to kernel fragmentation or tightly locked-down nodes.
Teams that require extensively curated, domain-specific spans and prefer manual instrumentation as a rule.

Vendor-acknowledged / documented limitations

Kernel requirement for enterprise eBPF data collection: Odigos documents a minimum Linux kernel version of 5.4.0 for eBPF-based collection.
Vendor-maintained benchmarks: Odigos publishes benchmark methodology and resource guidance, but these are vendor-controlled and should be validated in the purchaser’s environment.

Common limitations implied by the ecosystem

eBPF tooling can face compatibility constraints across distributions, kernels, and managed Kubernetes offerings.
Auto-instrumentation may not fully replace manual instrumentation for high-quality, domain-specific tracing.

Roadmap / future features

No formal public roadmap was identified in the accessible sources during this research.

02Why they buy

Unique selling points with evidence from accessible sources

- **Automation and control-plane approach:** Odigos materials position it as an observability control plane that deploys and scales collectors and pipelines automatically. - **Language detection and reduced annotation requirements:** Community discussion indicates that Odigos’ language detection can reduce the need for per-workload annotations. - **OpenTelemetry interoperability:** Odigos emphasizes OTel-native formats and OTLP compatibility with multiple destinations.

Where competitors have advantages

OBI/Beyla: Upstream OpenTelemetry alignment and community momentum.
Commercial APMs: More mature enterprise support, broader product capabilities, and clearer compliance documentation.

03Field reports

Important naming/market confusion: “Odigos” vs “Odigo”

A significant risk when gathering third-party reviews is a name collision: - **Odigos (observability vendor)** = OpenTelemetry/eBPF/Kubernetes observability tooling. - **Odigo (contact-center vendor)** = Contact Center as a Service (CCaaS) vendor. Several review-platform pages that surfaced in searches appear to be for Odigo (CCaaS) rather than Odigos (observability). Examples include G2 and Gartner pages that reference contact-center features. These listings should not be used to assess Odigos (observability). This means that mainstream review-platform results are often misattributed and coverage for Odigos is comparatively thin on those platforms.

Review platforms (G2 / Gartner Peer Insights / TrustRadius)

- **G2:** A page exists for “Odigo” with a small number of reviews; content appears inconsistent and unrelated to Odigos’ observability product. Treat as misattributed. - **Gartner Peer Insights:** Similar mismatch observed; the accessible page references CCaaS functionality rather than observability. - **TrustRadius:** No clearly relevant Odigos (observability vendor) review page was located in the sources reviewed. **Bottom line:** Traditional enterprise review platforms did not yield reliable Odigos-specific buyer feedback in accessible sources during this research.

Community / social proof (Reddit, GitHub)

Community discussion contains useful feedback relevant to Odigos: - A Reddit post noted appreciation for the Odigos open-source community for simplifying instrumentation for distributed tracing and mentioned practical usage. - Reddit discussions in Kubernetes communities compare solutions and note that Odigos can reduce the need to annotate every workload by auto-detecting languages. - Reddit and other community forums also include critiques of eBPF approaches more broadly (kernel-version troubleshooting) and discuss tradeoffs compared with traditional OpenTelemetry auto-instrumentation.

Reasons users cite for selecting Odigos (from community signals)

Reduced engineering effort and faster access to distributed tracing data.
Language detection that reduces the need for per-workload annotations.
Claims that tracing can be enabled without application code changes are attractive to teams facing resistance to manual instrumentation.

Reasons for avoidance or churn (inferred from community and eBPF realities)

Kernel compatibility and troubleshooting complexity associated with eBPF can be time-consuming.
Auto-instrumentation may increase noise and require tuning to maintain trace relevance.
Some organizations prefer explicit SDK-based instrumentation to capture richer, domain-specific spans.

Vendor/community case mentions

A community post describes a team that integrated Odigos to ingest distributed tracing data into a causal AI platform and documented the experience in a blog post referenced in a forum thread.

Quantified outcomes

No independently verified ROI or TEI studies specific to Odigos were located in the accessible sources during this research.

Critical evaluation

Odigos provides benchmark documentation and resource guidance; these documents are vendor-maintained and should be used as directional input rather than definitive proof of performance across all environments.
Benchmarks and resource impacts should be reproduced under the purchaser’s kernel versions, service mesh or networking stack, traffic patterns, and language/runtime mix.

04Best fit

Company sizes

Most likely fit: mid-size to large organizations with a meaningful microservices/Kubernetes footprint.
Particularly relevant where multiple teams and services slow centralized instrumentation efforts.

Industries

Technology/SaaS, fintech, marketplaces, and organizations running Kubernetes-based microservices.

Roles and personas

Decision makers: Head of Platform/Infrastructure, SRE leadership, CTO/VP Engineering.
End users: SREs, platform engineers, and service owners.

Pain points addressed

Difficulty delivering distributed tracing across a microservices estate in a timely manner.
Challenges in getting multiple teams to add and maintain instrumentation.
Need for language-agnostic visibility across Kubernetes clusters.

Qualification criteria (good fit)

The organization is standardizing on OpenTelemetry or intends to.
The organization runs Kubernetes and maintains consistent kernel/platform baselines.
There is an existing observability backend that supports OTLP.

05The pitch

What the product does (objective value proposition)

Odigos is an open-source observability control plane focused on automating OpenTelemetry (OTel) pipelines—especially for Kubernetes—by auto-instrumenting workloads and managing collection/export of traces (and, depending on configuration/product edition, metrics/logs) with minimal or no application code changes. It relies on eBPF-based instrumentation to reduce manual SDK instrumentation work and to shorten the time required to obtain distributed tracing data in modern, polyglot environments. In practice, Odigos deploys Kubernetes components (operators/agents/collectors) that: - Detect workloads and languages, then apply automatic instrumentation. - Create and scale telemetry pipelines/collectors based on traffic. - Export OTel-format data to supported destinations via OTLP. Key product claims (vendor-stated): - Vendor materials state the product can enable distributed tracing without application code changes and that it aims to provide rapid access to tracing data. - eBPF-powered auto-instrumentation. - Compatibility with existing observability tools via OpenTelemetry/OTLP. (These claims are described in Odigos documentation and the project README.)

Target market and positioning

- **Primary users:** platform engineers, SREs, DevOps, and developers operating Kubernetes (and some VM) environments who want to accelerate OpenTelemetry adoption. - **Positioning:** a layer that simplifies and automates OTel rollout (instrumentation and pipelines) rather than replacing the customer’s existing tracing/metrics/log backends. Odigos materials indicate a preference for users who are comfortable with command-line interfaces and basic cloud infrastructure, suggesting a technical buyer persona rather than line-of-business buyers.

Get a comprehensive analysis of Odigos including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →

Published Sep 26, 2026

01Common complaints

Requirement for a fully integrated, end-to-end commercial observability suite
- If an organization requires a single-vendor suite that includes unified billing, mature alerting and incident workflows, RUM/synthetics, and integrated analytics, commercial APM providers may be a better fit.
Environments that are incompatible with eBPF (kernel/version fragmentation, locked-down nodes)
- If kernels cannot be standardized or the platform restricts the required kernel versions, eBPF-based strategies may create extended troubleshooting and operational risk.
Procurement that requires publicly documented security certifications prior to shortlisting
- If SOC 2 Type II or ISO 27001 documentation is a gating item and Odigos cannot provide it early in procurement, organizations may need to consider vendors with clearer public compliance documentation.
Requirement for explicit application-level instrumentation for richer business context
- Auto-instrumentation often generates generic spans; if the primary value depends on high-quality, domain-specific spans, manual instrumentation using OpenTelemetry SDKs may still be necessary.

Deal disqualifiers (poor fit)

Procurement policies that require publicly available security/compliance attestations (e.g., SOC 2 or ISO certifications) before evaluation.
Highly heterogeneous or legacy environments where eBPF rollout is impractical due to kernel fragmentation or tightly locked-down nodes.
Teams that require extensively curated, domain-specific spans and prefer manual instrumentation as a rule.

Vendor-acknowledged / documented limitations

Kernel requirement for enterprise eBPF data collection: Odigos documents a minimum Linux kernel version of 5.4.0 for eBPF-based collection.
Vendor-maintained benchmarks: Odigos publishes benchmark methodology and resource guidance, but these are vendor-controlled and should be validated in the purchaser’s environment.

Common limitations implied by the ecosystem

eBPF tooling can face compatibility constraints across distributions, kernels, and managed Kubernetes offerings.
Auto-instrumentation may not fully replace manual instrumentation for high-quality, domain-specific tracing.

Roadmap / future features

No formal public roadmap was identified in the accessible sources during this research.

02Why they buy

Unique selling points with evidence from accessible sources

Automation and control-plane approach: Odigos materials position it as an observability control plane that deploys and scales collectors and pipelines automatically.
Language detection and reduced annotation requirements: Community discussion indicates that Odigos’ language detection can reduce the need for per-workload annotations.
OpenTelemetry interoperability: Odigos emphasizes OTel-native formats and OTLP compatibility with multiple destinations.

Where competitors have advantages

OBI/Beyla: Upstream OpenTelemetry alignment and community momentum.
Commercial APMs: More mature enterprise support, broader product capabilities, and clearer compliance documentation.

03Field reports

Important naming/market confusion: “Odigos” vs “Odigo”

A significant risk when gathering third-party reviews is a name collision:

Odigos (observability vendor) = OpenTelemetry/eBPF/Kubernetes observability tooling.
Odigo (contact-center vendor) = Contact Center as a Service (CCaaS) vendor.

Several review-platform pages that surfaced in searches appear to be for Odigo (CCaaS) rather than Odigos (observability). Examples include G2 and Gartner pages that reference contact-center features. These listings should not be used to assess Odigos (observability).

This means that mainstream review-platform results are often misattributed and coverage for Odigos is comparatively thin on those platforms.

Review platforms (G2 / Gartner Peer Insights / TrustRadius)

G2: A page exists for “Odigo” with a small number of reviews; content appears inconsistent and unrelated to Odigos’ observability product. Treat as misattributed.
Gartner Peer Insights: Similar mismatch observed; the accessible page references CCaaS functionality rather than observability.
TrustRadius: No clearly relevant Odigos (observability vendor) review page was located in the sources reviewed.

Bottom line: Traditional enterprise review platforms did not yield reliable Odigos-specific buyer feedback in accessible sources during this research.

Community / social proof (Reddit, GitHub)

Community discussion contains useful feedback relevant to Odigos:

A Reddit post noted appreciation for the Odigos open-source community for simplifying instrumentation for distributed tracing and mentioned practical usage.
Reddit discussions in Kubernetes communities compare solutions and note that Odigos can reduce the need to annotate every workload by auto-detecting languages.
Reddit and other community forums also include critiques of eBPF approaches more broadly (kernel-version troubleshooting) and discuss tradeoffs compared with traditional OpenTelemetry auto-instrumentation.

Reasons users cite for selecting Odigos (from community signals)

Reduced engineering effort and faster access to distributed tracing data.
Language detection that reduces the need for per-workload annotations.
Claims that tracing can be enabled without application code changes are attractive to teams facing resistance to manual instrumentation.

Reasons for avoidance or churn (inferred from community and eBPF realities)

Kernel compatibility and troubleshooting complexity associated with eBPF can be time-consuming.
Auto-instrumentation may increase noise and require tuning to maintain trace relevance.
Some organizations prefer explicit SDK-based instrumentation to capture richer, domain-specific spans.

Vendor/community case mentions

A community post describes a team that integrated Odigos to ingest distributed tracing data into a causal AI platform and documented the experience in a blog post referenced in a forum thread.

Quantified outcomes

No independently verified ROI or TEI studies specific to Odigos were located in the accessible sources during this research.

Critical evaluation

Odigos provides benchmark documentation and resource guidance; these documents are vendor-maintained and should be used as directional input rather than definitive proof of performance across all environments.
Benchmarks and resource impacts should be reproduced under the purchaser’s kernel versions, service mesh or networking stack, traffic patterns, and language/runtime mix.

04Best fit

Company sizes

Most likely fit: mid-size to large organizations with a meaningful microservices/Kubernetes footprint.
Particularly relevant where multiple teams and services slow centralized instrumentation efforts.

Industries

Technology/SaaS, fintech, marketplaces, and organizations running Kubernetes-based microservices.

Roles and personas

Decision makers: Head of Platform/Infrastructure, SRE leadership, CTO/VP Engineering.
End users: SREs, platform engineers, and service owners.

Pain points addressed

Difficulty delivering distributed tracing across a microservices estate in a timely manner.
Challenges in getting multiple teams to add and maintain instrumentation.
Need for language-agnostic visibility across Kubernetes clusters.

Qualification criteria (good fit)

The organization is standardizing on OpenTelemetry or intends to.
The organization runs Kubernetes and maintains consistent kernel/platform baselines.
There is an existing observability backend that supports OTLP.

05The pitch

What the product does (objective value proposition)

In practice, Odigos deploys Kubernetes components (operators/agents/collectors) that:

Detect workloads and languages, then apply automatic instrumentation.
Create and scale telemetry pipelines/collectors based on traffic.
Export OTel-format data to supported destinations via OTLP.

Key product claims (vendor-stated):

Vendor materials state the product can enable distributed tracing without application code changes and that it aims to provide rapid access to tracing data.
eBPF-powered auto-instrumentation.
Compatibility with existing observability tools via OpenTelemetry/OTLP.

(These claims are described in Odigos documentation and the project README.)

Target market and positioning

Primary users: platform engineers, SREs, DevOps, and developers operating Kubernetes (and some VM) environments who want to accelerate OpenTelemetry adoption.
Positioning: a layer that simplifies and automates OTel rollout (instrumentation and pipelines) rather than replacing the customer’s existing tracing/metrics/log backends.

Odigos materials indicate a preference for users who are comfortable with command-line interfaces and basic cloud infrastructure, suggesting a technical buyer persona rather than line-of-business buyers.

Get a comprehensive analysis of Odigos including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →