EDOT Collector in Elastic 9.2: Windows logs, tail sampling

Elastic Distributions of OpenTelemetry (EDOT) are Elastic’s own distributions of the OpenTelemetry standard: a collector and SDKs for Java, .NET, Node.js, PHP and Python, plus mobile applications on iOS and Android. They are GA. Elastic announced this in April 2025, together with the Observability 9.0 and 8.18 releases. Elastic 9.2, released on 23 October, gave the collector several components that change how it can be used: a Windows Event Log receiver, a tail sampling processor and a Kubernetes events receiver. Below we describe what this gives an administrator of a mixed environment that is not all Linux containers, and what to watch.

Where the collector lives and how to run it

The EDOT collector ships with Elastic Agent, and Elastic Agent can work in one of two modes described in the documentation. In Agent mode it collects data from the host and from applications instrumented with the SDKs and passes it to Elastic or to a collector in Gateway mode. In Gateway mode it acts as a central point: it receives data from many agents, processes it and sends it on. The documentation points to Gateway mode where you need shared processing rules for the whole organisation, filtering of data before it crosses the network, or fewer connections to the backend. In Kubernetes the typical layout is an agent on every node (a DaemonSet), one agent collecting cluster metrics and a Gateway that receives everything.

For a self-managed Elastic cluster the EDOT documentation additionally assumes a Gateway that runs the elasticapm processor and connector: they enrich and aggregate trace data in the way the APM interface in Kibana expects. Elastic Cloud, in turn, has a managed OTLP endpoint to which the SDKs can send data without a collector of your own.

Windows Event Log

Before 9.2 there was no Windows event log receiver among the Elastic Agent components, and the component table in the documentation gives 9.2.0 as the version in which it appeared. The windowseventlog receiver comes from the OpenTelemetry contrib repository. The release comes with a sample Windows configuration covering logs, metrics and application data. The simplest set of receivers looks like this:

receivers:
  windowseventlog/application:
    channel: application
  windowseventlog/system:
    channel: system
  windowseventlog/security:
    channel: security
    start_at: end

A few notes from the receiver’s documentation. The channel field is required and one receiver reads one channel, which is why the example has three. By default, on first start the receiver reads from the end (start_at: end), so you will not see old events unless you set beginning. If you configure the storage extension, the receiver remembers where it stopped across restarts; without it, it does so in memory only. The Security channel can also be very noisy, so narrow it with an XML query (query) instead of sending everything.

When does this make sense? If you build observability on OpenTelemetry and want one agent to collect metrics, traces and logs from Windows servers, the receiver closes a gap. If the goal is SIEM rather than observability, the approach with Elastic Agent integrations managed from Fleet is often still simpler: they store data in the ECS schema, ready for detection rules (we wrote about this in our article on SIEM on Elastic Security). The choice depends on which standard is your primary one.

Tail sampling: keep the traces that matter

With heavy traffic, storing every trace is expensive. The tail_sampling processor, added in Elastic Agent 9.2, decides after the whole trace has been collected, so it can keep every trace with errors or slow ones and only a share of the rest:

processors:
  tail_sampling:
    decision_wait: 30s
    policies:
      - name: errors
        type: status_code
        status_code: { status_codes: [ERROR] }
      - name: slow-requests
        type: latency
        latency: { threshold_ms: 1500 }
      - name: the-rest
        type: probabilistic
        probabilistic: { sampling_percentage: 5 }

Several things matter when designing this. According to the processor’s documentation, all spans of one trace must reach the same collector instance, otherwise decisions will be wrong. That is why the processor usually sits in the Gateway layer, and when there are several instances you must route spans by trace ID. The processor holds spans in memory until it decides (30 seconds by default) and limits the number of traces kept in memory (50,000 by default), so size the collector with headroom and watch its memory use. The processor must also come after processors that rely on context, such as k8sattributes, because it reassembles spans into new batches and loses the original context.

The drawback of this method is that after sampling you see only part of the traffic. Alerts and counters built on traces alone need to be adjusted, for example by basing availability indicators on metrics rather than on the number of retained traces.

Other changes in the collector

The release notes for Elastic Agent 9.2 also list a Kubernetes events receiver (k8seventsreceiver), a profiling receiver, an extension that sets headers, and inclusion of the collector’s internal telemetry in agent monitoring. In the component table of the documentation the Apache receiver also appears as added in 9.2. Elastic also says in the 9.2 announcement that a new OTLP endpoint for metrics raises ingest throughput by up to 60 percent, in Elastic Cloud and in self-managed installations.

What to watch when updating configuration

If you have your own collector configuration files, go through the Elastic Agent release notes. In 9.1 the deprecated *_dynamic_index settings of the Elasticsearch exporter were removed, and the resource/k8s processor was replaced with the standard k8sattributes, which handles service attributes natively. The same change appears again in the 9.2 notes for kube-stack configurations. It is also worth knowing that since 9.1 Elastic Agent has an upgrade rollback window (agent.upgrade.rollback.window, 168 hours by default) in which the previous version can be restored. That helps when you upgrade agents across a whole fleet.

How to start

Pick one Windows server and one application that today lack good observability. Run the agent on them with the sample configuration from the documentation, add the windowseventlog receiver and look at the data in Kibana. Add tail sampling only when traces begin to cost too much. We described the general principles of using OpenTelemetry in OpenTelemetry alongside Elastic and Grafana, and the Grafana collector in our article on Grafana Alloy.

We deploy collectors and choose their operating modes as part of application monitoring.