Sytuacja kobiet w IT w 2024 roku
3.02.20205 min
Albert Lewandowski

Albert Lewandowski Big Data DevOps Engineer

Jak wykorzystać logi w monitoringu

Poznaj korzyści, jakie może przynieść przeglądanie logów w monitoringu.

Jak wykorzystać logi w monitoringu

Systemy monitorujące system oraz najważniejsze usługi nie są dla nikogo zaskoczeniem. Obecnie możemy wyróżnić na tym rynku szereg różnych rozwiązań, które oferują podobne funkcje i do podstawowych zastosowań sprawdzają się świetnie. W tym miejscu można też dojść do tematu zbierania logów. W końcu to one pozwalają dokładnie zobaczyć, co dzieje się w usługach, i pozwalają szybko odkryć, skąd pojawił się, np. problem z przetwarzaniem napływających danych. Jak można zapewnić taki system?

Po co w ogóle oglądać logi?

Temat każdego dodatkowego elementu naszej platformy należy zacząć od podstawowego pytania: po co? W tym przypadku chodzi o zapewnienie kompleksowego monitoringu wszystkich istotnych procesów, jakie dzieją się na naszej platformie. W zespole zajmujemy się tematyką Big Data ze szczególnym naciskiem na przetwarzanie danych w czasie rzeczywistym i z racji na to, że mówimy tu o narzędziach, które mają działać nieprzerwanie cały czas, element pozwalający na szybkie sprawdzenie ich stanu jest nieoceniony.

W mojej pracy szczególnie chodzi o wszystkie informacje, jakie są generowane przez usługi do przetwarzania danych, jak Apache Spark czy Apache Flink. Na dobrą sprawę możemy tu dokonać podziału na dwie warstwy. Najpierw na pierwszym miejscu mamy zbieranie tradycyjnych metryk. Chodzi tu o standardowe zbieranie danych na temat ilości przetworzonych danych, przepustowość systemu, działanie samych serwerów oraz monitorowanie procesów systemowych, które zapewniają podstawowe informacje, czy wszystko działa w porządku.

Jeżeli jednak wystąpi problem, warto mieć możliwość szybkiego sprawdzenia tego, co pojawiło się w logach. Weźmy np. pipeline danych działający na Flinku. Pojawia się alert, dostajemy stosowną wiadomość SMS, możemy szybko sprawdzić w narzędziach do wizualizacji metryk i logów, co dokładniej się stało, co wywołało problem i podjąć dalsze działania. Może okazać się, że pojawił się problem z niepoprawnym formatem danych lub procesowi zabrakło zasobów na klastrze.

Przy stosowaniu konwencjonalnych metod, wymagałoby to logów. To również niezwykle ważna rzecz dla osób z działów operacyjnych, którym powinien wystarczyć dostęp do jednego narzędzia i w ten sposób są w stanie szybciej zareagować.

Elastic i przyjaciele

W przypadku zbierania logów z aplikacji wypada zacząć od jednego z najpopularniejszych stacków, czyli ElasticSearch do indeksowania treści, Kibana do ich wizualizacji, Logstash do przesyłania danych oraz Filebeat do czytania logów bezpośrednio na serwerach i wybierania z nich interesującej nas zawartości (jeżeli zdecydujemy się na taki ruch). Oczywiście ten ekosystem jest często uzupełniany przez Fluentbita lub Fluentd zamiast komponentu Elastica.

W wielu projektach jest to chętnie wykorzystywane rozwiązanie. Łatwo jednak dostrzec, że Elastic nieszczególnie chętnie udostępnia wszystkie funkcje w podstawowym darmowym wariancie, decydując się na promowanie swoich płatnych wersji. Do tego dochodzą problemy z Filebeatem, który lubi nie zamykać nieistniejących już plików, o czym na forum istnieje kilka wątków, jednak pomoc techniczna sprytnie odpowiada z użyciem SOA #1.

Dojrzała konkurencja

W przypadku jednego z projektów nie byliśmy usatysfakcjonowani z wydajności oferowanej przez ELK (ElasticSearch, Logstash, Kibana, Filebeat), który wymagałby dalszej rozbudowy. Niestety, pod względem optymalizacji samego pipelinu w ELK osiągnęliśmy wszystko. Dlatego zamiast dalej dokładać serwery, postanowiliśmy przetestować zupełnie inne rozwiązanie, bardziej dopasowane do monitoringu z Prometheusem i Grafaną. Po poszukiwaniach i testach zdecydowaliśmy się postawić na zupełnie nową technologię w postaci Lokiego. Jest ono stworzone pod kątem tailowania wskazanych przez nas plików i z racji na swoje jedno konkretne zastosowanie odpowiednio sobie z tym radzi.

Loki to skalowalne horyzontalnie narzędzie do agregowania logów. Jest ono rozwijane przez Grafana Labs i oczywiście mówimy tu o rozwiązaniu open-source. Jego instalacja pozostaje bardzo prosta. Na docelowy serwer pobieramy binarkę z Lokim, która do działania wymaga oczywiście pliku konfiguracyjnego. Jego format przedstawia się następująco:

