Loki — zbieranie logów, stosując podejście Prometheus

Cześć, Hubrowicze! W przededniu nowego rekrutacji na kurs „Praktyki i narzędzia DevOps“ przygotowaliśmy dla Was tłumaczenie interesującego materiału.

Ten artykuł to krótkie wprowadzenie do Loki. Projekt Loki jest wspierany przez Grafana i jest skierowany na centralizację zbierania logów (z serwerów lub kontenerów).

Głównym źródłem inspiracji dla Loki była Prometheus idea zastosowania jego podejścia do zarządzania logami:

• użycie etykiet (labels) do przechowywania danych
• małe zużycie zasobów

Jeszcze wrócimy do zasad działania Prometheus oraz przedstawimy kilka przykładów jego użycia w kontekście Kubernetes.

Kilka słów o Prometheus

Aby w pełni zrozumieć, jak działa Loki, ważne jest, aby cofnąć się i przypomnieć sobie o Prometheus.

Jedną z charakterystycznych cech Prometheus jest pobieranie metryk z punktów zbioru (przez eksportery) i ich przechowywanie w TSDB (Time Series Data Base, baza danych czasowych) z dodatkiem metadanych w postaci etykiet.

Po co to wszystko?

Ostatnio Prometheus stał się de facto standardem w świecie kontenerów i Kubernetes: jego instalacja jest bardzo prosta, a w klastrze Kubernetes od początku istnieje punkt końcowy dla Prometheus. Prometheus może również pobierać metryki z aplikacji uruchomionych w kontenerze, zachowując jednocześnie określone etykiety. Dlatego monitorowanie aplikacji jest bardzo proste do zrealizowania.

Niestety, do zarządzania logami wciąż nie ma rozwiązania „pod klucz”, więc musisz znaleźć rozwiązanie dla siebie:

• zarządzana usługa w chmurze do centralizacji logów (AWS, Azure lub Google)
• usługa monitorowania „monitoring jako usługa” (monitoring as a service) (na przykład Datadog)
• stworzenie własnej usługi zbierania logów.

Dla trzeciej opcji tradycyjnie korzystałem z Elasticsearch, mimo że nie zawsze byłem z niego zadowolony (szczególnie jego ciężkością i złożonością konfiguracji).

Loki został zaprojektowany w celu uproszczenia realizacji zgodnie z następującymi zasadami:

• być łatwym do uruchomienia
• zużywać mało zasobów
• działać samodzielnie bez żadnej specjalnej obsługi
• być uzupełnieniem dla Prometheus w celu pomocy w badaniu błędów

Jednak ta prostota osiągana jest kosztem pewnych kompromisów. Jednym z nich jest brak indeksowania treści. Dlatego wyszukiwanie po tekście nie jest zbyt efektywne ani bogate i nie pozwala na prowadzenie statystyk dotyczących treści. Ale ponieważ Loki chce być odpowiednikiem grep i uzupełnieniem Prometheusa, nie jest to wadą.

Śledzenie incydentów

Aby lepiej zrozumieć, dlaczego Loki nie potrzebuje indeksowania, wróćmy do metody śledzenia incydentów, którą stosowali deweloperzy Loki:

1 Alert → 2 Tablica → 3 Zapytanie ad hoc → 4 Agregacja logów → 5 Rozproszona śledzenie → 6 Napraw!
(1 Ostrzeżenie → 2 Tablica → 3 Zapytanie ad hoc → 4 Agregacja logów → 5 Rozproszona śledzenie → 6 Naprawiamy!)

Koncepcja polega na tym, że otrzymujemy jakieś ostrzeżenie (Powiadomienie Slack, SMS itd.) i po tym:

• sprawdzamy tablice Grafana
• sprawdzamy metryki usług (na przykład w Prometheusie)
• sprawdzamy zapisy logów (na przykład w Elasticsearch)
• możliwe, że spojrzymy na rozproszone śledzenie (Jaeger, Zipkin itd.)
• i w końcu naprawiamy pierwotny problem.

Tutaj, w przypadku stosu Grafana + Prometheus + Elasticsearch + Zipkin, będziemy musieli użyć czterech różnych narzędzi. Aby zaoszczędzić czas, dobrze byłoby mieć możliwość wykonania wszystkich tych kroków za pomocą jednego narzędzia: Grafana. Warto zauważyć, że takie podejście do badań zostało wprowadzone w Grafana od wersji 6. W ten sposób możliwe staje się odniesienie do danych Prometheus bezpośrednio z Grafana.

Ekran Eksploratora jest podzielony między Prometheusa a Loki

Na tym ekranie można przeglądać logi w Loki związane z metrykami Prometheus, wykorzystując koncepcję podziału ekranu. Począwszy od wersji 6.5, Grafana pozwala na obsługę identyfikatora śledzenia (trace id) w zapisach logów Loki w celu przechodzenia po linkach do ulubionych narzędzi śledzenia rozproszonego (Jaeger).

