Kilka tygodni temu pokazałem, jak firma można łatwo zmotywować ludzi pracujących nad różnymi projektami, które niekoniecznie są wciągające/ciekawe. W Kilku następnych postach, opiszę co ja zrobiłem w trakcie tego jednego dnia. Przekaże cały tok rozumowania jak i kroki jakie zrobiłem w celu stworzenie działającego POC. Zdecydował się rozbić materiał ze względu na jego długość. Raz w życiu wrzuciłem 30 stronicowy post, którego chyba nikt nie przeczytał do końca. Nie chcę tego błędu popełniać. Więc dla fanów całość, zapraszam za kilka tygodni. Dla fanów informacji podzielonej tak by dało się ją łatwo przyswoić, zapraszam już dzisiaj.

Z cyklu elastic, do tej pory ukazały się artykuły:

  1. elastic – wstęp
  2. elastic – logstash
  3. elastic – elasticserach
  4. elastic – kibana

Cel Hack Day

Wprowadzenie rozwiązań ułatwiających nam pracę – kod, deployment etc – bez konieczności modyfikowania aktualnych produktów.

Mój cel

Aplikacje aktualnie są słabo monitorowane, potrzebujemy czegoś co da nam prawie w czasie rzeczywistym podgląd tego co się dzieje. Szukam rozwiązania, które będzie działało z tym co mamy. Nie interesują mnie dostępne produkty Microsoftowe, chcę czegoś nowego, czego jeszcze nie dotykałem.

Wstępna analiza

Analizę wykonałem wcześniej, ciutkę. Tylko po to by nie marnować pół dnia na szukanie co bym chciał sprawdzić i zaimplementować. Chodziło o to by wyciągnąć jak najwięcej z dnia. Dzięki temu wiedziałem, że chcę się ograniczyć do 3 produktów i zrobić Proof of Concept (PoC) by sprawdzić czy to co chcemy mieć jest możliwe. Wszystkie trzy produkty należały do tej samej firmy Elastic (stąd też nazwa serii):

  • Logstash – służący do gromadzenia logów z wielu źródeł i ich unifikacji. Umożliwia bezpośrednie wyrzucenie z unifikowanych informacji do różnych strumieni wyjściowych w tym Elasticsearch.
  • Elasticsearch – narzędzie do indeksowania, analizowania, przeszukiwania i przechowywania danych, bazujące na formacie JSON.
  • Kibana – narzędzie które przeszukuje Elasticsearch i wizualizuje informacje – czy to tabelka, czy diagram, to co chcemy.

Dla mojego własnego PoC wystarczy, że udowodnię iż jestem wstanie wyświetlać logi IIS jak i logi naszej/naszych aplikacji.

Wymagania

Wiedziałem co chciałem zrobić, kwestia tylko tego wykonania. A więc najpierw instalacja. Jedyna rzecz, która mi się nie podobała to wymagania. Musiałem zainstalować Java, czego naprawdę nie chciałem (rok! się broniłem ;), ale poległem). Tak więc, to jest jedyne wymaganie i trzeba je spełnić. Ja to zrobiłem instalując po prostu Java Runtime Environment  i upewniając się, że istnieje zmienna JAVA_HOME. U mnie wskazuje ona na:

C:\Program Files\Java\jre1.8.0_102

Jednak czytałem, że nie zaleca się wykorzystywania JRE, dokładniej:

While a JRE can be used for the Elasticsearch service, due to its use of a client VM (as opposed to a server JVM which offers better performance for long-running applications) its usage is discouraged and a warning will be issued.

Więc może warto zainstalować pełne JDK… sami zadecydujcie, jak będziecie to robić. Trzeba jedynie pamiętać o JAVA_HOME.

Instalacja

Mając Java, możemy ściągnąć narzędzia (linki do stron z pobraniami):

Uwaga: Dla postu użyłem wersję 5.1.x. Wcześniejsze wersje miały ciutkę inną konfigurację jak i inne (nie wszędzie) komendy/nazwy skryptów. Więc jak przypadkowo macie wersję inną niż 5 na komputerze, to niestety, przykłady mogą wam nie działać.

Narzędzia są o tyle fajne, że nie trzeba ich instalować – no prawie, w sensie nie ma instalatora ;) Wystarczy więc przygotować sobie odpowiedni katalog i rozpakować każde z narzędzi do niego, dla uproszczenia u mnie to będzie:

