Newsletter 7.0.5: Update majowy

Witajcie!

Powracamy z nowym zestawem informacji dotyczących Energy Logserver i jego aktualnej wersji - 7.0.5. Tym razem pragniemy zwrócić Waszą uwagę na nowe możliwości zarządzania danymi oraz naszą reakcję na obecne problemy z CentOS 7&8. Mam nadzieję, że poniższa wiedza będzie dla Was przydatna!

 

Możliwości zarządzania danymi

ARCHIWIZACJA WYBRANYCH PÓL

Podczas gdy przechowywanie logów ze względu na zgodność z przepisami jest czymś, co widzimy w prawie każdej organizacji, z którą współpracujemy – zakres dokumenty logu, który chcą przechowywać - jest różny. Dzięki nowo wprowadzonemu „archiwizowaniu wybranych pól” możesz wybrać dokładnie te pola z logu, które chcesz zapisać na swoim dysku. Po prostu utwórz nowe zadanie „Archive” i przefiltruj nazwy, które chcesz uwzględnić w raporcie:

W ten sposób może znacząco zoptymalizować swoją przestrzeń dyskową i szybkość wyszukiwania!

 

OBJECT PERMISSION - USUWANIE POWIĄZANYCH OBIEKTÓW

Teraz, usuwając obiekt, w polu „Object Permission” możesz zaznaczyć powiązane obiekty do usunięcia w tym samym czasie. Ma to na celu skrócenie czasu zarządzania dashboardami dzięki naszemu rozwiązaniu. Pamiętasz, kiedy trzeba było ręcznie usuwać każdą wizualizację z zapisanego dashboardu?

To już nie problem!

Nie, kiedy robisz to następująco:
Saved search à Visualization à Dashboard  -  Możesz usuwać dashboardy wraz z wszystkimi powiązanymi obiektami.

 

HARMONOGRAMOWANIE EKSPORTU DANYCH

Nowo dodany harmonogram pomaga zachować zgodność z powtarzającymi się żądaniami raportowania. Ta funkcja jest przydatna, gdy chcesz:

  1. Zautomatyzować określone zadania raportowania (np. Miesięczny raport wydajności aplikacji)
  2. Przygotować raport z określonej nadchodzącej daty (z harmonogramem nie musisz o tym pamiętać)
  3. Zrzucić surowe dane w zaplanowany sposób

Ta funkcja może być doskonałym dodatkiem zarówno do funkcji związanych ze zgodnością z regulacjami, jak i zarządzaniem danymi.

 

Aktualizacje techniczne

 IMPLEMENTACJA MOŻLIWA DLA ORACLE LINUX 7/8, CENTOS STREAM & SCIENTIFIC LINUX

Nasze implementacje są teraz dodatkowo możliwe dla Oracle Linux 7/8, Scientific Linux 7, Centos Stream (a także pierwotnie dla Centos 7/8 i RedHat7 / 8). Zdecydowaliśmy się na wprowadzenie nowych możliwości wdrożeniowych ze względu na ostatnie problemy z dystrybucją Linux Centos. Więcej w poniższym artykule: CentOS Linux is dead—and Red Hat says Stream is “not a replacement

 

Jako Twoje techniczne wsparcie - z przyjemnością omówimy tą sytuację i pomożemy Ci przygotować się na przyszłość!

Newsletter 7.0.5: Nowa wersja i ulepszone raportowanie

Witajcie.

Nadeszła nowa wersja! Energy Logserver jest obecnie w wersji 7.0.5. Planowaliśmy, że ta aktualizacja będzie mniejsza, obejmująca głównie zmiany w zakresie optymalizacji i stabilizacji. Okazało się jednak, że dodaliśmy istotne funkcje, nad którymi pracowaliśmy już przez jakiś czas. Poniżej znajduje się kilka najważniejszych informacji.

 

Główne zmiany

SUNBURST IOC

