🥇Zbieranie kłód od Lokiego

W Badoo na bieżąco monitorujemy nowe technologie i oceniamy, czy warto je zastosować w naszym systemie. Chcielibyśmy podzielić się jednym z tych badań ze społecznością. Dedykowany jest Lokiemu, systemowi agregacji logów.

Loki to rozwiązanie do przechowywania i przeglądania logów, a stos ten zapewnia także elastyczny system ich analizy i przesyłania danych do Prometheusa. W maju ukazała się kolejna aktualizacja, którą twórcy aktywnie promują. Interesowało nas, co potrafi Loki, jakie daje możliwości i w jakim stopniu może stanowić alternatywę dla ELK, stosu, którego obecnie używamy.

Co to jest Loki

Grafana Loki to zestaw komponentów tworzących kompletny system do pracy z kłodami. W odróżnieniu od innych podobnych systemów, Loki opiera się na idei indeksowania wyłącznie metadanych logów – etykiet (takich samych jak w Prometheusie) i kompresowaniu samych logów w osobne fragmenty.

Strona główna, GitHub

Zanim przejdziemy do tego, co możesz zrobić z Lokim, chcę wyjaśnić, co rozumiemy przez „ideę indeksowania wyłącznie metadanych”. Porównajmy podejście Lokiego i podejście do indeksowania w tradycyjnych rozwiązaniach takich jak Elasticsearch, na przykładzie linii z logu nginx:

172.19.0.4 - - [01/Jun/2020:12:05:03 +0000] "GET /purchase?user_id=75146478&amp;item_id=34234 HTTP/1.1" 500 8102 "-" "Stub_Bot/3.0" "0.001"

Tradycyjne systemy analizują cały wiersz, w tym pola z dużą liczbą unikalnych wartości user_id i item_id, i przechowują wszystko w dużych indeksach. Zaletą tego podejścia jest to, że można szybko uruchamiać złożone zapytania, ponieważ prawie wszystkie dane znajdują się w indeksie. Ma to jednak swoją cenę, ponieważ indeks staje się duży, co przekłada się na wymagania dotyczące pamięci. W rezultacie indeks dziennika pełnotekstowego jest porównywalny pod względem rozmiaru z samymi dziennikami. Aby szybko je przeszukać należy załadować indeks do pamięci. Im więcej dzienników, tym szybciej rośnie indeks i więcej zużywa pamięci.

Podejście Lokiego wymaga, aby z ciągu znaków, którego liczba wartości jest niewielka, wyodrębnione zostały tylko niezbędne dane. W ten sposób otrzymujemy mały indeks i możemy przeszukiwać dane, filtrując je według czasu i indeksowanych pól, a następnie skanując resztę za pomocą wyrażeń regularnych lub wyszukiwania podciągów. Proces nie wydaje się najszybszy, ale Loki dzieli żądanie na kilka części i wykonuje je równolegle, przetwarzając dużą ilość danych w krótkim czasie. Można konfigurować liczbę fragmentów i równoległych żądań w nich zawartych; zatem ilość danych, które można przetworzyć w jednostce czasu, zależy liniowo od ilości dostarczonych zasobów.

Ten kompromis między dużym, szybkim indeksem a małym, równoległym indeksem brutalnej siły pozwala Lokiemu kontrolować koszt systemu. Można go elastycznie konfigurować i rozbudowywać w zależności od potrzeb.

Stos Lokiego składa się z trzech komponentów: Promtail, Loki, Grafana. Promtail zbiera logi, przetwarza je i wysyła do Lokiego. Loki ich trzyma. Grafana może zażądać danych od Lokiego i wyświetlić je. Ogólnie rzecz biorąc, Lokiego można używać nie tylko do przechowywania dzienników i ich przeszukiwania. Cały stos daje ogromne możliwości przetwarzania i analizowania przychodzących danych metodą Prometheusa.
Można znaleźć opis procesu instalacji tutaj.

Wyszukiwanie dziennika

Logi możesz przeszukiwać w specjalnym interfejsie Grafany – Explorer. Zapytania wykorzystują język LogQL, który jest bardzo podobny do PromQL używanego w Prometheusie. W zasadzie można go traktować jako rozproszony grep.

Interfejs wyszukiwania wygląda następująco:

