EDOT Collector w Elastic 9.2: logi Windows i tail sampling

Elastic Distributions of OpenTelemetry (EDOT), czyli własne dystrybucje standardu OpenTelemetry (kolektor i pakiety SDK dla Javy, .NET, Node.js, PHP, Pythona oraz aplikacji mobilnych na iOS i Androida), mają status GA. Elastic ogłosił to w kwietniu 2025 roku, razem z wydaniami Observability 9.0 i 8.18. W Elastic 9.2 z 23 października kolektor dostał kilka składników, które zmieniają jego zastosowanie: odbiornik logów Windows Event Log, procesor tail sampling i odbiornik zdarzeń Kubernetes. Poniżej opisujemy, co to daje administratorowi środowiska mieszanego, który nie ma samych kontenerów w Linuksie, i na co trzeba uważać.

Gdzie jest kolektor i jak go uruchamiać

Kolektor EDOT jest dostarczany razem z Elastic Agent, a Elastic Agent może pracować w jednym z dwóch trybów, opisanych w dokumentacji. W trybie Agent zbiera dane z hosta i z aplikacji instrumentowanych przez SDK i przekazuje je do Elastic albo do kolektora w trybie Gateway. W trybie Gateway pełni rolę centralnego punktu: przyjmuje dane od wielu agentów, przetwarza je i wysyła dalej. Dokumentacja wskazuje tryb Gateway tam, gdzie potrzebne są wspólne reguły przetwarzania dla całej organizacji, filtrowanie danych przed wysłaniem przez sieć albo ograniczenie liczby połączeń do backendu. W Kubernetes typowy układ to agent na każdym węźle (DaemonSet), jeden agent zbierający metryki klastra i Gateway, do którego trafia wszystko.

Dla klastra Elastic zarządzanego samodzielnie dokumentacja EDOT zakłada dodatkowo Gateway, w którym działają procesor i konektor elasticapm: dzięki nim dane o śladach są wzbogacane i agregowane tak, jak oczekuje tego interfejs APM w Kibanie. Z kolei Elastic Cloud ma zarządzany punkt końcowy OTLP, do którego pakiety SDK mogą wysyłać dane bez własnego kolektora.

Logi Windows Event Log

Przed 9.2 w składnikach Elastic Agent nie było odbiornika logów zdarzeń Windows, a tabela składników w dokumentacji podaje wersję 9.2.0 jako tę, w której się pojawił. Odbiornik windowseventlog pochodzi z repozytorium contrib OpenTelemetry. Do wydania dołączono przykładową konfigurację dla Windows z logami, metrykami i danymi aplikacji. Najprostszy zestaw odbiorników wygląda tak:

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

Kilka uwag z dokumentacji odbiornika. Pole channel jest wymagane, a jeden odbiornik czyta jeden kanał, dlatego w przykładzie jest ich trzy. Domyślnie przy pierwszym uruchomieniu odbiornik czyta od końca (start_at: end), więc starych zdarzeń nie zobaczysz, chyba że ustawisz beginning. Jeśli skonfigurujesz rozszerzenie storage, odbiornik zapamięta, gdzie skończył po restarcie, a bez niego robi to tylko w pamięci. Poza tym kanał Security bywa bardzo głośny, więc zawęź go zapytaniem XML (query) zamiast wysyłać wszystko.

Kiedy to ma sens? Jeśli budujesz obserwowalność na OpenTelemetry i chcesz jednym agentem zbierać metryki, ślady i logi z serwerów Windows, odbiornik zamyka lukę. Jeśli natomiast celem jest SIEM, a nie obserwowalność, nadal prostsze bywa podejście z integracjami Elastic Agent zarządzanymi z Fleet, które zapisują dane w schemacie ECS pod gotowe reguły wykrywania (pisaliśmy o tym w tekście o SIEM na Elastic Security). Wybór zależy od tego, który standard jest dla Ciebie podstawowy.

