Accelerate Otel Adoption with Elastic Agent Hybrid Ingestion

Hybrid Elastic Agent: The Most Practical Path to OpenTelemetry Adoption

OpenTelemetry is quickly becoming the standard foundation for modern observability. Organizations want its open ecosystem, unified model, and vendor-neutral instrumentation—but moving a mature production environment to OTel is rarely straightforward.

Most teams already rely on battle-tested pipelines for logs, metrics, and security signals. They have dashboards tuned over years, operational practices built around existing data flows, and mission-critical systems where disruption simply isn’t an option.

This means the question isn’t "Why OpenTelemetry?" It’s "How do we get there without breaking what already works?"

Elastic Observability introduces a way to ingest telemetry without disrupting existing data and dashboards with Hybrid ingestion. Released in Elastic 9.2, its a low-friction way to adopt OTel receivers alongside existing native Elastic integrations-managed centrally through Fleet.

This hybrid approach offers one of the most pragmatic and operationally safe routes to OTel adoption available today.

The Challenge: Adopting OTel Without Disrupting the Present

For many organizations, the path to OTel adoption is complicated by realities such as:

• Established log pipelines powering critical alerting
• Legacy infrastructure that isn’t easily re-instrumented
• Existing dashboards and visualizations built on Elastic-native datasets
• Teams with different levels of OTel experience
• Risk constraints that make large changes difficult to roll out

Standardizing on OTel is the right long-term direction, but replacing everything at once is neither realistic nor desirable.

Teams need a way to bring OTel into their environment incrementally, while preserving continuity, reliability, and central governance.

Elastic Agent 9.2+: Hybrid Ingestion as a Bridge to the Future

Elastic Agent now supports two fully supported ingestion paths, both running inside the same unified agent:

1. Elastic-native integrations

Perfect for logs and host-level telemetry, with mature dashboards, alerts, and ECS mappings.

2. OpenTelemetry input integrations (OTel receivers)

Powered by upstream OTel Collector components, managed directly from Fleet.

And crucially:

You can use both, simultaneously, on the same agent.

This hybrid ingestion model allows teams to:

• Continue collecting logs using native Elastic integrations
• Begin collecting metrics or traces via OTel receivers
• Maintain full control through Fleet
• Introduce OTel exactly where and when it makes sense
• Avoid running parallel agents or duplicate pipelines

It’s a way to evolve—not replace—your observability strategy.

A Practical Example: Adding OTel Inputs While Keeping Your Existing Pipelines

Imagine a system where NGINX logs are already handled via Elastic-native integrations. These pipelines drive dashboards, audits, and critical alerts. Interrupting them isn’t an option.

At the same time, your platform team wants to standardize metrics and service telemetry using OpenTelemetry.

With Elastic Agent hybrid ingestion, both goals align:

1. Keep your existing log integration in Fleet
2. Add an OTel input integration (e.g., OTel nginxreceiver)
3. Fleet deploys both inside the same Elastic Agent
4. Deployment is done at scale across your infrastructure from a single management console
5. Logs and OTel metrics flow into Elasticsearch side-by-side

No re-instrumentation. No duplicate agents. No loss of historical visibility. No new tooling for operations. No external deployment tool.

Whether the component is a web server, reverse proxy, database, JVM runtime, or custom service already instrumented in OTel, the workflow is the same.

Why This Hybrid Approach Matters Strategically

Hybrid ingestion is not simply a technical capability—it’s an organizational enabler for OpenTelemetry transformation.

Incremental migration without downtime

Teams can begin adopting OTel at the exact pace they’re comfortable with. Existing collection signals remain stable. OTel metrics or logs are added progressively.

Fleet remains your single control plane

Fleet continues to manage:

• agent lifecycle
• policy management
• version upgrades
• diagnostics and monitoring

Even as OTel becomes part of your ingestion strategy.

Consistent semantics across teams

Adopting OTel receivers through EDOT helps harmonize telemetry models across microservices, infrastructure, and applications.

OTel becomes the shared language—Elastic becomes the scalable backend.

Future-proof flexibility

When the day comes that a team needs advanced OTel features, custom pipelines, custom processors, or additional exporters, they can build their own EDOT custom collector flavor and use it in their elastic-agent in hybrid mode.

This allows deep customization without abandoning the Elastic Agent runtime.

No vendor lock-in—full ecosystem alignment

Hybrid ingestion leverages upstream OpenTelemetry components directly. This reinforces the open, vendor-neutral ecosystem organizations prefer when standardizing observability across teams while being supported by Elastic.

What About Standalone Mode? (Advanced Use Cases)

While Fleet-managed hybrid ingestion will meet the needs of most users, Elastic Agent in hybrid mode also support standalone deployment with the same functions as the managed version.