Samo żądanie składa się z dwóch części: selektora i filtra. Selektor to wyszukiwanie przy użyciu indeksowanych metadanych (etykiet) przypisanych do logów, a filter to ciąg wyszukiwania lub wyrażenie regularne, które odfiltrowuje rekordy zdefiniowane przez selektor. W podanym przykładzie: W nawiasach klamrowych znajduje się selektor, wszystko po nim jest filtrem.

{image_name="nginx.promtail.test"} |= "index"

Ze względu na sposób działania Lokiego nie można tworzyć zapytań bez selektora, ale etykiety można tworzyć tak ogólne, jak chcesz.

Selektor to para klucz-wartość ujęta w nawiasy klamrowe. Możesz łączyć selektory i określać różne warunki wyszukiwania za pomocą operatorów =, != lub wyrażeń regularnych:

{instance=~"kafka-[23]",name!="kafka-dev"} 
// Найдёт логи с лейблом instance, имеющие значение kafka-2, kafka-3, и исключит dev

Filtr to tekst lub wyrażenie regularne, które odfiltruje wszystkie dane otrzymane przez selektor.

Istnieje możliwość uzyskania wykresów ad-hoc na podstawie otrzymanych danych w trybie metrycznym. Możesz na przykład dowiedzieć się, jak często w logach nginx pojawia się wpis zawierający indeks ciągu:

Pełny opis możliwości można znaleźć w dokumentacji LogQL.

Analiza dziennika

Istnieje kilka sposobów gromadzenia dzienników:

Korzystanie z Promtail, standardowego komponentu stosu do zbierania logów.
Bezpośrednio z kontenera dokowanego za pomocą Sterownik logowania Loki Docker.
Użyj Fluentd lub Fluent Bit, które mogą wysyłać dane do Lokiego. W przeciwieństwie do Promtail mają gotowe parsery dla prawie każdego typu dziennika i mogą również obsługiwać logi wielowierszowe.

Zwykle do analizowania używany jest Promtail. Robi trzy rzeczy:

Znajduje źródła danych.
Przykleja do nich etykiety.
Wysyła dane do Lokiego.

Obecnie Promtail może czytać logi z plików lokalnych i dziennika systemowego. Musi być zainstalowany na każdej maszynie, z której zbierane są logi.

Następuje integracja z Kubernetes: Promtail automatycznie, poprzez Kubernetes REST API, rozpoznaje stan klastra i zbiera logi z węzła, usługi lub podu, natychmiastowo zamieszczając etykiety na podstawie metadanych z Kubernetesa (nazwa podu, nazwa pliku itp.) .

Możesz także wieszać etykiety na podstawie danych z dziennika za pomocą Pipeline. Pipeline Promtail może składać się z czterech rodzajów etapów. Więcej szczegółów w oficjalna dokumentacja, od razu zauważę pewne niuanse.

Etapy analizowania. To jest etap RegEx i JSON. Na tym etapie wyodrębniamy dane z logów do tzw. wyodrębnionej mapy. Możemy wyodrębnić dane z JSON, po prostu kopiując potrzebne nam pola do wyodrębnionej mapy lub za pomocą wyrażeń regularnych (RegEx), w których nazwane grupy są „odwzorowywane” na wyodrębnioną mapę. Wyodrębniona mapa to magazyn klucz-wartość, gdzie klucz to nazwa pola, a wartość to jego wartość z dzienników.
Etapy transformacji. Etap ten posiada dwie opcje: transform, w której ustalamy reguły transformacji oraz source - źródło danych do transformacji z wyodrębnionej mapy. Jeśli na wyodrębnionej mapie nie ma takiego pola, zostanie ono utworzone. W ten sposób możliwe jest tworzenie etykiet, które nie są oparte na wyodrębnionej mapie. Na tym etapie możemy manipulować danymi na wyodrębnionej mapie za pomocą dość potężnego narzędzia Szablon Golanga. Dodatkowo musimy pamiętać, że wyodrębniona mapa podczas parsowania ładuje się w całości, co pozwala np. sprawdzić znajdującą się w niej wartość: „{{if .tag}wartość tagu istnieje{end}}”. Szablon obsługuje warunki, pętle i niektóre funkcje ciągów, takie jak Zamień i Przytnij.
Etapy działania. W tym momencie możesz coś zrobić z wyodrębnioną zawartością:
- Utwórz etykietę z wyodrębnionych danych, które zostaną zaindeksowane przez Lokiego.
- Zmień lub ustaw czas zdarzenia z dziennika.
- Zmień dane (tekst dziennika), które trafią do Lokiego.
- Utwórz metryki.
Etapy filtrowania. Etap dopasowania, w którym możemy albo wysłać niepotrzebne nam wpisy do /dev/null, albo przekazać je do dalszego przetwarzania.

