Czym różni się agregacja metryk od agregacji logów? Czy logi nie mogą zawierać metryk? Czy systemy agregacji logów nie mogą robić tych samych rzeczy co systemy agregacji metryk?

To są pytania, które często słyszę. Widziałem również sprzedawców, którzy reklamowali swój system agregacji logów jako rozwiązanie wszystkich problemów związanych z obserwowalnością. Agregacja logów jest wartościowym narzędziem, ale zazwyczaj nie jest dobrym narzędziem dla danych szeregów czasowych.

Kilka wartościowych cech w systemie agregacji metryk szeregów czasowych to regularny interwał i system przechowywania dostosowany specjalnie do danych szeregów czasowych. Regularny interwał pozwala użytkownikowi na konsekwentne uzyskiwanie rzeczywistych wyników matematycznych. Jeśli system agregacji logów zbiera metryki w regularnym interwale, może potencjalnie działać w ten sam sposób. Jednakże, system przechowywania danych nie jest zoptymalizowany dla typów zapytań, które są typowe dla systemu agregacji metryk. Zapytania te będą wymagały więcej zasobów i czasu do przetworzenia przy użyciu systemów pamięci masowej, które można znaleźć w narzędziach agregacji logów.

Wiemy więc, że system agregacji logów prawdopodobnie nie jest odpowiedni dla danych szeregów czasowych, ale do czego jest dobry? System agregacji dzienników jest doskonałym miejscem do zbierania danych o zdarzeniach. Są to nieregularne działania, które są znaczące. Przykładem mogą być logi dostępu do serwisu internetowego. Są one istotne, ponieważ chcemy wiedzieć, co i kiedy uzyskuje dostęp do naszych systemów. Innym przykładem może być stan błędu aplikacji – ponieważ nie jest to normalny stan operacyjny, może być cenny podczas rozwiązywania problemów.

Garść reguł dotyczących logowania:

• DO include a timestamp
• DO format in JSON
• DON’T log insignificnificant events
• DO log all application errors
• MAYBE log warnings
• DO turn on logging
• DO write messages in a human-czytelnej dla człowieka formie
• NIE loguj danych informacyjnych w produkcji
• NIE loguj niczego, czego człowiek nie może przeczytać lub na co nie może zareagować

Koszty chmury

Podczas badania narzędzi do agregacji logów, chmura może wydawać się atrakcyjną opcją. Jednak może się to wiązać z poważnymi kosztami. Logi reprezentują dużą ilość danych, gdy są agregowane przez setki lub tysiące hostów i aplikacji. Pobieranie, przechowywanie i pobieranie tych danych jest kosztowne w systemach opartych na chmurze.

Jako punkt odniesienia dla rzeczywistego systemu, zbiór około 500 węzłów z kilkuset aplikacjami daje 200 GB danych dziennika. Prawdopodobnie jest miejsce na poprawę w tym systemie, ale nawet zmniejszenie go o połowę będzie kosztować prawie 10 000 dolarów miesięcznie w wielu ofertach SaaS. Często obejmuje to retencję danych tylko przez 30 dni, co nie jest zbyt długim okresem, jeśli chcesz spojrzeć na trend danych z roku na rok.

Nie chodzi o to, aby zniechęcić do korzystania z tych systemów, ponieważ mogą one być bardzo cenne – szczególnie dla mniejszych organizacji. Celem jest wskazanie, że mogą wystąpić znaczne koszty i może to być zniechęcające, gdy są one realizowane. Reszta tego artykułu skupi się na rozwiązaniach open source i komercyjnych, które są hostowane samodzielnie.

Opcje narzędzi

ELK

ELK, skrót od Elasticsearch, Logstash i Kibana, jest najpopularniejszym narzędziem open source do agregacji logów na rynku. Korzystają z niego takie firmy jak Netflix, Facebook, Microsoft, LinkedIn czy Cisco. Wszystkie trzy komponenty są rozwijane i utrzymywane przez firmę Elastic. Elasticsearch jest zasadniczo implementacją silnika wyszukiwania NoSQL Lucene. Logstash to system potoków logów, który może pobierać dane, przekształcać je i ładować do magazynu takiego jak Elasticsearch. Kibana jest warstwą wizualizacyjną na wierzchu Elasticsearch.

Kilka lat temu wprowadzono Beats. Beats to kolektory danych. Upraszczają one proces przesyłania danych do Logstash. Zamiast rozumieć właściwą składnię każdego typu logów, użytkownik może zainstalować Beata, który będzie eksportował logi NGINX lub logi Envoy proxy prawidłowo, tak aby mogły być efektywnie wykorzystane w Elasticsearch.

Podczas instalacji stosu ELK na poziomie produkcyjnym, kilka innych elementów może być dołączonych, jak Kafka, Redis i NGINX. Ponadto, często zastępuje się Logstash przez Fluentd, który omówimy później. System ten może być skomplikowany w obsłudze, co w początkowym okresie jego istnienia prowadziło do wielu problemów i skarg. Zostały one w dużej mierze naprawione, ale nadal jest to złożony system, więc możesz nie chcieć go wypróbować, jeśli jesteś mniejszą operacją.

To powiedziawszy, są dostępne usługi, więc nie musisz się o to martwić. Logz.io uruchomi go dla Ciebie, ale jego cena katalogowa jest trochę stroma, jeśli masz dużo danych. Oczywiście, prawdopodobnie jesteś mniejszy i możesz nie mieć zbyt wielu danych. Jeśli nie możesz sobie pozwolić na Logz.io, możesz spojrzeć na coś takiego jak AWS Elasticsearch Service (ES). ES to usługa oferowana przez Amazon Web Services (AWS), która sprawia, że bardzo łatwo jest szybko uruchomić Elasticsearch. Ma również narzędzia do uzyskania wszystkich logów AWS do ES przy użyciu Lambda i S3. Jest to znacznie tańsza opcja, ale istnieje pewne zarządzanie wymagane i istnieje kilka ograniczeń.