• native integrations support
• full control over Otel receivers, processors, and exporters
• Elasticsearch output as the backend

This is particularly useful for platform teams testing advanced OTel deployments or building custom telemetry strategies.

But it remains optional—the managed experience is still the default path.

Conclusion: A Modern, Flexible Path Toward OpenTelemetry

Migrating to OpenTelemetry is a journey, not a switch. With hybrid ingestion, Elastic provides a realistic, scalable, and low-risk pathway for organizations that want to adopt OTel gradually while maintaining operational continuity.

Elastic Agent 9.2+ enables teams to:

• retain reliable log integrations
• introduce OTel inputs seamlessly
• manage everything from Fleet
• reduce complexity and operational overhead
• expand into OTel at the right pace
• stay aligned with open standards and best practices

It brings the best of both worlds—Elastic-native richness and OTel-standard flexibility—into a single agent and a unified operational model.

Hybrid isn’t a workaround. It’s the strategic bridge between where your observability platform is today and where it needs to go next.

Technical Walkthrough: Deploying Hybrid Elastic Agent + EDOT in Fleet

Before we close, let’s look at what this actually looks like in practice. Conceptual advantages are important, but many teams want to see how hybrid ingestion works when deployed through Fleet.

The example below walks through a simple, production-ready setup using Elastic Agent 9.2, combining a native integration and an OTel input integration inside a single agent, the same approach you can apply to any service across your environment.

Here is a step-by-step guide showing how to deploy Elastic Agent 9.2 in Fleet-managed hybrid mode, using the OTel nginxreceiver as one concrete example. This applies to any service with an OTel receiver (Redis, HAProxy, Kafka, JVM, etc.).

Requirements

• Elastic Stack 9.2+
• Elastic Agent 9.2+
• Fleet configured in Kibana
• A host running your workload (NGINX in this example)
• NGINX
  stub_status
  endpoint or any equivalent OTel metrics endpoint
• API key with ingest privileges

1. Create or Select an Agent Policy

1. In Kibana → Management → Fleet → Agent policies
2. Create a new policy:
   nginx-o11y
3. Enable system monitoring (recommended)
4. Save

2. Enroll Elastic Agent into the Policy

From the policy page:

1. Click Add agent
2. Choose your OS
3. Copy the installation command
4. Run:

sudo elastic-agent install \
  --url=<FLEET_URL> \
  --enrollment-token=<ENROLLMENT_TOKEN>

You should soon see the agent appear as Healthy in Fleet.

3. Add the Native Integration (Logs)

1. In Fleet, go to Integrations.
2. Search for NGINX.
3. Click Add NGINX.
4. Select your
   nginx-o11y
   policy.
5. Only enable log collection (access + error logs).
6. Save and deploy.

4. Validate Log Collection

1. In Kibana, go to Analytics → Discover and search for:

data_stream.dataset : "nginx.access" or "nginx.error"

2. Or open the built-in dashboard:

Analytics → Dashboards → [Logs Nginx] Access and error logs

5. Collecting NGINX Metrics via the OTel NGINX Receiver

Elastic Agent 9.2+ allows Fleet to deploy OTel input integrations.
This scenario uses the OpenTelemetry

5.1. Install the NGINX OpenTelemetry Integration Content

1. In Kibana, go to Management → Fleet → Integrations.
2. Search for NGINX OpenTelemetry Assets.
3. Click Add Integration.

5.2. Install the NGINX OpenTelemetry Input Integration

1. In Kibana, go to Management → Fleet → Integrations.
2. Search for NGINX OpenTelemetry Input Package.
3. Click Add Integration.
4. Assign it to your agent
   nginx-o11y
   policy.

Provide the endpoint for the NGINX status page:

• Endpoint:
  http://localhost/status
• Collection interval:
  10s

Click Add integration.

6. Validate OTel Metrics

1. Go to Analytics → Dashboards.
2. Open: [Metrics Nginx OTEL Overview] Dashboard

You should see metrics such as active connections, writes, reads, waiting, and request counts.

7. Closing thoughts

This example highlights how straightforward hybrid ingestion becomes with Elastic Agent 9.2. By combining native integrations and OTel receivers within a single, centrally managed policy, you gain the flexibility to adopt OpenTelemetry where it adds the most value without disrupting existing pipelines or introducing operational overhead.

Whether you extend this pattern to additional services, experiment with other OTel receivers, or scale it across your fleet, the deployment model remains consistent, repeatable, and production-ready.

For more information and other innovations Elastic Observability has made check out:

• Discover how Elastic is evolving data ingestion with OpenTelemetry

• Learn how OpAMP enables centralized configuration of OpenTelemetry SDKs

• Explore how Streams reshape AI-driven log investigation workflows