d:\mon

Każde z narzędzi zaś trafia do swojego katalogu:

d:\mon\ls        # ls - logstash
d:\mon\es        # es - elasticsearch
d:\mon\kibana

Teraz, by móc sprawnie przechodzić pomiędzy narzędziami proponowałbym posiadanie czegoś w stylu ConEmu – w szczególności, że najnowsze wersję są super i niezależnie od tego wpisu, gorąco polecam. W razie co zawsze można ściągnąć cmder, ConEmu z kilkoma bajerami :) Przyda się to nam, gdyż będziemy pracować na kilku oknach linii poleceń.

Pliki logów

Zanim przejdziemy do konfiguracji narzędzi, musimy przygotować sobie źródło logów, które byśmy chcieli monitorować. Dla uproszczenia tego artykułu użyje logów IIS. Na swoim komputerze mam IIS zainstalowanego i większość windowsowych web devów pewnie też. Logi które będę chciał analizować, znajdują się podkatalogach W3SVCX (X to numer) w katalogu:

C:\inetpub\logs\LogFiles

W katalogach W3SVCX mamy pliku log które u mnie wyglądają tak:

#Software: Microsoft Internet Information Services 10.0
#Version: 1.0
#Date: 2017-01-11 13:41:26
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
2017-01-11 13:41:26 ::1 GET /index1.html - 80 - ::1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/54.0.2840.50+Safari/537.36 - 200 0 0 255
2017-01-11 13:41:26 ::1 GET /backson.jpg - 80 - ::1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/54.0.2840.50+Safari/537.36 http://localhost/index1.html 200 0 0 2
2017-01-11 13:41:26 ::1 GET /favicon.ico - 80 - ::1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/54.0.2840.50+Safari/537.36 http://localhost/index1.html 404 0 2 2

To co jest ważne to pola jakie są u mnie zapisywane w logu, wypisuje wszystkie osobo, byście sprawdzili czy też tak macie czy też nie. Gdyż będziemy ten log parsować, a parsowanie niestety lubi być dokładne:

date
time
s-ip
cs-method
cs-uri-stem
cs-uri-query
s-port
cs-username
c-ip
cs(User-Agent)
cs(Referer)
sc-status
sc-substatus
sc-win32-status
time-taken

Macie takie same? Jak nie, to spoko, będziecie musieli tylko poprawić parser ale to też nie będzie trudne, pokażę także narzędzia które ułatwiają konfiguracje parsera.

Podsumowanie

To tyle na dziś. Jeżeli nie mieliśmy nic z tych rzeczy to samo przygotowanie komputera zajmie nam około 30 minut. To co dowiedzieliśmy się to, to, że elastic dostarcza narzędzi do procesowania logów (logstash), zbierania i indeksowania ich (elasticsearch) i następnie wizualizacji zindeksowanych logów (kibana). Każde z tych narzędzi wymaga Javy, i wszystkie instalujemy poprzez rozpakowanie plików, co daje nam możliwość łatwego ich przenoszenia między systemami.

Za tydzień zaś, skoncentrujemy się na logstash i jego konfiguracji.

Z ciekawości, korzystaliście już z tych narzędzi? I jakie wrażenia? A jak nie to dlaczego?

PODOBNE ARTYKUŁYWIĘCEJ OD AUTORA

