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

Hi willemdh,

the RedHat distro and operator integrates natively with the OpenShift security controls / context constraints and platform. It's a recommended choice to use it. The EDOT collector is supported on OpenShift but is not specialized to it.

For Central Ingest / Gateway the EDOT collector or an EDOT-like custom collector is recommended here. Just make sure you have all necessary components in the collector if you build your own.

  1. Is this hybrid model (in-cluster collectors + central gateway tier) considered a recommended / supported reference architecture by Elastic?

Yes. It's described in the Kubernetes reference architecture.

  1. Is EDOT intended to run in both layers, or primarily at the gateway tier?

You can run it on both layers.

  1. For OpenShift specifically, is Elastic Agent expected to replace the in-cluster OTel collectors over time, or should OTel Operator remain the preferred approach?

No. Only if you need a feature that is only provided by the Elastic Agent (e.g. Fleet Management).

  1. Are there any known limitations or support boundaries for this model (e.g. Fleet-managed collectors, SCC constraints, buffering expectations)?

If you run the RedHat distro in the OpenShift cluster and the EDOT Collector on the central ingest / gateway we would provide support for the ingest tier and thereafter.

I hope it helps you and provides the validation you are looking for.