🥇Logowanie w Kubernetes: EFK kontra PLG

Monitorowanie stało się bardzo ważnym elementem rozwijających się rozwiązań chmurowych w miarę wzrostu złożoności systemów rozproszonych. Jest niezbędne do zrozumienia ich zachowania. Potrzebne są skalowalne narzędzia, które będą w stanie zbierać dane z wszystkich usług — i zapewnić specjalistom jedyny interfejs z analizą wydajności, prezentacją błędów, dostępnością i logami.

Te same narzędzia powinny być efektywne i wydajne. W tym artykule omówimy dwa popularne zestawy technologii: EFK (Elasticsearch) i PLG (Loki) oraz przeanalizujemy ich architektury i różnice.

Zestaw EFK

Być może słyszałeś o bardzo popularnym ELK lub EFK. Zestaw składa się z kilku oddzielnych części: Elasticsearch (obiektowe magazynowanie), Logstash lub FluentD (zbieranie i agregacja logów) oraz Kibana do wizualizacji.

Typowy schemat działania wygląda tak:

Elasticsearch — rozproszone obiektowe magazynowanie z wyszukiwaniem i analizą w czasie rzeczywistym. Doskonałe rozwiązanie dla częściowo złożonych danych, takich jak logi. Informacje są przechowywane w postaci dokumentów JSON, indeksowane w czasie rzeczywistym i rozdzielane po węzłach klastra. Używany jest indeks odwrócony, który zawiera wszystkie unikalne słowa i powiązane z nimi dokumenty do wyszukiwania pełnotekstowego, które z kolei opiera się na silniku wyszukiwania Apache Lucene.

FluentD — to zbieracz danych, który wykonuje unifikację danych podczas ich zbierania i konsumowania. Stara się uporządkować dane w JSON, w miarę możliwości. Jego architektura jest rozszerzalna, istnieje więcej niż setek różnych rozszerzeń, wspieranych przez społeczność, na wszelkie okazje.

Kibana — narzędzie wizualizacji danych dla Elasticsearch z różnymi dodatkowymi możliwościami, takimi jak analiza szeregów czasowych, grafami, uczeniem maszynowym i innymi.

Architektura Elasticsearch

Dane klastra Elasticsearch są przechowywane rozproszone na wszystkich jego węzłach. Klastr składa się z kilku węzłów w celu zwiększenia dostępności i odporności. Każdy węzeł może pełnić wszystkie role klastra, ale w dużych, skalowalnych wdrożeniach węzłom zazwyczaj przypisywane są oddzielne zadania.

Typy węzłów klastra:

master node — zarządza klastrem, potrzebne są minimum trzy, z czego jeden jest zawsze aktywny;
data node — przechowuje zindeksowane dane i wykonuje różne zadania z nimi związane;
węzeł ingest — organizuje konwertery do przetwarzania danych przed indeksowaniem;
węzeł koordynujący — routowanie zapytań, redukcja fazy przetwarzania wyszukiwania, koordynacja masowej indeksacji;
węzeł alertujący — uruchomienie zadań powiadamiania;
węzeł uczenia maszynowego — przetwarzanie zadań uczenia maszynowego.

Na poniższym diagramie pokazano, jak dane są przechowywane i replikowane między węzłami w celu uzyskania wyższej dostępności danych.

Dane każdej repliki są przechowywane w indeksie odwróconym, poniższy schemat pokazuje, jak to działa:

Instalacja

Szczegóły można zobaczyć tutaj, będę korzystać z helm chart:

$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elastics

Stos PLG

Nie należy się dziwić, jeśli nie możesz znaleźć tego akronimu, ponieważ bardziej znany jest jako Grafana Loki. W każdym razie ten stos zyskuje na popularności, ponieważ wykorzystuje przemyślane rozwiązania techniczne. Mógł już słyszeć o Grafanie, popularnym narzędziu do wizualizacji. Jej twórcy, inspirowani Prometheusem, stworzyli Loki, poziomo skalowalny system agregacji logów o wysokiej wydajności. Loki indeksuje tylko metadane, ale nie same logi, co pozwoliło mu być prostym w obsłudze i ekonomicznie opłacalnym.

Promtail — agent do wysyłania logów z systemu operacyjnego do klastra Loki. Grafana — narzędzie do wizualizacji oparte na danych z Loki.

Loki zbudowano na tych samych zasadach, co Prometheus, dlatego dobrze nadaje się do przechowywania i analizy logów Kubernetes.

Architektura Loki

Loki można uruchomić zarówno w trybie pojedynczego procesu, jak i w kilku procesach, co zapewnia poziome skalowanie.

Może również działać zarówno jako monolityczna aplikacja, jak i jako mikroserwis. Uruchomienie w trybie pojedynczego procesu może być przydatne do lokalnego rozwoju lub małego monitorowania. Dla wdrożenia przemysłowego i obciążenia skalowalnego zaleca się zastosowanie wariantu mikroserwisowego. Ścieżki zapisu i odczytu danych są oddzielone, co pozwala dostosować i skalować go adekwatnie do potrzeb.

Zobaczmy architekturę systemu zbierania logów bez szczegółów:

A tu — opis (architektura mikroserwisowa):

Składniki:

Promtail — agent instalowany na węzłach (w postaci zestawu usług), zbiera logi z zadań i korzysta z API Kubernetes, aby uzyskać metadane, którymi będą oznaczane logi. Następnie wysyła log do głównej usługi Loki. Dla dopasowania metadanych stosowane są te same zasady etykietowania, co w Prometheus.