Lokalny test Loki

Najlepszym sposobem na lokalne testowanie Loki jest użycie docker-compose. Plik docker-compose znajduje się w repozytorium Loki. Możesz uzyskać repozytorium za pomocą następującego polecenia sshpass:

$ git clone https://github.com/grafana/loki.git

Następnie musisz przejść do katalogu produkcyjnego:

$ cd production

Potem można pobrać najnowsze wersje obrazów Docker:

$ docker-compose pull

Na koniec stack Loki uruchamiany jest następującym poleceniem:

$ docker-compose up

Architektura Loki

Oto mała diagram z architekturą Loki:

Zasady architektury Loki

Klient webowy uruchamia aplikacje na serwerze, Promtail zbiera logi i wysyła je do Loki, klient webowy również przesyła metadane do Loki. Loki wszystko agreguje i przekazuje do Grafany.
Loki jest uruchomiony. Aby wyświetlić dostępne komponenty, wykonaj następujące polecenie:

$ docker ps

W przypadku świeżo zainstalowanego Dockera polecenie powinno zwrócić następujący wynik:

IMAGE               PORTY                  NAZWY
grafana/promtail:                          production_promtail_1
grafana/grafana: m  0.0.0.0:3000->3000/tcp production_grafana_1
grafana/loki: late  80/tcp,0.0.0.0:3100... production_loki_1

Widzimy następujące komponenty:

• Promtail: agent odpowiedzialny za centralizację logów
• Grafana: znane narzędzie do pulpitów nawigacyjnych
• Loki: demon centralizacji danych

W ramach klasycznej infrastruktury (na przykład opartej na maszynach wirtualnych) na każdej maszynie musi być wdrożony agent Promtail. Grafana i Loki mogą być zainstalowane na tej samej maszynie.

Wdrożenie w Kubernetes

Instalacja komponentów Loki w Kubernetes będzie polegać na następujących krokach:

• daemonSet do wdrożenia agenta Promtail na każdej z maszyn w klastrze serwerów
• wdrożenie (Deployment) Loki
• i na koniec — wdrożenie Grafany.

Na szczęście, Loki jest dostępny jako pakiet Helm, co ułatwia jego wdrożenie.

Instalacja przez Helm

Helm powinien być już zainstalowany. Można go pobrać z repozytorium GitHub projektu. Instalacja odbywa się przez rozpakowanie archiwum odpowiadającego twojej architekturze i dodanie helm do $PATH.

Uwaga: Wersja 3.0.0 Helma została ostatnio wydana. Ponieważ w niej było wiele zmian, czytelnikowi zaleca się poczekać trochę przed jej używaniem..

Dodanie źródła do Helma

Pierwszym krokiem będzie dodanie repozytorium „loki” za pomocą następującego polecenia:

$ helm add loki https://grafana.github.io/loki/charts

Po tym można szukać pakietów o nazwie „loki”:

$ helm search loki

Wynik:

loki/loki       0.17.2 v0.4.0 Loki: jak Prometheus, ale dla logów.
loki/loki-stack 0.19.1 v0.4.0 Loki: jak Prometheus, ale dla logów.
loki/fluent-bit 0.0.2  v0.0.1 Używa wtyczki go fluent-bit dla...
loki/promtail   0.13.1 v0.4.0 Odpowiedzialny za zbieranie logów i...

Te pakiety mają następujące funkcje:

• pakiet loki/loki odpowiada tylko serwerowi Loki
• pakiet loki/fluent-bit pozwala na wdrożenie DaemonSet używając fluent-bit do zbierania logów zamiast Promtail
• pakiet loki/promtail zawiera agenta zbierającego logi
• pakiet loki/loki-stack, pozwala na jednoczesne wdrożenie Loki wraz z Promtail.

Instalacja Loki

Aby wdrożyć Loki w Kubernetes, wykonaj następujące polecenie w przestrzeni nazw „monitoring”:

$ helm upgrade --install loki loki/loki-stack --namespace monitoring

Aby zapisać na dysku, dodaj parametr --set loki.persistence.enabled = true:

$ helm upgrade --install loki loki/loki-stack 
              --namespace monitoring 
              --set loki.persistence.enabled=true

Uwaga: jeśli chcesz uruchomić Grafana jednocześnie, dodaj parametr --set grafana.enabled = true

Uruchamiając to polecenie, powinieneś uzyskać następujący wynik:

OSTATNIO WDROŻONE: Wt 19 lis 2019 15:56:54
PRZESTRZEŃ NAZWOWA: monitorowanie
STAN: WDROŻONY
ZASOBY:
==> v1/ClusterRole
NAZWA WIEK
loki-promtail-clusterrole 189d
…
NOTATKI:
Stos Loki został wdrożony w twoim klastrze. Loki może być teraz dodany jako źródło danych w Grafanie.
Zobacz <a href="http://docs.grafana.org/features/datasources/loki/">http://docs.grafana.org/features/datasources/loki/</a> więcej szczegółów.

