Samouczek Logstash: Używanie Logstash do usprawnienia powiadomień e-mail

Aplikacje, które używają e-maili jako głównego mechanizmu zgłaszania błędów i wyjątków, zawsze wydają się na początku dobrym pomysłem. Jako programiści Java myślimy: „hej, od razu będę wiedział, kiedy coś pójdzie nie tak!”

Jednak w pewnym momencie zdasz sobie sprawę, że e-maile z błędami uciekają od Ciebie i musisz wyczyścić swoją skrzynkę odbiorczą. Możesz zignorować błędy 404 (w większości przypadków) i może być fajnie otrzymywać powiadomienia o nowych rejestracjach, ale pod koniec dnia może to być trochę zbyt gorączkowe lub czasochłonne.

Wcześniej czy później odróżnienie „aktywnych” wiadomości e-mail od bezsensownych powiadomień staje się trudne. Możesz skonfigurować reguły i filtry w swojej poczcie, ale nawet tymi mogą stać się niemożliwe do zarządzania.

W tym samouczku Java przyjrzymy się możliwości wykorzystania Logstash do odzyskania kontroli i oczyszczenia skrzynki odbiorczej poczty e-mail oraz ponownego zarządzania błędami e-maili, a wszystko to bez zmiany ani jednej rzeczy w aplikacji.

Konfiguracja i wprowadzanie dziennika

Pierwszym krokiem w naszym samouczku Logstash jest upewnienie się, że wszystkie wiadomości e-mail, które otrzymujesz z systemu, trafiają do jednego folderu. Ponieważ przenosimy wszystkie czynności związane z sortowaniem i zarządzaniem z Twojej skrzynki odbiorczej, nie ma znaczenia, że ​​jest to już jeden duży folder. Śmiało usuń wszystkie foldery i filtry, które już skonfigurowałeś, i zmniejsz je do jednego folderu i jednego filtra.

Przenieś wszystkie e-maile z „[email protected]” do folderu „MyAwesomeAppEmails”. Jeśli masz oddzielną skrzynkę pocztową na te e-maile, będzie to jeszcze prostsze.

Teraz możemy skonfigurować Logstash, aby odpytywał ten folder i analizował wiadomości za pomocą wtyczki IMAP. Wersja 1.4.2 obsługuje tylko pobieranie wiadomości e-mail ze skrzynki odbiorczej, ale istnieje stosunkowo prosta poprawka, która została zastosowana w wersji 1.5, aby umożliwić odpytywanie określonego folderu. Jeśli nie masz oddzielnej skrzynki pocztowej, przed kontynuowaniem zastosuj poprawkę do wtyczki IMAP w instancji Logstash.

 # /etc/logstash/conf.d/01-imap-input.conf input { imap { host => "imap.yourmailserver.com" user => "username" password => "password" secure => true fetch_count => 15 folder => "MyAwesomeAppEmails" # This line will only work if you apply the above mentioned patch } }

Rozpocznie się sprawdzanie nowych wiadomości e-mail i analizowanie ich w zdarzeniach Logstash.

Filtr dziennika

Wiele przydatnych danych jest analizowanych z wiadomości e-mail do różnych właściwości zdarzenia — zauważ, że znacznik czasu wiadomości e-mail jest używany jako „@znacznik czasu” zdarzenia. Co więcej, na podstawie samych nagłówków możemy na przykład zidentyfikować hosta, z którego pochodzi błąd:

 filter { mutate { replace => [ "received", "%{[received][-1]}" ] } grok { match => [ "received", "from %{HOSTNAME:hostname} \(%{HOSTNAME:full_hostname} \[%{IP:ip}\]\)" ] } mutate { remove_field => [ "received" ] } }

To jednak nie wystarczy, aby okiełznać e-maile z błędami. Potrzebujemy trochę więcej, a konkretnie następujące trzy kroki opisujące:

• Rodzaj błędu
• Waga błędu
• Wszelkie szczegóły błędu zawarte w e-mailu

Załóżmy, że umieściłeś nazwę błędu, np. „Widżet nie powiódł się”, a także wagę błędu „BŁĄD” w tytule wiadomości e-mail w następujący sposób: „BŁĄD: Widget nie powiódł się w /var/www/myapp/foobar .php 20”.