Dystrybutor — usługa dystrybucji działająca jako bufor. Aby przetwarzać miliony wpisów, pakuje przychodzące dane, kompresując je w blokach podczas ich przyjmowania. Równocześnie działa kilka odbiorników danych, ale logi należące do jednego strumienia danych muszą znaleźć się tylko w jednym z nich dla wszystkich jego bloków. To jest zorganizowane w postaci pierścienia odbiorników i sekwencyjnego haszowania. Dla odporności na awarie i redundancji odbywa się to n razy (3, jeśli nie jest konfigurowane).

Ingester — usługa odbiorcza. Bloki danych przychodzą skompresowane z dodanymi logami. Gdy blok osiąga wystarczający rozmiar, jest zrzucany do bazy danych. Metadane trafiają do indeksu, a dane z bloku z logiem przechodzą do Chunks (zwykle jest to magazyn obiektowy). Po zrzucie odbiorca tworzy nowy blok, do którego będą dodawane nowe wpisy.

Index — baza danych, DynamoDB, Cassandra, Google BigTable i inne.

Chunks — bloki logów w skompresowanej formie, zazwyczaj przechowywane w magazynie obiektowym, takim jak S3.

Querier — ścieżka odczytu, wykonująca całą czarną robotę. Sprawdza zakres czasowy i etykiety, a następnie przeszukuje indeks w celu znalezienia dopasowań. Następnie odczytuje bloki danych i filtruje je, aby uzyskać wyniki.

A teraz przyjrzyjmy się wszystkiemu w akcji.

Instalacja

Najłatwiejszym sposobem na zainstalowanie w Kubernetes jest skorzystanie z helm. Zakładamy, że już go zainstalowałeś i skonfigurowałeś (i trzeciej wersji! przyp. tłumacza)

Dodajemy repozytorium i instalujemy stos.

$ helm repo add loki https://grafana.github.io/loki/charts
$ helm repo update
$ helm upgrade --install loki loki/loki-stack --set grafana.enabled=true,prometheus.enabled=true,prometheus.alertmanager.persistentVolume.enabled=false,prometheus.server.persistentVolume.enabled=false

Poniżej znajduje się przykład pulpitu, na którym pokazano dane z Prometheus dla metryk Etcd i Loki dla logów podów Etcd.

A teraz porozmawiajmy o architekturze obu systemów i porównajmy ich możliwości.

Porównanie

Język zapytań

W Elasticsearch używany jest Query DSL oraz język zapytań Lucene, które umożliwiają pełnotekstowe wyszukiwanie. To ustalony, potężny silnik wyszukiwania z szeroką obsługą operatorów. Dzięki niemu można wyszukiwać w kontekście i sortować według istotności.

Po drugiej stronie ringu znajduje się LogQL, stosowany w Loki, następcy PromQL (języka zapytań Prometheusa). Wykorzystuje on etykiety logów do filtrowania i selekcji danych logów. Możliwe jest użycie niektórych operatorów oraz arytmetyki, jak opisano tutaj, ale pod względem możliwości ustępuje językowi Elastic.

Ponieważ zapytania w Loki są związane z etykietami — łatwo je powiązać z metrykami, co ułatwia organizację monitoringu operacyjnego.

Skalowalność

Oba stosy są horyzontalnie skalowalne, ale w przypadku Loki jest to prostsze, ponieważ ma on oddzielne ścieżki do odczytu i zapisu danych oraz architekturę mikroserwisową. Loki może być dostosowany do Twoich potrzeb i może być używany do bardzo dużych zbiorów danych logów.

Multi-tenancy

Multi-tenancy klastra to powszechny temat w redukcji OPEX, oba stosy zapewniają multi-tenancy. Dla Elasticsearch jest kilka sposobów oddzielania klientów: oddzielny indeks dla każdego klienta, routowanie na podstawie klienta, unikalne pola klienta, filtry wyszukiwania. W Loki jest to wsparcie w postaci nagłówka HTTP X-Scope-OrgID.

Koszt

Loki jest bardzo efektywny ekonomicznie, ponieważ nie indeksuje danych, a jedynie metadanych. W ten sposób osiąga się oszczędności na przechowywaniu i pamięci (cache), ponieważ przechowywanie obiektów jest tańsze niż blokowe, które stosowane jest w klastrach Elasticsearch.

Podsumowanie

Stos EFK może być wykorzystywany do różnych celów, zapewniając maksymalną elastyczność i wielofunkcyjny interfejs Kibana do analizy, wizualizacji i zapytań. Może być dodatkowo wzbogacony możliwościami uczenia maszynowego.

Stos Loki jest przydatny w ekosystemie Kubernetes ze względu na mechanizm wykrywania metadanych. Łatwo można powiązać dane do monitorowania opartego na szeregach czasowych w Grafanie i logach.

Kiedy mowa o kosztach i długoterminowym przechowywaniu logów, Loki jest świetnym wyborem do wprowadzenia do rozwiązań chmurowych.

Na rynku jest wiele alternatyw — niektóre z nich mogą być lepsze dla Ciebie. Na przykład, GKE ma integrację z Stackdriver, co zapewnia doskonałe rozwiązanie do monitorowania. Nie uwzględniliśmy ich w naszej analizie w tym artykule.

Linki:

Artykuł został przetłumaczony i przygotowany dla Habr przez pracowników centrum szkoleniowego Slurm — intensywne kursy, wideo oraz szkolenia korporacyjne prowadzone przez praktyków (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)

Źródło: habr.com