Dodaliśmy wykrywanie SUNBURST IOC do Energy Logserver. SUNBURST to poważne zagrożenie, które może zostać wykorzystać do wykradania poufnych informacji z organizacji, a nawet przejęcia kontroli nad zainfekowanymi systemami. Atak ten jest bardzo poważny i warto monitorować jego aktywność. Energy Logserver został wyposażony w predefiniowane alerty, których można użyć do wykrywania SUNBURST. Możesz przeczytać więcej tutaj https://energylogserver.pl/pl/detekcja-sunburst/

Alert przez syslog

Dodano funkcję do interfejsu alertów. Możesz wybrać metodę alarmowania jako wiadomość syslog. Jest to bardzo przydatne do integracji Energy Logserver z wieloma różnymi rozwiązaniami, które mogą odbierać dane lub sygnał za pośrednictwem syslog. Możesz wybrać hosta, port, protokół, severity i facility tej metody powiadamiania.

Obsługa znaków narodowych

Energy Logserver ma teraz pełne wsparcie dla znaków narodowych. Dzięki temu jest całkowicie gotowy na wszelkie niestandardowe dane z nietypowych źródeł. Każdy moduł Energy Logserver jest przygotowany do przetwarzania i działania ze 100% wydajnością z takimi danymi.

Ulepszone raportowanie

Raporty i eksporty zostały wzbogacone o dodatkowe informacje. Teraz możesz zobaczyć, kto i kiedy utworzył raport lub zadanie eksportu. Harmonogram raportów został zoptymalizowany i przeniesiony do tej samej karty, co twórca raportów. Dzięki tej aktualizacji masz jeszcze większą kontrolę i informacje o użytkownikach Energy Logserver. To kolejny krok w kierunku, aby zarządzanie użytkownikami Energy Logserver było tak łatwe i przejrzyste, jak to tylko możliwe.

 

Zajęliśmy się również jednym z najbardziej zagmatwanych tematów w elasticsearch: Keyword i Text - jaka jest różnica.

Zapraszam do przeczytania krótkiego artykułu tutaj: https://energylogserver.pl/pl/roznica-miedzy-text-a-keyword/

Jeśli cię to zaintereoswało, to kilka słów o optymalizacji powinno być czymś, o czym chcesz się dowiedzieć 🙂

Przeczytaj więcej na naszym blogu: https://energylogserver.pl/pl/slow-kilka-o-optymalizacji/

 

Bądźcie bezpieczni i szczęśliwego wyszukiwania!

Zespół Energy Logserver

Różnica między Text a Keyword

W elasticsearch występują dwa typy danych, które często bywają kłopotliwe dla osób niedoświadczonych w pracy z systemem – Keyword i Text. Oba typy są rodzajem stringa, ale elasticsearch inaczej je interpretuje, przez co można na nich wykonać inne operacje.

 

Skąd się bierze typ pola?

Ogółem, to jakim typem jest pole, określa template. Jest to wzorzec tworzenia indexów w elasticsearch – w tym mapowania pól. Jeśli dany template nie określa jasno jakiego typu ma być dane pole, elasticsearch domyślnie stworzy dynamiczny mapping dla typów Keyword i Text. Nie jest jednak to rekomendowane ze względu na przestrzeń dyskową jaką można zaoszczędzić poprzez planowanie przypisanych typów do pól.

 

Index odwrócony

Aby zrozumieć wagę problemu, należy spojrzeć na odwrócony index elasticsearch[1].  Jest to specyficzny sposób w jaki system zapisuje dane i to dzięki temu rozwiązaniu elasticsearch jest bardzo szybki w zwracaniu odpowiedzi nawet w dużej skali czasu.

Odwrócony index działa podobnie do indexu w niektórych książkach. Na końcu książki można znaleźć listę wyrazów z informacją na których stronach się te wyrazy pojawiły. Elasticsearch robi dokładnie to samo dla każdego wyrazu z informacją w którym dokumencie się znajduje.

Przykład dokumentu

