Monitorowanie stało się bardzo ważnym elementem rozwijających się rozwiązań chmurowych wraz ze wzrostem złożoności systemów rozproszonych. Konieczne jest zrozumienie ich zachowania. Potrzebujemy skalowalnych narzędzi, które będą w stanie zbierać dane ze wszystkich usług i zapewnić specjalistom jeden interfejs z analizą wydajności, demonstracją błędów, dostępnością i logami.
Te same narzędzia muszą być wydajne i produktywne. W tym artykule przyjrzymy się dwóm popularnym stosom technologii: EFK (Elasticsearch) i PLG (Loki) oraz zbadamy ich architekturę i różnice.
Stos EFK
Być może słyszałeś już o bardzo popularnym ELK lub EFK. Stos składa się z kilku odrębnych części: Elasticsearch (przechowywanie obiektów), Logstash lub FluentD (gromadzenie i agregacja logów) oraz Kibana do wizualizacji.
Typowy przepływ pracy wygląda następująco:
Elasticsearch — rozproszone przechowywanie obiektów z wyszukiwaniem i analizą w czasie rzeczywistym. Doskonałe rozwiązanie dla danych częściowo ustrukturyzowanych, takich jak logi. Informacje są zapisywane w postaci dokumentów JSON, indeksowane w czasie rzeczywistym i rozpowszechniane pomiędzy węzłami klastra. Stosowany jest indeks odwrócony, zawierający wszystkie unikalne słowa i powiązane z nimi dokumenty do wyszukiwania pełnotekstowego, które z kolei opiera się na wyszukiwarce Apache Lucene.
PłynnyD to moduł gromadzący dane, który ujednolica dane podczas ich gromadzenia i wykorzystywania. Stara się jak najbardziej uporządkować dane w formacie JSON. Jego architektura jest rozszerzalna, jest ich więcej , wspierane przez społeczność, na każdą okazję.
Kibana - narzędzie do wizualizacji danych dla Elasticsearch z różnymi dodatkowymi możliwościami, na przykład analizą szeregów czasowych, analizą wykresów, uczeniem maszynowym i nie tylko.
Architektura Elasticsearch
Dane klastra Elasticsearch są przechowywane we wszystkich jego węzłach. Klaster składa się z wielu węzłów w celu poprawy dostępności i odporności. Każdy węzeł może pełnić wszystkie role klastra, ale w przypadku wdrożeń o dużej skali w poziomie węzłom zwykle przypisuje się indywidualne zadania.
Typy węzłów klastra:
- węzeł główny - zarządza klastrem, potrzebne są co najmniej trzy, jeden jest zawsze aktywny;
- węzeł danych - przechowuje zaindeksowane dane i wykonuje z nimi różne zadania;
- węzeł pozyskiwania - organizuje potoki transformacji danych przed indeksowaniem;
- węzeł koordynujący - routing żądań, skrócenie fazy przetwarzania wyszukiwania, koordynacja masowego indeksowania;
- węzeł alarmujący — uruchamianie zadań alarmowych;
- węzeł uczenia maszynowego - przetwarzanie zadań uczenia maszynowego.
Poniższy diagram pokazuje, w jaki sposób dane są przechowywane i replikowane pomiędzy węzłami w celu osiągnięcia większej dostępności danych.
Dane każdej repliki przechowywane są w odwróconym indeksie, poniższy diagram pokazuje, jak to się dzieje:
Instalacja
Szczegóły można zobaczyć , użyję wykresu steru:
$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elasticsStos PLG
Nie zdziw się, jeśli nie możesz znaleźć tego akronimu, ponieważ jest on lepiej znany jako Grafana Loki. W każdym razie stos ten zyskuje na popularności, ponieważ wykorzystuje sprawdzone rozwiązania techniczne. Być może słyszałeś już o Grafanie, popularnym narzędziu do wizualizacji. Jego twórcy, zainspirowani Prometeuszem, opracowali Loki, skalowalny poziomo, wysokowydajny system agregacji logów. Loki indeksuje tylko metadane, a nie same czasopisma, co jest rozwiązaniem technicznym, które sprawia, że jest ono łatwe w użyciu i opłacalne.
Promtail - agent wysyłający logi z systemu operacyjnego do klastra Loki. grafana to narzędzie do wizualizacji oparte na danych z Lokiego.
Loki jest zbudowany na tych samych zasadach co Prometheus, dzięki czemu doskonale nadaje się do przechowywania i analizowania logów Kubernetesa.
Architektura Lokiego
Loki może być uruchamiany jako pojedynczy proces lub jako wiele procesów, co pozwala na skalowanie poziome.
Może również działać jako aplikacja monolityczna lub jako mikrousługa. Prowadzenie jako pojedynczego procesu może być przydatne dla rozwoju lokalnego lub do drobnego monitorowania. W przypadku wdrożeń przemysłowych i skalowalnego obciążenia zaleca się skorzystanie z opcji mikroserwisu. Ścieżki zapisu i odczytu danych są oddzielone, dzięki czemu można je precyzyjnie dostrajać i skalować w zależności od potrzeb.
Przyjrzyjmy się architekturze systemu gromadzenia logów bez wchodzenia w szczegóły:
A oto opis (architektura mikroserwisów):
Składniki:
Promtail — agent instalowany na węzłach (jako zestaw usług), usuwa logi z zadań i uzyskuje dostęp do Kubernetes API w celu uzyskania metadanych, które będą oznaczać logi. Następnie wysyła dziennik do głównej usługi Loki. Mapowanie metadanych obsługuje te same zasady tagowania, co Prometheus.
Dystrybutor — dystrybutor usług pełniący funkcję bufora. Aby przetworzyć miliony rekordów, pakuje przychodzące dane i kompresuje je w blokach po nadejściu. Jednocześnie działa kilka źródeł danych, ale logi należące do jednego przychodzącego strumienia danych powinny pojawiać się tylko w jednym z nich i we wszystkich jego blokach. Jest to zorganizowane w pierścień ujścia i sekwencyjne mieszanie. W celu zapewnienia odporności na błędy i redundancji jest to wykonywane n razy (3, jeśli nie jest skonfigurowane).
Połykacz — odbiorca usługi. Bloki danych są dostarczane skompresowane z dodanymi dziennikami. Gdy blok osiągnie wystarczający rozmiar, jest on przesyłany do bazy danych. Metadane trafiają do indeksu, a dane z bloku dziennika trafiają do fragmentów (zwykle magazynu obiektowego). Po resecie odbiornik tworzy nowy blok, w którym będą dodawane nowe wpisy.
wskaźnik - baza danych, DynamoDB, Cassandra, Google BigTable itp.
Kawałki — bloki dziennika w formie skompresowanej, zwykle przechowywane w pamięci obiektowej, na przykład S3.
Pytający - ścieżka czytania, która wykonuje całą brudną robotę. Sprawdza zakres czasu i znacznik czasu, a następnie przegląda indeks w celu znalezienia dopasowań. Następnie odczytuje bloki danych i filtruje je, aby uzyskać wynik.
Zobaczmy teraz wszystko w akcji.
Instalacja
Najłatwiejszym sposobem instalacji w Kubernetesie jest użycie hełmu. Zakładamy, że już go zainstalowałeś i skonfigurowałeś ( około. tłumacz)
Dodaj repozytorium i zainstaluj 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=falsePoniżej znajduje się przykładowy pulpit pokazujący dane z metryk Prometheus for Etcd i dzienniki podów Loki for Etcd.
Omówmy teraz architekturę obu systemów, a także porównajmy ze sobą ich możliwości.
Porównanie
Język zapytań
Elasticsearch wykorzystuje język zapytań Query DSL i Lucene, aby zapewnić możliwości wyszukiwania pełnotekstowego. Jest to sprawdzona, wydajna wyszukiwarka z szerokim wsparciem operatorów. Dzięki niemu możesz wyszukiwać według kontekstu i sortować według trafności.
Po drugiej stronie pierścienia znajduje się LogQL, używany w Lokim, następcy PromQL (języka zapytań Prometheus). Wykorzystuje znaczniki dziennika do filtrowania i wybierania danych dziennika. Możliwe jest użycie niektórych operatorów i arytmetyki zgodnie z opisem , ale pod względem możliwości pozostaje w tyle za językiem Elastic.
Ponieważ zapytania w Lokim są powiązane ze znacznikami, można je łatwo skorelować z metrykami, co w efekcie ułatwia organizację monitorowania operacyjnego.
Skalowalność
Obydwa stosy są skalowalne w poziomie, ale Loki ułatwia to, ponieważ ma oddzielne ścieżki odczytu i zapisu oraz architekturę mikrousług. Loki można dostosować do własnych potrzeb i można go używać do bardzo dużych ilości danych dziennika.
Wielodostępność
Wielodostępność klastrów jest częstym tematem skrótu OPEX, oba stosy zapewniają wielodostępność. Jest ich kilka dla Elasticsearch separacja klientów: oddzielny indeks dla każdego klienta, routing oparty na kliencie, unikalne pola klienta, filtry wyszukiwania. Loki ma w postaci nagłówka HTTP X-Scope-OrgID.
Kosztować
Loki jest dość oszczędny ze względu na fakt, że nie indeksuje danych, a jedynie metadane. To osiąga i pamięć (pamięć podręczna), ponieważ pamięć obiektowa jest tańsza niż pamięć blokowa używana w klastrach Elasticsearch.
wniosek
Stos EFK może być używany do różnych celów, zapewniając maksymalną elastyczność i bogaty w funkcje interfejs Kibana do analiz, wizualizacji i zapytań. Można go dodatkowo ulepszyć dzięki możliwościom uczenia maszynowego.
Stos Loki jest przydatny w ekosystemie Kubernetes ze względu na mechanizm odkrywania metadanych. Możesz łatwo korelować dane do monitorowania na podstawie szeregów czasowych w Grafanie i logach.
Jeśli chodzi o koszty i długoterminowe przechowywanie logów, Loki jest doskonałym punktem wyjścia do rozwiązań chmurowych.
Na rynku jest więcej alternatyw – niektóre mogą być dla Ciebie lepsze. Na przykład GKE ma integrację Stackdriver, która 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 — kursy intensywne, kursy wideo i szkolenia korporacyjne prowadzone przez praktykujących specjalistów (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)
Źródło: www.habr.com