Grafana Alloy 1.9: co zmienia się w kolektorze telemetrii

Grafana Alloy to otwarty kolektor telemetrii: jedno narzędzie zbiera metryki, logi, ślady i profile, przetwarza je i wysyła do wybranych backendów. Grafana Labs opisuje go jako dystrybucję OpenTelemetry Collector z wbudowanymi potokami Prometheus. W tekście wyjaśniamy, do czego Alloy służy i jak zastępuje Grafana Agent, a potem omawiamy wersję 1.9, na podstawie oficjalnego dziennika zmian (changelog) projektu. Wersja zawiera kilka zmian niezgodnych wstecz, więc warto przeczytać ją przed aktualizacją.

Do czego służy Alloy

Alloy działa jako agent na hoście, w kontenerze albo w klastrze Kubernetes. Konfigurację pisze się w jego własnej składni jako zestaw komponentów, z których każdy robi jedną rzecz: odbiera dane, przekształca je albo wysyła dalej. Komponenty łączy się w potok, a ten działa w sposób ciągły. Dzięki temu jeden proces może na przykład:

• zbierać metryki z hosta i z aplikacji (wbudowane eksportery Prometheus, w tym dla baz danych i Windows);
• odbierać dane OTLP z aplikacji zinstrumentowanych przez OpenTelemetry;
• czytać pliki logów, kontenery i wpisy dziennika systemowego i wysyłać je do Loki;
• wysyłać dane do Grafana Cloud, własnego stosu Grafany albo innych backendów zgodnych z OTLP i Prometheus.

To przydatne, gdy chcesz zachować otwarte standardy. Alloy może być kolektorem w architekturze opisanej w tekście OpenTelemetry obok Elastic i Grafany, a dzięki komponentom OTLP wysyła dane także do Elastic.

Alloy a Grafana Agent

Alloy jest następcą Grafana Agent. Grafana Labs wycofuje Agenta i udostępnia narzędzia migracji: polecenie alloy convert zamienia konfigurację Agenta (w trybie statycznym i Flow), a także konfigurację Prometheus i OpenTelemetry Collector, na konfigurację Alloy. Przed przełączeniem produkcji sprawdź wynik konwersji i uruchom oba kolektory obok siebie na jednym hoście testowym, bo część opcji Agenta nie ma bezpośredniego odpowiednika. Przy większych środowiskach migrację warto rozłożyć na etapy.

Wersja 1.9: zmiany niezgodne wstecz

Alloy wydaje nowe wersje według stałego harmonogramu (mniej więcej co sześć tygodni), a 1.9 jest kolejną wersją z tej serii. Najważniejsze zmiany, które mogą wymagać poprawek w konfiguracji:

• prometheus.exporter.oracledb korzysta teraz z oficjalnego eksportera utrzymywanego przez Oracle, a nie ze wcześniejszego, społecznościowego. W efekcie trzy metryki nie są już domyślnie włączone. Jeśli masz na nich dashboardy lub alerty, trzeba je włączyć przez własny plik metryk.
• prometheus.exporter.windows przeszedł na nowszą wersję eksportera z większą przebudową. Kolektory msmq i service nie obsługują już warunków where w WMI, a kilka kolektorów połączono lub usunięto.
• beyla.ebpf (komponent eksperymentalny): argument enable_context_propagation zastąpiono argumentem context_propagation, który pozwala sterować propagacją dokładniej.

Zmiana przy Oracle i Windows dotyka metryk, więc po aktualizacji porównaj liczbę serii metryk i sprawdź, czy alerty nadal mają dane.

Wersja 1.9: nowe możliwości

Według dziennika zmian wersja 1.9 dodaje między innymi:

• komponent otelcol.storage.file, czyli rozszerzenie do trwałych kolejek i stanu na dysku, dzięki któremu dane nie giną przy restarcie;
• komponent otelcol.receiver.splunkhec, odbierający dane w formacie Splunk HEC (przydatny przy migracji ze Splunk);
• społecznościowy komponent otelcol.exporter.googlecloud;
• uwierzytelnianie podstawowe (Basic) dla serwera HTTP Alloy;
• polecenie validate, które w ograniczonym zakresie sprawdza poprawność konfiguracji bez uruchamiania Alloy;
• wsparcie dla modułów urządzeń Cisco w prometheus.exporter.snmp oraz federacji grup reguł Mimir w mimir.rules.kubernetes;
• aktualizację komponentów OpenTelemetry z wersji 0.122.0 do 0.125.0.

Po wydaniu 1.9.0 projekt publikuje wydania poprawkowe 1.9.x. Przy aktualizacji bierz najnowsze z nich, a nie pierwsze.

Przykład potoku OTLP w Alloy

Poniżej szkic, który odbiera dane OTLP, grupuje je w paczki i wysyła do backendu OTLP. Adres i token są przykładowe.

otelcol.receiver.otlp "default" {
  grpc {}
  http {}

  output {
    metrics = [otelcol.processor.batch.default.input]
    logs    = [otelcol.processor.batch.default.input]
    traces  = [otelcol.processor.batch.default.input]
  }
}

otelcol.processor.batch "default" {
  output {
    metrics = [otelcol.exporter.otlp.backend.input]
    logs    = [otelcol.exporter.otlp.backend.input]
    traces  = [otelcol.exporter.otlp.backend.input]
  }
}

otelcol.auth.bearer "backend" {
  token = sys.env("OTLP_TOKEN")
}

otelcol.exporter.otlp "backend" {
  client {
    endpoint = "otlp.example.com:443"
    auth     = otelcol.auth.bearer.backend.handler
  }
}

Jak aktualizować bezpiecznie

1. Przeczytaj sekcję zmian łamiących zgodność dla każdej wersji, którą pomijasz.
2. Zrób kopię konfiguracji i sprawdź ją poleceniem validate oraz na hoście testowym.
3. Zaktualizuj najpierw jeden węzeł i obserwuj przez dobę metryki własne Alloy oraz ciągłość danych na dashboardach.
4. Dopiero potem aktualizuj pozostałe agenty. W dużych środowiskach robimy to etapami.

Wybór kolektora, wdrożenie Alloy i połączenie go z Elastic albo Grafaną realizujemy w ramach monitoringu infrastruktury.