Dla przykładu spójrzmy na dokument o id "moj-dokument". Ma on pole "adres", a wartość tego pola to "Wiejska 20, Warszawa".
POST "localhost:9200/moj-index/_doc/moj-dokument" -d'
{
"adres" : "Wiejska 20, Warszawa"
}'

Poniżej prezentacja, jak widzi to elasticsearch w odwróconym indexie dla typów

Keyword

 

Text

Różnica w zapytaniu

Elasticsearch po otrzymaniu zapytania najpierw sprawdza index odwrócony pod względem dopasowania. Jeśli je znajdzie, wyświetla dokumenty, które odpowiadają temu zapytaniu. Dlatego jeśli odpytamy elasticsearch o wartość „Warszawa”, dokument z typem Keyword może nie zwrócić rezultatu, ponieważ wartość to dosłownie „Wiejska 20, Warszawa”. Odwrotnie jest w przypadku typu Text - ponieważ zawartość pola została przeanalizowana, elasticsearch jest w stanie odnaleźć pojedyncze wyrazy w odwróconym indexie i zwrócić odpowiedź w postaci dokumentu.

Oczywiście istnieją jeszcze różne rodzaje zapytań do Elasticsearch i w zależności od tego, które zostaną użyte, można otrzymać różne wyniki. Ta kwestia jednak nie dotyka bezpośrednio różnic w samych typach pól.

 

Podsumowując

Różnice między tymi dwoma polami są znaczące. Generalnie używamy typów keyword dla stałych wartości w danych, których nie chcemy analizować, np. nazwa kraju, aplikacji, itp. Typu Text używamy, kiedy musimy skorzystać z mocy przeszukiwania pełnotekstowego, np. w polu message, które zawiera oryginalną wiadomość z systemu.

 

 

 

[1] Po prawdzie, odwrócony index jest właściwością silnika Apache Lucene, na bazie którego powstał Elasticsearch. Celem ułatwienia zrozumienia problemu, użyto skrótu myślowego.

Newsletter 7.0.4 aktualizacja luty: Wiki

Witamy

Drugi miesiąc minął naprawdę szybko w Energy Logserver. Jesteśmy pełni motywacji, bo wydaje się, że każdy dzień przynosi nowe wyzwania.

Obecnie pracujemy nad kilkoma przełomowymi modułami dla Energy Logserver. W tej chwili zakończyliśmy dopracowywanie i aktualizację istniejących funkcji i chętnie podzielimy się informacjami. Aby poznać interesujące funkcje, zarejestruj się na nasze webinarium, więcej informacji poniżej:

 

Webinar Energy Logserver 7.0.4 – Widoki użytkownika i zaawansowane uprawnienia

25.03.2021 10:00 czasu polskiego

https://zoom.us/webinar/register/WN_UZscLOiwRbm1FzHa0_mPeQ

 

Główne zmiany

Widoki niestandardowe
Role mogą teraz mieć przypisane uprawnienia do modułów, które pozwolą tworzyć dedykowane widoki użytkowników. Ta zaawansowana, ale łatwa w użyciu funkcja pozwala na takie przypadki użycia, jak:
- Tworzenie dedykowanego widoku wizualizacji dla zespołów analitycznych, które nie muszą widzieć tekstowych danych.
- Widoki SOC, które muszą widzieć jasne informacje i muszą mieć możliwość przełączania się między danymi z różnych modułów.
- Twórzenie przejrzystych i oddzielnych widoków dla różnych działów, nawet jeśli dane są nadal scentralizowane w jednym środowisku.

Wiki
Energy Logserver ma teraz wbudowane rozwiązanie wiki. Pozwala to tworzyć i zachować łatwą do odczytania dokumentację i informacje o Twojej infrastrukturze. Używając Wiki z Energy Logserver, upewniasz się, że informacje są łatwe do odczytania i dostępne tylko dla tych, którzy powinni mieć do nich dostęp.