auth_enabled: false

server:
http_listen_port: 3100

ingester:
lifecycler:
address: 127.0.0.1
ring:
kvstore:
store: inmemory
replication_factor: 1
final_sleep: 0s
chunk_idle_period: 5m
chunk_retain_period: 30s

schema_config:
configs:
- from: 2018-04-15T00:00:00.000Z
store: boltdb
object_store: filesystem
schema: v9
index:
prefix: index_
period: 168h

storage_config:
boltdb:
directory: /tmp/loki/index
filesystem:
directory: /tmp/loki/chunks

limits_config:
enforce_metric_name: false
reject_old_samples: true
reject_old_samples_max_age: 168h

chunk_store_config:
max_look_back_period: 0

table_manager:
chunk_tables_provisioning:
inactive_read_throughput: 0
inactive_write_throughput: 0
provisioned_read_throughput: 0
provisioned_write_throughput: 0
index_tables_provisioning:
inactive_read_throughput: 0
inactive_write_throughput: 0
provisioned_read_throughput: 0
provisioned_write_throughput: 0
retention_deletes_enabled: false
retention_period: 0


Obecnie Loki wspiera przechowywanie zagregowanych logów lokalnie, może je indeksować z wykorzystaniem Cassandry. Nie brakuje też wsparcia dla usług Google Cloud Storage i BigTable w Google Cloud Platform, a także S3 i DynamoDB w Amazon Web Sevices. Twórcy zapewniają również, że Loki jest kompatybilny z dowolnym storagem kompatybilnym z API S3.

Jako źródło danych w jednym z naszym projektów zdecydowaliśmy się na wykorzystanie Promtaila. Jeżeli mieliście już do czynienia z Prometheusem, jego konfiguracja oraz możliwość tworzenia kolejnych etapów w przetwarzaniu logów (m.in. relabelowanie z użyciem regexa, aby mieć od razu przygotowane interesujące nas dane) nie będzie stanowiła dla Was wielkiego wyzwania. W tym przypadku również potrzebne jest pobranie pliku binarnego oraz załączeniu do konfiguracji. W takim pliku wskazujemy ścieżki do plików z logami. Warto dodać, że Promtail zapisuje do swojego pliku informacje na temat tego, gdzie skończył czytanie plików.

server:
http_listen_port: 9080
grpc_listen_port: 0

positions:
filename: /tmp/positions.yaml

clients:
- url: 'http://localhost:3100/loki/api/v1/push'

scrape_configs:
- job_name: system
static_configs:
- targets:
- localhost
labels:
job: varlogs
__path__: /var/log/*log


Dlaczego jednak Loki i Promtail to interesujące połączenie? Po pierwsze jest ono dedykowane pod zbieranie i agregowanie logów, po drugie idealnie łączy się z Prometheusem, oferując możliwość podglądu wszystkiego w Grafanie, a po trzecie zostało ono stworzone z myślą o monitorowaniu usług w klastrach Kubernetesa. Na plus zaliczyć można również skalowalność rozwiązania oraz jego prostą konfigurację.

Owszem, Kibana jest bardziej efektownym narzędziem do wizualizacji logów, jednak trudno powiedzieć, aby przy czynnościach operacyjnych było to kluczowe. Tym bardziej, że ostatnia odsłona Lokiego z Grafaną umożliwiają tworzenie dashboardów z przeglądaniem logów na żywo.

Samego Promtaila można bez większych problemów zastąpić innym rozwiązaniem z, np. Fluentd. Deweloperzy przygotowali do niego odpowiedni moduł, dzięki czemu możliwe jest łączenie tych komponentów. Z krótkiego porównania wygląda na to, że Fluentbit / Fluentd oferują większe możliwości transformacji logów. Jeżeli potrzebujemy jedynie ograniczoną ilość informacji z logów, wówczas warto postawić jednak na to rozwiązanie.

Równocześnie rozważaliśmy również inne usługi. Obecnie na rynku mamy do czynienia ze sporą liczbą dostępnych rozwiązań i na dobrą sprawę spory wpływ na wybór tego jednego konkretnego ma także pozostała część naszego stacku. Jedną z ciekawszych opcji jest Graylog, który cieszy się sporą popularnością i oferuje analizę tego, co znajduje się wewnątrz logów. Wśród open sourcowych projektów warto też wskazać LOGalyze.

Wszechobecny monitoring, prawdziwe SRE

Monitoring to obowiązkowa rzecz przy dowolnej platformie danych. Pozwala na bieżąco sprawdzać działające procesy i reagować od razu w przypadku wystąpienia jakichkolwiek problemów i nawet zapobiegać poważnym kłopotom, np. utracie danych czy nieprzetworzeniu danych. Dodanie alertów dla występowania zbyt dużej liczby błędów lub ostrzeżeń pozwala skutecznie usprawnić sprawdzanie działania platformy i pozwala wejść na kolejny poziom przeciwdziałania jakimkolwiek dalszym problemom.

<p>Loading...</p>