Na przykładzie przetwarzania zwykłych logów nginx pokażę, jak można analizować logi za pomocą Promtail.

Do testu weźmy jako nginx-proxy zmodyfikowany obraz nginx jwilder/nginx-proxy:alpine i małego demona, który może zadać sobie pytanie poprzez HTTP. Demon ma kilka punktów końcowych, do których może dostarczać odpowiedzi o różnej wielkości, z różnymi statusami HTTP i różnymi opóźnieniami.

Będziemy zbierać logi z kontenerów dokowanych, które można znaleźć wzdłuż ścieżki /var/lib/docker/containers/ / -json.log

W docker-compose.yml konfigurujemy Promtail i podajemy ścieżkę do konfiguracji:

promtail:
  image: grafana/promtail:1.4.1
 // ...
 volumes:
   - /var/lib/docker/containers:/var/lib/docker/containers:ro
   - promtail-data:/var/lib/promtail/positions
   - ${PWD}/promtail/docker.yml:/etc/promtail/promtail.yml
 command:
   - '-config.file=/etc/promtail/promtail.yml'
 // ...

Dodaj ścieżkę do logów do promtail.yml (w konfiguracji jest opcja „docker”, która robi to samo w jednej linijce, ale nie byłoby to takie jasne):

scrape_configs:
 - job_name: containers

   static_configs:
       labels:
         job: containerlogs
         __path__: /var/lib/docker/containers/*/*log  # for linux only

Gdy ta konfiguracja jest włączona, logi ze wszystkich kontenerów będą wysyłane do Lokiego. Aby tego uniknąć zmieniamy ustawienia testowego nginxa w pliku docker-compose.yml - dodajemy pole tagu logującego:

proxy:
 image: nginx.test.v3
//…
 logging:
   driver: "json-file"
   options:
     tag: "{{.ImageName}}|{{.Name}}"

Edycja pliku promtail.yml i konfiguracja Pipeline. Dane wejściowe obejmują logi następującego typu:

{"log":"u001b[0;33;1mnginx.1    | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] "GET /api/index HTTP/1.1" 200 0 "-" "Stub_Bot/0.1" "0.096"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.66740443Z"}
{"log":"u001b[0;33;1mnginx.1    | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] "GET /200 HTTP/1.1" 200 0 "-" "Stub_Bot/0.1" "0.000"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.702925272Z"}

Etap rurociągu:

 - json:
     expressions:
       stream: stream
       attrs: attrs
       tag: attrs.tag

Wyodrębniamy pola stream, attrs, attrs.tag (jeśli istnieją) z przychodzącego JSON-a i umieszczamy je w wyodrębnionej mapie.

 - regex:
     expression: ^(?P<image_name>([^|]+))|(?P<container_name>([^|]+))$
     source: "tag"

Jeśli udało nam się umieścić pole tagu w wyodrębnionej mapie, to za pomocą wyrażenia regularnego wyodrębniamy nazwy obrazu i kontenera.

 - labels:
     image_name:
     container_name:

Przypisujemy etykiety. Jeżeli w wyodrębnionych danych zostaną znalezione klucze nazwa_obrazu i nazwa_kontenera, to ich wartości zostaną przypisane do odpowiednich etykiet.

 - match:
     selector: '{job="docker",container_name="",image_name=""}'
     action: drop

Odrzucamy wszystkie dzienniki, które nie mają zainstalowanych etykiet nazwa_obrazu i nazwa_kontenera.

  - match:
     selector: '{image_name="nginx.promtail.test"}'
     stages:
       - json:
           expressions:
             row: log

W przypadku wszystkich dzienników, których nazwa_obrazu to nginx.promtail.test, wyodrębnij pole dziennika z dziennika źródłowego i umieść je na wyodrębnionej mapie za pomocą klucza wiersza.

  - regex:
         # suppress forego colors
         expression: .+nginx.+|.+[0m(?P<virtual_host>[a-z_.-]+) +(?P<nginxlog>.+)
         source: logrow

Czyścimy linię wejściową za pomocą wyrażeń regularnych i wyciągamy wirtualny host nginx oraz linię dziennika nginx.

     - regex:
         source: nginxlog
         expression: ^(?P<ip>[w.]+) - (?P<user>[^ ]*) [(?P<timestamp>[^ ]+).*] "(?P<method>[^ ]*) (?P<request_url>[^ ]*) (?P<request_http_protocol>[^ ]*)" (?P<status>[d]+) (?P<bytes_out>[d]+) "(?P<http_referer>[^"]*)" "(?P<user_agent>[^"]*)"( "(?P<response_time>[d.]+)")?

Przeanalizuj dziennik nginx przy użyciu wyrażeń regularnych.

    - regex:
           source: request_url
           expression: ^.+.(?P<static_type>jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|pdf|txt|tar|wav|bmp|rtf|js|flv|swf|html|htm)$
     - regex:
           source: request_url
           expression: ^/photo/(?P<photo>[^/?.]+).*$
       - regex:
           source: request_url
           expression: ^/api/(?P<api_request>[^/?.]+).*$

Przeanalizujmy request_url. Za pomocą wyrażenia regularnego określamy cel żądania: do danych statycznych, do zdjęć, do API i ustawiamy odpowiedni klucz w wyodrębnionej mapie.

       - template:
           source: request_type
           template: "{{if .photo}}photo{{else if .static_type}}static{{else if .api_request}}api{{else}}other{{end}}"

Korzystając z operatorów warunkowych w Template, sprawdzamy zainstalowane pola w wyodrębnionej mapie i ustawiamy wymagane wartości dla pola request_type: photo, static, API. Przypisz inny, jeśli się nie powiedzie. request_type zawiera teraz typ żądania.

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

Ustawiamy etykiety api_request, virtual_host, request_type i status (status HTTP) w oparciu o to, co udało nam się umieścić w wyodrębnionej mapie.

       - output:
           source: nginx_log_row

Zmień wyjście. Teraz oczyszczony dziennik Nginx z wyodrębnionej mapy trafia do Lokiego.

Po uruchomieniu powyższej konfiguracji możesz zobaczyć, że każdemu wpisowi przypisano etykiety na podstawie danych z dziennika.

Należy pamiętać, że pobieranie etykiet z dużą liczbą wartości (liczność) może znacznie spowolnić Lokiego. Oznacza to, że nie powinieneś umieszczać w indeksie na przykład user_id. Więcej na ten temat przeczytasz w artykule „W jaki sposób etykiety w Lokim mogą przyspieszyć i ułatwić wykonywanie zapytań w dziennikach" Ale to nie znaczy, że nie możesz wyszukiwać według user_id bez indeksów. Podczas wyszukiwania należy zastosować filtry („przechwycić” dane), a indeks pełni tutaj rolę identyfikatora strumienia.

Wizualizacja logów

Loki może działać jako źródło danych dla wykresów Grafana przy użyciu LogQL. Obsługiwane są następujące funkcje:

szybkość — liczba rekordów na sekundę;
count over time — liczba rekordów w określonym zakresie.

Istnieją również funkcje agregujące Sum, Avg i inne. Można zbudować dość złożone wykresy, np. wykres ilości błędów HTTP:

Standardowe źródło danych Loki ma nieco zmniejszoną funkcjonalność w porównaniu ze źródłem danych Prometheus (na przykład nie można zmienić legendy), ale Loki można podłączyć jako źródło typu Prometheus. Nie jestem pewien, czy jest to udokumentowane zachowanie, ale sądząc po odpowiedzi programistów „Jak skonfigurować Lokiego jako źródło danych Prometheusa? · Wydanie #1222 · grafana/loki”, na przykład, jest całkowicie legalne, a Loki jest w pełni kompatybilny z PromQL.

Dodaj Lokiego jako źródło danych z typem Prometheus i dodaj adres URL /loki:

I możemy tworzyć wykresy, jakbyśmy pracowali z metrykami z Prometeusza:

Myślę, że rozbieżność w funkcjonalności jest tymczasowa i programiści poprawią to w przyszłości.

Metryka

Loki umożliwia wyodrębnianie danych liczbowych z dzienników i wysyłanie ich do firmy Prometheus. Na przykład dziennik nginx zawiera liczbę bajtów na odpowiedź, a także, z pewną modyfikacją standardowego formatu dziennika, czas w sekundach potrzebny na odpowiedź. Dane te można wyodrębnić i przesłać do firmy Prometheus.

Dodaj kolejną sekcję do promtail.yml:

- match:
   selector: '{request_type="api"}'
   stages:
     - metrics:
         http_nginx_response_time:
           type: Histogram
           description: "response time ms"
           source: response_time
           config:
             buckets: [0.010,0.050,0.100,0.200,0.500,1.0]
- match:
   selector: '{request_type=~"static|photo"}'
   stages:
     - metrics:
         http_nginx_response_bytes_sum:
           type: Counter
           description: "response bytes sum"
           source: bytes_out
           config:
             action: add
         http_nginx_response_bytes_count:
           type: Counter
           description: "response bytes count"
           source: bytes_out
           config:
             action: inc

Opcja umożliwia definiowanie i aktualizację metryk w oparciu o dane z wyodrębnionej mapy. Te metryki nie są wysyłane do Lokiego - pojawiają się w punkcie końcowym Promtail /metrics. Prometheus musi być skonfigurowany do odbioru danych otrzymanych na tym etapie. W powyższym przykładzie dla request_type=„api” zbieramy metrykę histogramu. W przypadku tego typu metryk wygodnie jest uzyskać percentyle. W przypadku statyki i zdjęcia zbieramy sumę bajtów i liczbę wierszy, w których otrzymaliśmy bajty, aby obliczyć średnią.

Przeczytaj więcej o metrykach tutaj.

Otwórz port na Promtail:

promtail:
     image: grafana/promtail:1.4.1
     container_name: monitoring.promtail
     expose:
       - 9080
     ports:
       - "9080:9080"

Upewnij się, że pojawiają się metryki z przedrostkiem promtail_custom:

Ustawianie Prometeusza. Dodaj ogłoszenie o pracę:

- job_name: 'promtail'
 scrape_interval: 10s
 static_configs:
   - targets: ['promtail:9080']

I rysujemy wykres:

W ten sposób możesz poznać na przykład cztery najwolniejsze zapytania. Można także skonfigurować monitorowanie tych metryk.

skalowanie

Loki może działać w trybie pojedynczego pliku binarnego lub w trybie fragmentacji (tryb skalowalny w poziomie). W drugim przypadku może zapisać dane w chmurze, a porcje i indeks są przechowywane osobno. Wersja 1.5 wprowadza możliwość przechowywania w jednym miejscu, jednak nie jest jeszcze zalecane wykorzystywanie jej na produkcji.

Kawałki można przechowywać w pamięci kompatybilnej z S3, a do przechowywania indeksów można używać skalowalnych poziomo baz danych: Cassandra, BigTable lub DynamoDB. Inne części Lokiego – Dystrybutorzy (do zapisu) i Querier (do zapytań) – są bezstanowe i również skalowane poziomo.

Na konferencji DevOpsDays Vancouver 2019 jeden z uczestników Callum Styan ogłosił, że w przypadku Lokiego jego projekt zawiera petabajty logów o indeksie mniejszym niż 1% całkowitego rozmiaru: „Jak Loki koreluje dane i dzienniki — i oszczędza pieniądze".

Porównanie Lokiego i ELK-a

Rozmiar indeksu

Aby przetestować wynikowy rozmiar indeksu, pobrałem logi z kontenera nginx, dla którego skonfigurowano powyższy potok. Plik dziennika zawierał 406 624 wierszy o łącznej objętości 109 MB. Dzienniki generowano w ciągu godziny, około 100 wpisów na sekundę.

Przykład dwóch linii z logu:

Po indeksowaniu przez ELK dało to rozmiar indeksu 30,3 MB:

W przypadku Lokiego dało to około 128 KB indeksu i około 3,8 MB danych w fragmentach. Warto zaznaczyć, że dziennik został wygenerowany sztucznie i nie zawierał dużej różnorodności danych. Prosty gzip na oryginalnym logu Dockera JSON z danymi dał kompresję na poziomie 95,4%, a biorąc pod uwagę fakt, że do samego Lokiego przesłano jedynie oczyszczony log nginx, kompresja do 4 MB jest zrozumiała. Całkowita liczba unikalnych wartości dla etykiet Lokiego wyniosła 35, co wyjaśnia niewielki rozmiar indeksu. W przypadku ELK dziennik również został wyczyszczony. Zatem Loki skompresował oryginalne dane o 96%, a ELK o 70%.

Zużycie pamięci

Jeśli porównamy cały stos Prometeusza i ELK, to Loki „je” kilka razy mniej. Oczywiste jest, że usługa Go zużywa mniej niż usługa Java, a porównanie rozmiaru sterty JVM Elasticsearch i przydzielonej pamięci dla Lokiego jest błędne, niemniej jednak warto zauważyć, że Loki zużywa znacznie mniej pamięci. Przewaga procesora nie jest tak oczywista, ale jest również obecna.

prędkość

Loki szybciej „pożera” logi. Szybkość zależy od wielu czynników - jakiego rodzaju są logi, jak bardzo jesteśmy wyrafinowani w ich analizowaniu, sieci, dysku itp. - ale jest zdecydowanie wyższa niż ELK (w moim teście - około dwa razy większa). Wyjaśnia to fakt, że Loki umieszcza w indeksie znacznie mniej danych i w związku z tym spędza mniej czasu na indeksowaniu. W przypadku szybkości wyszukiwania sytuacja jest odwrotna: Loki zauważalnie zwalnia na danych większych niż kilka gigabajtów, natomiast prędkość wyszukiwania ELK nie zależy od rozmiaru danych.

Wyszukiwanie dziennika

Loki znacznie ustępuje ELK pod względem możliwości wyszukiwania logów. Grep z wyrażeniami regularnymi jest potężny, ale ustępuje dojrzałej bazie danych. Brak zapytań zakresowych, agregacja wyłącznie według etykiet, brak możliwości wyszukiwania bez etykiet – to wszystko ogranicza nas w poszukiwaniu informacji interesujących Lokiego. Nie oznacza to, że za pomocą Lokiego nic nie można znaleźć, ale określa przebieg pracy z logami, gdy po raz pierwszy znajdziesz problem na wykresach Prometheusa, a następnie użyjesz tych etykiet, aby sprawdzić, co wydarzyło się w logach.

Interfejs

Przede wszystkim jest piękny (przepraszam, nie mogłem się powstrzymać). Grafana ma ładnie wyglądający interfejs, ale Kibana jest znacznie bardziej bogata w funkcje.

Plusy i minusy Lokiego

Jedną z zalet jest to, że Loki integruje się z Prometheusem, dzięki czemu otrzymujemy metryki i alerty od razu po wyjęciu z pudełka. Jest wygodny do zbierania logów i przechowywania ich z Kubernetes Pods, ponieważ ma funkcję wykrywania usług odziedziczoną z Prometheusa i automatycznie dołącza etykiety.

Minusem jest słaba dokumentacja. Niektóre rzeczy, na przykład funkcje i możliwości Promtail, odkryłem dopiero w trakcie studiowania kodu, na szczęście jest to oprogramowanie typu open source. Kolejną wadą są słabe możliwości analizowania. Na przykład Loki nie może analizować dzienników wielowierszowych. Kolejną wadą jest to, że Loki jest stosunkowo młodą technologią (wersja 1.0 ukazała się w listopadzie 2019).

wniosek

Loki to w 100% interesująca technologia, która nadaje się do małych i średnich projektów, pozwalając na rozwiązanie wielu problemów związanych z agregacją logów, wyszukiwaniem logów, monitorowaniem i analizą logów.

Nie używamy Lokiego na Badoo, ponieważ mamy stos ELK, który nam odpowiada i który przez lata został zarośnięty różnymi niestandardowymi rozwiązaniami. Dla nas przeszkodą jest przeszukiwanie kłód. Przy prawie 100 GB logów dziennie ważne jest dla nas, abyśmy mogli znaleźć wszystko i trochę więcej i zrobić to szybko. Do tworzenia wykresów i monitorowania wykorzystujemy inne rozwiązania, które są dostosowane do naszych potrzeb i zintegrowane ze sobą. Stos Lokiego ma wymierne korzyści, ale nie da nam więcej niż już mamy, a jego korzyści na pewno nie przewyższą kosztów migracji.

I chociaż po badaniach okazało się, że nie możemy używać Lokiego, mamy nadzieję, że ten post pomoże Ci w wyborze.

Znajduje się repozytorium z kodem użytym w artykule tutaj.

Źródło: www.habr.com

Zbieranie dzienników od Lokiego