WEC
Windows Event Forwarding (WEF) to częsty temat rozmów w środowisku z dużą infrastrukturą systemu Windows. Chodzi o to, aby mieć możliwość udostępniania danych bez instalowania agenta. Dlatego też wymagane jest, aby kolektor zdarzeń, zwany Windows Event Collector (WEC) był jednocześnie komputerem z systemem Windows, co powoduje pewne problemy w utrzymaniu i monitorowaniu. Opracowaliśmy niezależne rozwiązanie, które jest przeznaczone do wysyłania danych z systemów Windows do systemu Linux!
Energy Event Collector jest zaprojektowany do korzystania z natywnej technologii Windows, ale rozszerza jego funkcje z zamkniętego środowiska i pozwala na bardziej elastyczne podejście.
Więcej informacji można znaleźć tutaj: www.eventcollector.com

Archiwum
Automatyczna archiwizacja danych jest ważnym aspektem zarządzania przestrzenią dyskową wewnątrz Energy Logserver. Ten moduł został wprowadzony w poprzednim biuletynie. Warto podkreślić, jak ważne jest zarządzanie retencją danych. Stale ulepszamy i optymalizujemy funkcje modułu archiwum.

Jeśli przegapiliście nasz ostatni webinarium na temat modułu archiwum, zapraszamy do obejrzenia nagranego materiału na naszym kanale Youtube tutaj: https://youtu.be/FsB29W7bqGI

Bądźcie bezpieczni i szczęśliwego wyszukiwania!
Zespół Energy Logserver

Integracja ze skanerami podatności

Luki i podatności są częstym problemem w społeczności IT. Niektóre są poważne, inne - nie tak bardzo. Najważniejsze jest, aby wiedzieć, czy w naszych systemach występują, jak bardzo są one krytyczne i jak można je naprawić. Istnieją narzędzia, które mogą pomóc w uzyskaniu tych informacji, zwane skanerami podatności.

Skanery podatności sprawdzają Twoje systemy i aplikacje, szukając znanych exploitów lub backdoorów. Podobnie jak oprogramowanie antywirusowe, programy te mają własne bazy danych, które wymagają regularnej aktualizacji. Raporty z takiego skanu mogą być jednak długie i trudne do analizy.

Energy Logserver ma dobrą wiadomość dla wszystkich, którzy chcą zwiększyć widoczność i korelację bezpieczeństwa w swoim środowisku. Obecnie integrujemy się z wiodącymi rozwiązaniami: Qualys, Tennable.sc i oczywiście OpenVAS 🙂

Oprócz tej integracji dodaliśmy również nowy dashboard przeznaczony dla skanerów podatności. Oznacza to, że możemy nie tylko zbierać dane i integrować się ze skanerami podatności, ale także dajemy ci możliwość dokładnego spojrzenia w to, co zostało wykryte w twojej infrastrukturze i skorelowania te informacje z danymi z różnych źródeł.

Interaktywny dashboard jest wyposażony w listę znalezionych problemów i zalecanych rozwiązań, listę głównych hostów z wykrytymi lukami oznaczonymi kolorami i wiele innych.

Jeśli jesteś zainteresowany tą funkcjonalnością lub twoja wersja Energy Logserver nie posiada tej integracji skontaktuj się z naszym zespołem lub wyślij maila na sales[at]energylogserver.pl

Newsletter 7.0.4 i Webinar: Moduł archiwum

Witamy.

Na wstępie życzymy szczęśliwego Nowego Roku od całego zespołu Energy Logserver.
Z przyjemnością informujemy, że Energy Logserver jest obecnie w wersji 7.0.4.
Ta wersja przynosi niesamowite zmiany wraz z nowym modułem - archiwum, który pozwala zarządzać automatyczną archiwizacją danych. Więcej o tym poniżej.

Jeśli chcesz zobaczyć nowe funkcje w akcji, zapraszamy na nadchodzący webinarium!

Webinar Energy Logserver 7.0.4 - Moduł archiwum
21.01.2021 10:00 AM