Elastic, firma macierzysta stosu, oferuje bardziej solidny produkt, który wykorzystuje otwarty model rdzenia, który zapewnia dodatkowe opcje wokół narzędzi analitycznych i raportowania. Może być również hostowany na Google Cloud Platform lub AWS. To może być najlepsza opcja, ponieważ ta kombinacja narzędzi i platform hostingowych oferuje tańsze rozwiązanie niż większość opcji SaaS i nadal zapewnia dużą wartość. System ten może skutecznie zastąpić lub dać możliwości systemu zarządzania informacjami i zdarzeniami bezpieczeństwa (SIEM).

Stos ELK oferuje również świetne narzędzia wizualizacji poprzez Kibanę, ale brakuje mu funkcji alertowania. Elastic zapewnia funkcjonalność alertów w ramach płatnego dodatku X-Pack, ale nie ma nic wbudowanego w system open source. Yelp stworzył rozwiązanie tego problemu o nazwie ElastAlert i prawdopodobnie są też inne. Ten dodatkowy element oprogramowania jest dość solidny, ale zwiększa złożoność i tak już skomplikowanego systemu.

Graylog

Graylog ostatnio zyskał na popularności, ale miał swój początek, gdy Lennart Koopmann stworzył go w 2010 roku. Dwa lata później narodziła się firma o tej samej nazwie. Pomimo rosnącego wykorzystania, wciąż pozostaje daleko w tyle za stosem ELK. Oznacza to również, że ma mniej funkcji rozwijanych przez społeczność, ale może korzystać z tych samych Beats, których używa stos ELK. Graylog zyskał uznanie w społeczności Go wraz z wprowadzeniem Graylog Collector Sidecar napisanego w Go.

Graylog używa Elasticsearch, MongoDB i serwera Graylog pod maską. To sprawia, że jest tak samo złożony do uruchomienia jak stos ELK, a może nawet trochę bardziej. Jednakże Graylog posiada alerting wbudowany w wersję open source, jak również kilka innych godnych uwagi funkcji, takich jak strumieniowanie, przepisywanie wiadomości i geolokalizacja.

Funkcja strumieniowania pozwala na kierowanie danych do określonych strumieni w czasie rzeczywistym, podczas gdy są one przetwarzane. Dzięki tej funkcji użytkownik może zobaczyć wszystkie błędy bazy danych w jednym strumieniu, a błędy serwera WWW w innym strumieniu. Alerty mogą być nawet oparte na tych strumieniach, gdy nowe elementy są dodawane lub gdy próg został przekroczony. Opóźnienie jest prawdopodobnie jednym z największych problemów w systemach agregacji logów, a Strumienie eliminują ten problem w Graylogu. Natychmiast po otrzymaniu logu może on zostać skierowany do innych systemów poprzez Strumień, nie będąc w pełni przetworzonym.

Funkcja przepisywania wiadomości wykorzystuje otwarty silnik reguł Drools. Pozwala to na analizę wszystkich przychodzących wiadomości w oparciu o zdefiniowany przez użytkownika plik reguł, umożliwiając usunięcie wiadomości (tzw. czarna lista), dodanie lub usunięcie pola lub zmodyfikowanie wiadomości.

Najfajniejszą funkcją może być zdolność Grayloga do geolokalizacji, która obsługuje wykreślanie adresów IP na mapie. Jest to dość powszechna funkcja i jest dostępna również w Kibanie, ale dodaje ona wiele wartości – szczególnie, jeśli chcesz używać tego systemu jako systemu SIEM. Funkcjonalność geolokalizacji jest dostarczana w wersji open source systemu.

Graylog, firma, pobiera opłaty za wsparcie w wersji open source, jeśli tego chcesz. Oferuje również model open core dla swojej wersji Enterprise, która oferuje archiwizację, rejestrowanie audytów i dodatkowe wsparcie. Nie ma wielu innych opcji wsparcia lub hostingu, więc prawdopodobnie będziesz zdany na siebie, jeśli nie korzystasz z Graylog (firma).

Fluentd

Fluentd został opracowany w Treasure Data, a CNCF przyjął go jako projekt inkubujący. Został napisany w C i Ruby i jest rekomendowany przez AWS i Google Cloud. Fluentd stał się powszechnym zamiennikiem dla Logstash w wielu instalacjach. Działa jako lokalny agregator do zbierania wszystkich logów węzłów i wysyłania ich do centralnych systemów przechowywania danych. Nie jest to system agregacji logów.

Używa solidnego systemu wtyczek, aby zapewnić szybkie i łatwe integracje z różnymi źródłami danych i wyjściami danych. Ponieważ dostępnych jest ponad 500 wtyczek, większość twoich przypadków użycia powinna być objęta. Jeśli nie, brzmi to jak okazja do wniesienia wkładu w społeczność open source.

Fluentd jest częstym wyborem w środowiskach Kubernetes ze względu na jego niskie wymagania pamięciowe (zaledwie dziesiątki megabajtów) i wysoką przepustowość. W środowisku takim jak Kubernetes, gdzie każdy strąk ma bocznicę Fluentd, zużycie pamięci będzie rosło liniowo z każdym nowo utworzonym strąkiem. Użycie Fluentd drastycznie zmniejszy wykorzystanie systemu. Staje się to powszechnym problemem z narzędziami stworzonymi w Javie, które są przeznaczone do uruchamiania jednego na węzeł, gdzie narzut pamięci nie był głównym problemem.