Wykorzystamy to do ustawienia kilku właściwości zdarzenia:

 filter { grok { match => [ "subject", "%{WORD:severity}: %{DATA:type} in %{PATH:path} %{POSINT:line}" ] } }

Logstash zawiera szereg predefiniowanych wzorców, których można się spodziewać w dziennikach i innych różnych miejscach. Użyj ich, aby zbudować swoje wzorce Grok i uczynić je łatwiejszymi do odczytania. Użyliśmy „WORD” (pojedyncze słowo), „DATA” (nie chciwy catchall), „PATH” (ścieżka do pliku Unix lub Windows) i „POSINT” (dodatnia liczba całkowita). Możesz także użyć debugera Grok do debugowania wzorców Grok. Wiadomości, które nie pasują do wzorca, zostaną oznaczone tagiem „_grokparsefailure”.

To zajmuje się typem, wagą, plikiem źródłowym i wierszem błędu - w zasadzie wszystkimi istotnymi metadanymi zdarzenia. Teraz przejdźmy do szczegółów.

Dostrajanie Logstash

Być może wcześniej dodałeś ładny podpis w nagłówku lub stopce do wiadomości e-mail, będąc uprzejmą osobą, którą jesteś, ale teraz to przeszkadza. Usuńmy go z wiadomości, a także wszelkie końcowe białe znaki, abyśmy mogli przeanalizować resztę wiadomości e-mail w poszukiwaniu śladu błędów:

 filter { mutate { # gsub takes 3 elements per substitution: field, regular expression and substitution gsub => [ "message", "Your Dev Team", "", "message", "More error details:", "" ] } mutate { strip => "message" } # Split the message into an array of lines, each containing a line of the stacktrace mutate { split => [ "message", "\n" ] } }

Mutacja „gsub” wykorzystuje standardowy obiekt Ruby Regexp, więc wszystkie opcje i funkcje są również dostępne w logstash.

Dane wyjściowe przez Elasticsearch i Amazon SNS

Zastosujmy to do naszej instancji Elasticsearch za pomocą danych wyjściowych Logstash Elasticsearch, abyśmy mogli łatwo przeszukiwać i określać ilościowo gromadzone dane:

 output { if "_grokparsefailure" not in [tags] { elasticsearch { } } }

Wykluczamy wszystkie wiadomości, które nie trafiały poprawnie do Groka, sprawdzając tag „_grokparsefailure”. Założenie jest takie, że tylko e-maile, których temat pasuje do określonego tematu, powinny być interpretowane jako e-maile z błędami. W przeciwnym razie jest to proste i proste.

Logstash zawiera mnóstwo danych wyjściowych, więc rozszerzmy to jeszcze bardziej, korzystając z danych wyjściowych SNS, aby powiadamiać nas o istotnych błędach za pomocą usługi Simple Notification Service (SNS) firmy Amazon. Założymy, że wszystkie błędy typu „notifable” muszą generować powiadomienie. Jeśli nie korzystasz z instancji EC2, musisz podać klucz i klucz tajny AWS.

 output { if "notifiable" in [tags] { sns { region => "us-east-1" arn => "arn:aws:sns:us-east-1:1234567890123456:mytopic" access_key_id => "AWS ACCESS_KEY" # Only specify these if you're not on an EC2 instance secret_access_key => "AWS ACCESS SECRET" # Only specify these if you're not on an EC2 instance } } }

Oznaczanie błędów jako „podlegających zgłoszeniu” zależy od Ciebie. Możesz to zrobić, sprawdzając wagę błędu lub rodzaj błędu.

Teraz możesz ponownie czytać ważne e-maile i możesz mieć pewność, że nie przegapisz ważnych e-maili o błędach. Możesz także podejmować świadome decyzje dotyczące tego, jakie błędy należy naprawić, ponieważ możesz zobaczyć, jak często występuje błąd i kiedy wystąpił jako ostatni. Wyszukiwanie określonego błędu jest również łatwiejsze i szybsze dzięki niesamowitym możliwościom wyszukiwania Elasticsearch opisanym w tym samouczku Logstash.