https://zoom.us/webinar/register/WN_sseWJaxzRmW6m_a7hR93uA

Główne zmiany

Nowy moduł: Archiwum
Pozwala skonfigurować automatyczną archiwizację wybranych indeksów i wysyłać je we wskazane miejsce. Co więcej, dzięki temu modułowi możesz przeszukiwać zarchiwizowane dane bez przenoszenia ich z powrotem do systemu. Proces przywracania również jest naprawdę prosty - po prostu wybierz archiwa, które chcesz przywrócić i gotowe!

Ulepszony moduł zarządzania agentami
Zarządzanie agentami nie tylko wygląda lepiej, ale teraz daje również możliwość zdalnej kontroli żądanego agenta. Ponadto możesz monitorować / zmieniać konfiguracje niestandardowe, niezwiązane z agentami Energy Logserver.

Nowa domyślna integracja
Dodaliśmy nową integrację do Energy Logserver. Teraz Energy Logserver 7.0.4 jest domyślnie zintegrowany ze skanerami luk w zabezpieczeniach i oferuje niesamowity pulpit nawigacyjny do wizualizacji wszystkich zebranych danych.

Ulepszone alerty
Moduł alertów obsługuje teraz zmianę nazw istniejących alertów (wiemy, że wielu z Was na to czekało 😉 ) ale co więcej, można grupować alerty, np. grupa dla Windows, itp. Ponadto dodaliśmy obsługę GUI do powiadamiania na Slack i OP5 Monitor. I wreszcie - dodaliśmy dwie nowe opcje:
• Calendar, który pozwala zarządzać czasem powiadomień o alertach w oparciu o format cron
• Escalate, która powoduje eskalację alarmu po określonym czasie.

Pełna lista zmian znajduje się na stronie: https://kb.energylogserver.pl/en/latest/CHANGELOG.html

Jeśli szukasz interesujących przypadków użycia Energy Logserver, znajdziesz kilka poniżej lub możesz też je przeczytać na blogu na naszej stronie:

Wykrywanie i alertowanie logowań po godzinach pracy
https://energylogserver.pl/pl/wykrywanie-i-alertowanie-logowan-po-godzinch-pracy

Wykrywanie i alertowanie anomalii w ruchu sieciowym
https://energylogserver.pl/pl/wykrywanie-i-alertowanie-anomalii-w-ruchu-sieciowym

Wykrywanie i alertowanie ataków ddos w energy logserver
https://energylogserver.pl/pl/wykrywanie-i-alertowanie-atakow-ddos-w-energy-logserver

Bądźcie bezpieczni i szczęśliwego wyszukiwania!
Zespół Energy Logserver

Webinar: Zarządzanie incydentami w Energy Logserver – od SOC do analizy

Witajcie.

Mamy nadzieję, że w tych interesujących czasach pozostaniecie bezpieczni i zdrowi. W Energy Logserver nieustannie pracujemy nad dostarczaniem Ci najwyższej jakości funkcji. Dlatego chcielibyśmy podzielić się z Tobą nowościami.

Energy Logserver jest obecnie w wersji 7.0.3. Skupiliśmy się mocno na korelacji zdarzeń i alertach wraz z ulepszoną kontrolą wewnętrzną. Poniżej umieszczamy najciekawsze aspekty tej wersji.

Główne zmiany

Ulepszone typy alertów:

  • Chain - możliwość indywidualnego dopasowania poszczególnych reguł. Reguła jest uruchamiana po osiągnięciu progu i wystąpieniu oczekiwanej sekwencji danych. Przykład: wykrycie nieudanych logowań, po których następuje sukces.
  • Logical - aktywuje się, gdy wybrane alerty są wyzwalane ze zdefiniowaną logiką. Przykład: wykrycie co najmniej trzech nieudanych logowań OR logowanie roota AND dwóch zmiany konfiguracji usługi.

 

Moduł agenta:

