Elastic Observability vs OpenTelemetry: Are We Finally on the "Right" Path?

Elastic Observability
11

Thanks again for the clarification around EDOT and the OTel direction.

To make this more concrete for OpenShift-based environments, I’d like to validate whether the following architecture aligns with Elastic’s recommended and supported approach:

[OpenShift Cluster]

  • OTel Collector (Operator-managed, DaemonSet or Deployment)

  • Minimal processing (k8s enrichment, batching)

  • Export via OTLP↓

=> [Central Ingest / Gateway Tier]

  • OTel Collector (EDOT or upstream)

  • Aggregation, routing, buffering, multi-tenant handling↓

=> [Elastic (ECE)]

Questions:

  1. Is this hybrid model (in-cluster collectors + central gateway tier) considered a recommended / supported reference architecture by Elastic?
  2. Is EDOT intended to run in both layers, or primarily at the gateway tier?
  3. For OpenShift specifically, is Elastic Agent expected to replace the in-cluster OTel collectors over time, or should OTel Operator remain the preferred approach?
  4. Are there any known limitations or support boundaries for this model (e.g. Fleet-managed collectors, SCC constraints, buffering expectations)?

Trying to align with a production-grade design for regulated environments.

Thanks!