Tail sampling: zostawiaj ślady, które mają znaczenie

Przy dużym ruchu przechowywanie wszystkich śladów kosztuje. Procesor tail_sampling, dodany w Elastic Agent 9.2, podejmuje decyzję po zebraniu całego śladu, a więc może zachować wszystkie ślady z błędami albo wolne, a z reszty tylko część:

processors:
  tail_sampling:
    decision_wait: 30s
    policies:
      - name: bledy
        type: status_code
        status_code: { status_codes: [ERROR] }
      - name: wolne-zapytania
        type: latency
        latency: { threshold_ms: 1500 }
      - name: reszta
        type: probabilistic
        probabilistic: { sampling_percentage: 5 }

Kilka rzeczy trzeba uwzględnić przy projektowaniu. Według dokumentacji procesora wszystkie spany jednego śladu muszą trafić do tej samej instancji kolektora, inaczej decyzje będą błędne. Dlatego procesor umieszcza się zwykle w warstwie Gateway, a gdy instancji jest kilka, trzeba zapewnić kierowanie spanów według identyfikatora śladu. Procesor trzyma spany w pamięci do czasu decyzji (domyślnie 30 sekund) i ma limit liczby śladów w pamięci (domyślnie 50 000), więc wymiaruj kolektor z zapasem i obserwuj jego zużycie pamięci. Procesor musi też stać w potoku po procesorach, które korzystają z kontekstu, takich jak k8sattributes, bo składa spany w nowe partie i traci kontekst oryginalny.

Wadą tej metody jest to, że po próbkowaniu widzisz tylko część ruchu. Alerty i liczniki zbudowane na samych śladach trzeba na to dostosować, na przykład opierając wskaźniki dostępności na metrykach, a nie na liczbie zachowanych śladów.

Pozostałe zmiany w kolektorze

Notatki do Elastic Agent 9.2 wymieniają jeszcze odbiornik zdarzeń Kubernetes (k8seventsreceiver), odbiornik profilowania, rozszerzenie ustawiające nagłówki oraz włączenie wewnętrznej telemetrii kolektora do monitoringu agenta. W tabeli składników dokumentacji jako dodany w 9.2 figuruje też odbiornik Apache. Elastic podaje ponadto w ogłoszeniu 9.2, że nowy punkt końcowy OTLP dla metryk zwiększa przepustowość zapisu nawet o 60 procent, w Elastic Cloud i w instalacjach samodzielnych.

Na co uważać przy aktualizacji konfiguracji

Jeśli masz własne pliki konfiguracyjne kolektora, przejrzyj notatki do wydania Elastic Agent. W 9.1 usunięto przestarzałe ustawienia *_dynamic_index eksportera Elasticsearch, a procesor resource/k8s zastąpiono standardowym k8sattributes, który obsługuje atrybuty usług natywnie. Zmiana ta powtarza się w notatkach do 9.2 dla konfiguracji kube-stack. Warto też wiedzieć, że od 9.1 Elastic Agent ma okno wycofania aktualizacji (agent.upgrade.rollback.window, domyślnie 168 godzin), w którym można przywrócić poprzednią wersję. To przydatne, gdy aktualizujesz agentów w całej flocie.

Jak zacząć

Wybierz jeden serwer Windows i jedną aplikację, które dziś nie mają dobrej obserwowalności. Uruchom na nich agenta z przykładową konfiguracją z dokumentacji, dodaj odbiornik windowseventlog i obejrzyj dane w Kibanie. Tail sampling dodawaj dopiero wtedy, gdy ślady zaczną kosztować. Ogólne zasady stosowania OpenTelemetry opisaliśmy w tekście OpenTelemetry obok Elastic i Grafany, a kolektor Grafany w tekście o Grafana Alloy.

Kolektory wdrażamy i dobieramy do nich tryby pracy w ramach monitoringu aplikacji.