Dzięki Energy Logserver 7.0.3 możesz spodziewać się nowego wyglądu modułu Agentów, odpowiedzialnego za centralne zarządzanie. Poprawiliśmy między innymi niezawodność, lepszą kontrolę stanu agentów - wszystko dostępne z poziomu interfejsu użytkownika.

 

Skimmer:

Czy znasz Skimmera, nasz wewnętrzny proces monitorowania? Nowa wersja zapewnia więcej wskaźników kontroli stanu klastra, takich jak:

  • Wskaźnik indeksowania - pokazuje ilość EPS w systemie.
  • Oczekiwane węzły danych - Energy Logserver mierzy swoją wydajność i oblicza, ile węzłów danych wymaga do optymalnego przepływu pracy.
  • Wykorzystanie heap - pokazuje przypisane użycie pamięci dla każdej grupy komponentów w infrastrukturze Energy Logserver.
  • Miejsce na dysku - monitorujemy wykorzystanie miejsca na dysku. Teraz możesz zobaczyć, ile miejsca pozostało na dane.
  • i inne...

Jeśli nie znasz Skimmera, zdecydowanie powinieneś to sprawdzić!
https://kb.energylogserver.pl/en/latest/21-00-00-Monitoring/21-00-00-Monitoring.html#skimmer

 

Nasza społeczność zadaje nam nowe, trudne pytania, na które z chęcią odpowiadamy. Cieszymy się, że możemy współpracować z tymi, którzy podzielają pasję do oprogramowania monitorującego. Wspólne rozwiązywanie problemów jest bardzo satysfakcjonujące. Oto kilka najważniejszych informacji:

Jak radzić sobie z ponadwymiarowymi dokumentami Kafki w Logstash?

Jak usunąć zduplikowane lub mało ważne wiadomości z syslog?

Dlaczego czas przetwarzania filtru DNS Logstash jest długi?

 

Nadchodzące webinary:

Zarządzanie incydentami w Energy Logserver - od SOC do analityki

10.12.2020 o godzinie 14:00 czasu czasu polskiego

Kliknij tutaj, aby się zarejestrować: https://zoom.us/webinar/register/WN_r8Qzg_vPRd-Vhk5pT4L9kQ

Opis:

Podczas tego webinarium przyjrzymy się, jak wyszukiwać dane pod kątem błędów i anomalii. Stworzymy incydenty i przyjrzymy się, jak pracować z Energy Logserver z dwóch perspektyw - operacyjnej i analitycznej z dashboardami.

 

Bądźcie bezpieczni i szczęśliwego wyszukiwania!

Zespół Energy Logserver

 

 

Jak usunąć duplikaty lub nieistotne wiadomości z wiadomości syslog?

Opis problemu

Pewnie wszyscy znamy taki wpis w dziennikach syslog:
... last message repeated ... times

można to jakoś łatwo wykluczyć?

Rozwiązanie problemu

Tak, można. Jest wiele sposobów na pozbycie się zbędnych wiadomości, a poniższy jest tylko jednym tego przykładem:

filter {
&nbsp&nbspif [source] == "/ var / log / messages" {
&nbsp&nbsp&nbsp&nbspif [message] =~ / last message repeated [0-9] + times / {
&nbsp&nbsp&nbsp&nbsp&nbsp&nbspdrop {}
&nbsp&nbsp&nbsp&nbsp}
&nbsp&nbsp}
}

Powolny filtr DNS w logstashu

Opis problemu

Uruchomiłem filtr DNS na logstashu, ale wyraźnie widać, że prędkość indeksowania zmalała przez dodanie resolve.
Czy musi tak być?

Mój konfig jak w dokumentacji :

filter {
&nbsp&nbspdns {
&nbsp&nbsp&nbsp&nbspreverse => [ "source_host", "field_with_address" ]
&nbsp&nbsp&nbsp&nbspresolve => [ "field_with_fqdn" ]
&nbsp&nbsp&nbsp&nbspaction => "replace"
&nbsp&nbsp}
}