12 KOMENTARZE

  1. A może Docker i dwie pieczenie przy jednym ogniu :) Są gotowe skonfigurowane obrazy ELK’a, teraz już Elastic Stack’a. Mała konfiguracja i działa świetnie. IMO na PoC’a najlepsze rozwiązanie.
    Zajmuję się testami wydajnościowymi i potrzebowałem zwizualizować real time co się dzieje ma maszynach. Będąc ograniczony tylko/aż do open source wykorzystałem ELK – strzał w 10 :) Zbierałem w elasticsearch logi z serwerów www i jmeter’a – kontrola podstawą zaufania.

    • super :) zaś z Dockera zrezygnowałem z trzec powodów:
      1) sam chciałem wszystko przejść by potem móc to odpowiednia skonfigurować
      2) to był moment kiedy docker nie wiedział czego chce na windows i chyba opcja Virtual Box już nie była dostępna, a opcja z hyper-v u mnie nie działa z powodu kontrolera usb-3, więcej zachodu było w postawieniu dockera niż zrobieniu wszystkiego samemu :)
      3) na windowsach nie działało poprawnie mapowanie na lokalny dysk – by obraz dockera miał do niego dostęp. na linuxie i macu to śmigało. Teraz na windowsie chyba już też ale nie jestem pewny… i nie wiem czy to tylko dla kontenerów windowsowych…

      Ale absolutnie się zgadzam, jak można i da się, docker będzie najszybszym sposobem zrobienia tego.

    • jak napisałem, głównie dlatego, że nie interesują mnie funkcje i produkty microsoftowe. siedzę w nich cały czas, mam ich powoli dość :) Do tego firma w której pracuje nie chce mieć nic w azure. Ma ku temu pewne przesłanki. Do tego, nie wszystkie projekty u nas są na IIS i w .NET – mamy skrypty, aplikacje consolowe, usługi, php itp itd. To też wpływa na dobór możliwych technologii. A w przykładzie koncentruje się na logach IIS gdyż… większość devów .NETowych ma IIS :) Celem raczej w hack day było udowodnienie, że mogę mieć różne formaty plików, różne źródła i różne raporty. Akurat tak się zdarzyło, że wszystko było .NETowe :)

      zaś co do złych doświadczeń, nie miałem, bo z Azure App Insights intencjonalnie jeszcze nie korzystałem.

  3. Elastic daje radę, podobnie jak cały elk-stack. Aczkolwiek jest kilka ale.
    Pierwszy z brzegu to próba wcielenia tego w model SAAS, niestety elasticsearch nie wspiera, żadnego z wzorców pod “multi-tenant”.
    Sami twórcy sugerują używanie wtedy unikalnych kluczy na poziomie indeksu, co niestety kuleje jak masz “głośne” indeksy “sąsiednie”.
    Napewno warto poćwiczyć umiejetności w temacie, dużo pracy ciekawej.

  4. Próbowałem to kiedyś zestawić ręcznie i poległem. ElasticSeach wraz z Kibaną można jednak zainstalować kilkoma kliknięciami również z Bitnami Stacks ;) Nie trzeba się bawić z Dockerem.
    Czekam na kolejne części ;) Domyślam się, że wspomnisz również o Serilog’u
    Pozdro

    • Super, mam nadzieję, że kolejne posty będą Cię tak samo interesować!

      Co do serilogu, nie, nie chciałem o tym wspominać. Jakiś konkretny powód dlaczego miałbym o nim wspomnieć nie licząc tego, że on pisze bezpośrednio do ES? Czy głównie o to chodziło? jak tak to nie jest to zły pomysł by w ogóle to opisać jakoś. Nie korzystałem z tego zaś w żadnym komercyjnym projekcie więc ciężko jest coś od siebie rozsądnego napisać. Ale na pewno warto to tym wspomnieć! może w podsumowaniu?

  5. Tak, właśnie dlatego, że pisze bezpośrednio do ES ;) Niby nie ma o czym pisać, bo wystarczy wskazać adres ES, ale jak dobrze skonfigurować i wykorzystać loggera, żeby później można było szybko przeanalizować zebrane dane to wg mnie już nie takie proste.
    Sam myślę o zastosowaniu takiego połączenia Serilog -> ElasticSearch->Kibana w dużym projekcie, aczkolwiek jakoś przeraża konfiguracja indeksu i Kibany dla wielu źródeł danych ( kilkanaście aplikacji w różnych technologiach w architekturze SOA)

    Szkoda, że nie zauważyłem posta wcześniej bo seria się już skończyła :(

    • My mamy nlog, nawet całkiem z unifikowany i łatwo jest rozróżnić aplikację. Wiec Dashboard per app działa u nas całkiem nieźle oraz Dashboard na wszystkie błędy :) ale da się łatwo all rozdzielić przez dobrze zaplanowany plik logu

      • Konfiguracja takiego rozwiązania rozumiem, że jest wtedy po stronie loggera każdej aplikacji i składanego przez niego tekstu wpisu ?
        Coś w stylu “APP1 DEBUG Komunikat” ,”APP2 INFO Komunikat” itp? Czy coś więcej ?
        A wykorzystujecie to do śledzenia komunikatów pomiędzy aplikacjami czy tylko zbierania logów z każdej z osobna ?

Comments are closed.