Sprawdzając stan podów w przestrzeni nazw „monitoring”, zobaczymy, że wszystko jest uruchomione:

$ kubectl -n monitoring get pods -l release=loki

Wynik:

NAZWA                GOTOWY  STATUS   RESTARTY  WIEK
loki-0               1/1    Działa  0         147m
loki-promtail-9zjvc  1/1    Działa  0         3h25m
loki-promtail-f6brf  1/1    Działa  0         11h
loki-promtail-hdcj7  1/1    Działa  0         3h23m
loki-promtail-jbqhc  1/1    Działa  0         11h
loki-promtail-mj642  1/1    Działa  0         62m
loki-promtail-nm64g  1/1    Działa  0         24m

Wszystkie pody są uruchomione. Teraz nadszedł czas, aby wykonać kilka testów!

Podłączenie do Grafana

Aby połączyć się z Grafana w Kubernetes, musisz otworzyć tunel do jego podu. Poniżej znajduje się polecenie do otwarcia portu 3000 dla podu Grafana:

$ kubectl -n port-forward monitoring svc/loki-grafana 3000:80

Kolejnym ważnym punktem jest konieczność przywrócenia hasła administratora Grafana. Hasło przechowywane jest w sekrecie loki-grafana w polu .data.admin-user w formacie base64.

Aby je przywrócić, konieczne jest wykonanie następującego polecenia:

$ kubectl -n monitoring get secret loki-grafana 
 --template '{{index .data "admin-password" | base64decode}}'; echo

Użyj tego hasła wraz z domyślnym kontem administratora (admin).

Definiowanie źródła danych Loki w Grafana

Najpierw upewnij się, że utworzone zostało źródło danych Loki (Konfiguracja / Źródło danych).
Oto przykład:

Przykład konfiguracji źródła danych dla Loki

Klikając „Test”, możesz sprawdzić połączenie z Loki.

Wykonujemy zapytania do Loki

Teraz przejdź do Grafana do sekcji „Eksploruj”. Podczas odbierania logów z kontenerów Loki dodaje metadane z Kubernetes. Umożliwia to przeglądanie logów określonego kontenera.

Na przykład, aby wybierać logi kontenera promtail, możesz użyć następującego zapytania: {container_name = "promtail"}.
Pamiętaj również, aby wybrać źródło danych Loki.

To zapytanie zwróci aktywność kontenerów w następujący sposób:

Wynik zapytania w Grafana

Dodawanie do pulpitu nawigacyjnego

Zaczynając od Grafana 6.4, można umieścić informacje o logach bezpośrednio na pulpicie nawigacyjnym. Umożliwia to użytkownikowi szybkie przełączanie się pomiędzy ilością zapytań na jego stronie a śladami aplikacji.

Poniżej znajduje się przykład pulpitu nawigacyjnego, wdrażającego tę interakcję:

Przykład kokpitu z metrykami Prometheus i logami Loki

Przyszłość Loki

Zacząłem używać Loki jeszcze w maju / czerwcu, zaczynając od wersji 0.1. Dziś wydano już wersję 1, a nawet 1.1 i 1.2.

Trzeba przyznać, że wersja 0.1 była niewystarczająco stabilna. Jednak 0.3 już pokazała prawdziwe oznaki dojrzałości, a kolejne wersje (0.4, a następnie 1.0) tylko wzmocniły to wrażenie.

Po wersji 1.0.0 nikt nie ma już usprawiedliwienia, aby nie korzystać z tego wspaniałego narzędzia.

Dalsze ulepszenia powinny dotyczyć nie samego Loki, ale raczej jego integracji z doskonałą Grafaną. W rzeczywistości w Grafanie 6.4 już zaczęła istnieć dobra integracja z kokpitami.

Grafana 6.5, która została wydana niedawno, jeszcze bardziej poprawia tę integrację, automatycznie rozpoznając zawartość logów w formacie JSON.

Poniżej wideo przedstawiające mały przykład tego mechanizmu:

Wykorzystanie ciągów Loki wyświetlanych w Grafanie

Można użyć jednego z pól JSON, na przykład do:

• linkowania do zewnętrznego narzędzia
• filtrowania zawartości logów

Na przykład możesz kliknąć na traceId, aby przejść do Zipkin lub Jaeger.

Tradycyjnie czekamy na Wasze komentarze i zapraszamy na otwarty webinar, gdzie porozmawiamy o tym, jak rozwijał się przemysł DevOps w 2019 roku i omówimy możliwe kierunki rozwoju na rok 2020.

Źródło: habr.com