Rozwiązanie problemu

 

W starszych wersjach logstasha (2018*) po użyciu dyrektywy cache_size/failed_cache_size był błąd uniemożliwiający równoległe odpytywanie cache-a.

Bardzo fajną analizę wraz z wykresami wydajności przeprowadził zgłaszający:
https://github.com/logstash-plugins/logs...ns/pull/42

Gotowy config do użycia poniżej - proszę pamiętać, że pełną wydajność uzyskuje się po zapełnieniu cache-u danymi.
Warto także używać szybkich dnsów np 1.1.1.1/1.0.0.1


filter{
&nbsp&nbsp# dns resolve
&nbsp&nbspdns {
&nbsp&nbsp&nbsp&nbspreverse => [ "hostname" ]
&nbsp&nbsp&nbsp&nbspaction => "replace"
&nbsp&nbsp&nbsp&nbspnameserver => ["1.1.1.1", "1.0.0.1"]
&nbsp&nbsp&nbsp&nbsphit_cache_size => 131072
&nbsp&nbsp&nbsp&nbsphit_cache_ttl => 900
&nbsp&nbsp&nbsp&nbspfailed_cache_size => 131072
&nbsp&nbsp&nbsp&nbspfailed_cache_ttl => 900
&nbsp&nbsp}

&nbsp&nbsp# filter performance
&nbsp&nbspmetrics {
&nbsp&nbsp&nbsp&nbspmeter => "events"
&nbsp&nbsp&nbsp&nbspadd_tag => "metric"
&nbsp&nbsp}
}

output {
&nbsp&nbspif "metric" in [tags] {
&nbsp&nbsp&nbsp&nbspstdout {
&nbsp&nbsp&nbsp&nbsp&nbsp&nbspcodec => line {
&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbspformat => "DNS filter rate: %{[events][rate_1m]}"
&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp}
&nbsp&nbsp&nbsp&nbsp}
&nbsp&nbsp}
}

Co zrobić ze zbyt dużymi dokumentami Kafki w Logstashu?

Opis problemu

 

Kafka nie przyjmuje dokumentów ponieważ są one za duże.

Zwiększanie limitów nic nie daje, bo osiągnięto poziom 10MB i dalej niektórych zdarzeń logstash nie jest w stanie ich wysłać do kafki.

Po czasie skutkuje to zapełnieniem kolejki w logstashu, co w konsekwencji prowadzi do zawieszenia całego pipeline...

Jak najlepiej rozwiązać taki problem?

Logi
[2020-09-03T00:53:38,603][WARN ][logstash.outputs.kafka ] KafkaProducer.send() failed: org.apache.kafka.common.er rors.RecordTooLargeException: The message is 1223210 bytes when serialized which is larger than the maximum request size you have configured with the max.request.size configuration. {:exception=>java.util.concurrent.ExecutionExcep tion: org.apache.kafka.common.errors.RecordTooLargeException: The message is 1223210 bytes when serialized which is larger than the maximum request size you have configured with the max.request.size configuration.} [2020-09-03T00:53:38,644][INFO ][logstash.outputs.kafka ] Sending batch to Kafka failed. Will retry after a delay . {:batch_size=>1, :failures=>1, :sleep=>0.1} [2020-09-03T00:53:38,769][WARN ][logstash.outputs.kafka ] KafkaProducer.send() failed: org.apache.kafka.common.er rors.RecordTooLargeException: The message is 1223210 bytes when serialized which is larger than the maximum request size you have configured with the max.request.size configuration. {:exception=>java.util.concurrent.ExecutionExcep tion: org.apache.kafka.common.errors.RecordTooLargeException: The message is 1223210 bytes when serialized which is larger than the maximum request size you have configured with the max.request.size configuration.} [2020-09-03T00:53:38,770][INFO ][logstash.outputs.kafka ] Sending batch to Kafka failed. Will retry after a delay . {:batch_size=>1, :failures=>1, :sleep=>0.1} [2020-09-03T00:53:38,878][INFO ][logstash.outputs.kafka ] Exhausted user-configured retry count when sending to K afka. Dropping these events. {:max_retries=>1, :drop_count=>1} [2020-09-03T02:15:12,763][WARN ][logstash.outputs.kafka ] KafkaProducer.send() failed: org.apache.kafka.common.er rors.RecordTooLargeException: The message is 1216262 bytes when serialized which is larger than the maximum request size you have configured with the max.request.size configuration. {:exception=>java.util.concurrent.ExecutionExcep tion: org.apache.kafka.common.errors.RecordTooLargeException: The message is 1216262 bytes when serialized which is larger than the maximum request size you have configured with the max.request.size configuration.} [2020-09-03T02:15:12,764][INFO ][logstash.outputs.kafka ] Sending batch to Kafka failed. Will retry after a delay . {:batch_size=>1, :failures=>1, :sleep=>0.1} [2020-09-03T02:15:12,871][WARN ][logstash.outputs.kafka ] KafkaProducer.send() failed: org.apache.kafka.common.er rors.RecordTooLargeException: The message is 1216262 bytes when serialized which is larger than the maximum request size you have configured with the max.request.size configuration. {:exception=>java.util.concurrent.ExecutionExcep tion: org.apache.kafka.common.errors.RecordTooLargeException: The message is 1216262 bytes when serialized which is larger than the maximum request size you have configured with the max.request.size configuration.} [2020-09-03T02:15:12,871][INFO ][logstash.outputs.kafka ] Sending batch to Kafka failed. Will retry after a delay . {:batch_size=>1, :failures=>1, :sleep=>0.1}

&nbsp&nbsp

Issue solution

 

W zależności od potrzeb proponujemy 3 rozwiązania które powinny się sprawdzić:

1. Tagowanie dokumentów posiadających więcej niż 10000 znaków w polu message.
Taki dokument można w sekcji output skierować np pliku - output file{}, a następnie podejrzeć i odpowiednio sparsować tak żeby pole message było już pocięte na odpowiednie pola. W tym przypadku duże dokumenty będą pomijały output kafki i pipeline logstasha się nie zapełni.


filter&nbsp{
&nbsp&nbspruby&nbsp{
&nbsp&nbsp&nbsp&nbspcode&nbsp=>&nbsp"
&nbsp&nbsp&nbsp&nbsp&nbsp&nbspif&nbspevent.get('message').length&nbsp>&nbsp10000
&nbsp&nbsp&nbsp&nbsp&nbsp&nbspevent.tag('TLTR')
&nbsp&nbsp&nbsp&nbsp&nbsp&nbspend
&nbsp&nbsp&nbsp&nbsp"
&nbsp&nbsp}
}

2. Truncate + Tagowanie.
Dokument zostanie obcięty po określonej liczbie bajtów oraz otagowany tak żeby było wiadomo który message jest ucięty.
W tym przypadku duże dokumenty będą ucinane i zostaną poprawnie odebrane po stronie kafki, a pipeline logstasha się nie zapełni

filter&nbsp{
&nbsp&nbsptruncate&nbsp{
&nbsp&nbsp&nbsp&nbspfields&nbsp=>&nbsp["message"]
&nbsp&nbsp&nbsp&nbsplength_bytes&nbsp=>&nbsp49999999
&nbsp&nbsp&nbsp&nbspadd_tag&nbsp=>&nbsp"TLTR"
&nbsp&nbsp}
}

3. Drop.
Rozwiązanie przydatne wtedy, gdy wiemy że "duże dokumenty" zawierają nieistotne informacje i możemy pozwolić sobie na ich utratę.
W tym wypadku dokument który zostanie odbity od kafki, wróci do kolejki tylko jede raz, a następnie zostanie porzucony. Pipeline logstasha przez to nie będzie utrzymywał tego dokumentu.
W sekcji output musimy dodać:

retries=> 1