Przez ostatnie trzy tygodnie piszę posty dot. prostego POC w oparciu o produkty elastic – Logstash, Elasticsearch i teraz Kibana. Jest to też ostatni post w tej serii, a więc zabierajmy się do roboty.

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

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

Zanim zaczniemy

Zanim zaczniemy opis konfiguracji i zabawy z Kibana, wykonajmy ostatnie korki z poprzednich postów:

  • odpalenie Elasticsearch
  • odpalenie Logstash

W tym celu może się przydać ConEmu. Polecam z miejsca otworzyć trzy zakładki i na każdym z narzędzi działać na oddzielnej zakładce.  W pierszej, odpalmy elasticsearch – głównie dlatego, że to właśnie tam logstash będzie wrzucał przetworzone logi! :)

$ elasticsearch-service start
The service 'elasticsearch-service-x64' has been started

No chyba, że korszytacie z elasticsearch nie jako serwisu to wtedy:

$ elasticsearch

W drugiej odpalamy logstash:

$ logstash -f logstash.conf

Powinno to wygenerować masę tekstu na ekranie w tym coś co zacznie przypominać eventy – strukturowo i wyglądowo. To dobrze, to znaczy, że nasze logi są przetwarzane i generują wpisy do elasticsearch!

Jeżeli wszystko śmiga i nic nie wywaliło błędu, to przechodzimy do trzeciej zakładki w której będziemy odpalać Kibane.

Co to jest Kibana?

Kibana różni się od poprzednich narzędzi tym, że nie jest to konsolowa/usługowa aplikacja która wykonuje coś w tle. Ale narzędzie/aplikacja webowa, która umożliwia generowane wykresów, przeglądanie i analizowanie danych przechowywanych w elastisearch.

Jest to narzędzie graficzne, które wymaga od nas jedej bardzo ważnej rzeczy: musimy wiedzieć co chcemy z logów wyciągnąć. Co nas interesuje i dlaczego to.

Konfiguracja Kibana

Tutaj za bardzo nie mamy pola do popisu, większość rzeczy będziemy wyklikiwać z UI, jednak jedną rzecz można sprawdzić. W katalogu d:\mon\kibana\config znajdziecie plik kibana.yml a w nim parametr: elasticsearch.url. Jeżeli z jakiś powodów elasticsearch nie działau nas na domyślnym porcie to tutaj możemy to zmienić. Pamiętajcie, że wtedy też pewnie konfiguracja logstash będzie musiała być zaktualizowana.

Kibana.yml to przy okazji miejsce w którym możemy dokonywać konfiguracji kibany – nie wszystkiego.  Ale na przykład danych wymaganych do elastisearch by się zalogować, portu na jakim będzie kibana działała, adresu url itp. Reszta rzeczy jest do konfigurowania z poziomu UI.

Uruchomienie

Odpalenie Kibany jest proste, w tym celu w naszej trzeciej zakładce musimy wykonać polecenie:

$ kibana

To spowoduje wygenerowanie mniej więcej takiego o to logu:

  log   [15:28:41.778] [info][status][plugin:[email protected]] Status changed from uninitialized to green - Ready
  log   [15:28:41.827] [info][status][plugin:[email protected]] Status changed from uninitialized to yellow - Waiting for Elasticsearch
  log   [15:28:41.852] [info][status][plugin:[email protected]] Status changed from uninitialized to green - Ready
  log   [15:28:42.289] [info][status][plugin:[email protected]] Status changed from uninitialized to green - Ready
  log   [15:28:42.296] [info][listening] Server running at http://localhost:5601
  log   [15:28:42.298] [info][status][ui settings] Status changed from uninitialized to yellow - Elasticsearch plugin is yellow
  log   [15:28:47.301] [info][status][plugin:[email protected]] Status changed from yellow to yellow - No existing Kibana index found
  log   [15:28:47.602] [info][status][plugin:[email protected]] Status changed from yellow to green - Kibana index ready
  log   [15:28:47.603] [info][status][ui settings] Status changed from yellow to green - Ready

A z niego dowiemy się, że nasza kibana działa pod adresem localhost:5601.

Interfejs webowy

Kilka rzeczy się zmieniło w UI, więc jak widzieliście jakieś dema i fajne czarne kolorki to… trudno nowa wersja tak już ma i tyle – choć o czarnych kolorkach jeszcze wspomnę.

Zaraz po uruchomieniu strony powinniśmy zostać poproszeni o stworzenie indexu na bazie którego kibana będzie przeszukiwała i agregowała dane. Dla naszym potrzeb wystarczy wybrać wartości domyślne (w ostatnim polu Time-filed name zaznaczyć @timestamp)

Kibana - setting index
Kibana – setting index

To spowoduje zainicjonowane budowania indeksu. Teraz w zależności od danych, komputera, dysku twardego możemy na chwilę odejść i wrócić po po 3-4 minutach (idealnie by wziąć kawę). Od teraz nasz indeks został zbudowany a my możemy przeglądać zgromadzone dane. Zalecam jednak zanim to zrobimy, wykonanie kilkunastu requestów do naszego serwera IIS – z kilku przeglądarek najlepiej. Dlaczego? A no, domyślnie wszystko w kibanie działa w przedziale czasu 15 minut. To można zmienić. Robi się to w prawym górnym rogu ekranu:

Kibana - time rage settings
Kibana – time rage settings

Ale to też jest powodem wielu zmartwień i pytań czemu nasze wykresy nic nie pokazują. Często jest to wina filtru czasowego :) warto więc o nim pamiętać, w szzególności, że nasze operacje na UI mogą ten fitr zmieniać, zawężać itp.

Nasz cały UI opiera się 6 opcji po lewej stronie i opcji konfiguracyjnych na górze po prawej stronie. Dokładnie mówiąc, lewe menu zmienia funkcje, górne prawe, zarządza widokiem.

Discover

Kibana - discover
Kibana – discover

Discover umożliwia nam przeglądanie zdarzeń, ich filtrowanie, szlifowanie itp. Każdy taki event można podejrzeć w formie tabelki lub JSON, poniżej zaś z powodów estetycznych załączam jak to wygląda w formie jsonowej:

Event:
{
  "_index": "logstash-2017.02.03",
  "_type": "IISLog",
  "_id": "AVoEm-dI0BK-GZi-2RU8",
  "_score": null,
  "_source": {
    "referer": "-",
    "useragent": "Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/56.0.2924.76+Safari/537.36",
    "browser_os_name": "Windows",
    "type": "IISLog",
    "path": "C:/inetpub/logs/LogFiles/W3SVC1/u_ex170203.log",
    "browser_patch": "2924",
    "timetaken": "1",
    "browser_major": "56",
    "clientip": "::1",
    "@version": "1",
    "host": "Gutek-PC",
    "serverip": "::1",
    "browser_os": "Windows",
    "method": "GET",
    "substatus": "0",
    "browser_minor": "0",
    "querystring": "-",
    "message": "2017-02-03 15:33:18 ::1 GET /index1.html - 80 - ::1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/56.0.2924.76+Safari/537.36 - 304 0 0 1\r",
    "browser_name": "Chrome",
    "@timestamp": "2017-02-03T15:33:18.000Z",
    "port": "80",
    "browser_device": "Other",
    "page": "/index1.html",
    "username": "-",
    "status": "304",
    "scstatus": "0"
  },
  "fields": {
    "@timestamp": [
      1486135998000
    ]
  },
  "sort": [
    1486135998000
  ]
}

Dodatkowo za pomocą słów po lewej stronie, możemy przefiltrować listę zdarzeń po prawej. Może to się okazać przydatne przy wstępnej analizie danych – czy dobrze rześmy wszystko przetworzyli, czy mamy te dane, które nas interesują itp.

Kibana - filtering discover
Kibana – filtering discover

Visualize

Kibana - Visualize
Kibana – Visualize

Tu tutaj, tworzymy, przeglądamy, filtrujemy, bawimy się itp. wykresami. Jeżeli wiemy co i jak chcemy przedstawić, to pozostała nam jedynie kwestia tego wyklikania i skonfigurowania.

Dla przykładu, z naszymi plikami logów, możemy stworzyć sobie pie chart wyświetlający przeglądarki z których ludzie do nas wchodzili:

Kibana - Visualize - Pie Chart
Kibana – Visualize – Pie Chart

Albo wykres słupkowy pokazujący liczbę reuqestw w danym przedziale czasu i jakie są proporcje http status codes dla requestów.

To co jest tutaj ważne to, to, że każdy z takich wykresów jesteśmy wstanie zapisać (górne menu Save). Możemy tez załadować już istniejący i go edytować. Takie klocki wykresów są nam potrzebne w celu stworzenia dashboard.

Kibana - Open Graph
Kibana – Open Graph

Będąc w tym punkcie warto jeszcze wspomnieć, że jak klikniemy na wykres, to możemy przypadkowo włączyć filtrowanie po danej wartości. Czyli dal przeglądarek możemy ustawić filtr by tylko pokazywał przeglądarkę chrome. Co powoduje, że cały wykres jest do niczego nam potrzebny. Skoro tylko chrom będziemy pokazywać :)

Dashboard

Kibana - Dashboard Light
Kibana – Dashboard Light

To właśnie tutaj tworzymy tak zwane nasze centrum dowodzenia. Zbieramy nasze zapisane wizualizacje danych i ustawiamy je tak jak chcemy.

Kibana - Add visualization to dashboard
Kibana – Add visualization to dashboard

Zapisujemy i potem możemy to odtwarzać. Dla przykładu inny widok mogą mieć dev a inny devops.

Kibana - Dahsboards
Kibana – Dahsboards

Także tutaj możemy mieć zarówno jasne jak i ciemne tło (patrz Management).

Kibana - Dashboard Dark
Kibana – Dashboard Dark

Więcej magii tutaj nie ma. Jak wiemy co chcemy pokazać, jakie dane są nam potrzebne to tutaj możemy zrobić sobie nasz mały świat numerków i diagramów.

Jak nie mamy zielonego pojęcia co nas interesuje… to raczej nic fajnego tutaj nie wyklikamy.

Timelion

Kibana - Timelion
Kibana – Timelion

Nie miałem okazji się tym bawić, ogólnie umożliwia on wizualizację zupełnie niezależnych źródeł danych w czasie. Dla przykład jak się różniła liczba requestów w tym tym tygodniu od zeszłego tygodnia? Albo ile stron ogląda jeden unikatowy użytkownik w przedziale czasu.

Jak wiemy co chcemy z danymi zrobić, to może to być bardzo potężne narzędzie.

Dev tools

Kibana - Dev Tools
Kibana – Dev Tools

Ekran do zabawy z elasticserach – możemy tutaj dodawać nowe dokumenty, przeszukiwać istniejące itp. Oprócz zabawy raczej nie wiem po co to może być potrzebne. W sensie na pewno jest, ale dla moich celów nie było to w ogóle potrzebne.

Management

Kibana - Management
Kibana – Management

Tutaj możemy zarządzać indeksami jak i ustawieniami graficznymi. Dla przykładu w advance settings możemy zmienić dashboard na to by używał dark theme:

Kibana - Dark Theme setting
Kibana – Dark Theme setting

Do tego możemy zarządzać wszystkimi zapisanymi elementami (wizualizacjami, dahsboardami, wyszukiwaniami, timelionami) – w tym eksportowaniem i ich importowaniem.

Podsumowanie

To tyle, tak naprawdę to nie było trudne. Bardzo prosto dało się wszystko zestawić w jedną całość. Jedyny problem to konfiguracja logstash oraz wiedza co chcemy z tymi danymi zrobić.

W serii pokazałem, że logstash (narzędzie do zbierania logów) służy do filtrowania i mapowania danych z jednego źródła na inne źródło wyjściowe. Wszystko tyczy się w około tego jak dobrze posługujemy się plikem logstash.conf i gork.

Elasticserach zaś jest bezobsługowy, wystarczy go odpalić i będzie śmigał (w prostej wersji, w innych na pewno warto go zabezpieczyć i dobrze dokonfigurować). Po odpaleniu elasticsearch gromadzi dane które są dostępne za pomocą REST API.

Na końcu (dzisiaj), kibana, narzędzie umożliwiające nam wizualizację danych zebranych przez logstash i zapisanych w elastisearch. Podobnie jak elasticsearch, kibana nie wymaga za bardzo konfiguracji – jednak potem już

Mnie zastanawia to w jakis sposób to się sprwadzi w większym i bardziej skomplikowanym środowisku, z wieloma źródłami danych – tak bardziej ciekawi, czy wszystko pójdzie prosto i fajnie czy jednak będą z tym jakieś pomniejsze kłopoty :) ktoś coś? :)

2 KOMENTARZE

  1. Miałem do czynienia z ELK postawioną na AWS dla wielu produkcyjnych środowisk, gdzie logi to kilkaset gigabajtów dziennie. Wiele zależy od maszyny, na którym to jest postawione.
    Przeszukiwanie w kibanie było w miarę responsywne. Jedyne co mi przeszkadzało, to w sumie niemożliwość przeglądania logów bez filtrów, ani przeszukiwania. Trzeba zawsze było zaczynać od id wątku, albo request_id. Jak proces nie miał tego zaimplementowane, albo nie logował – konia z rzędem temu, kto z powodzeniem będzie analizował logi. Nie licząc tego jednego problemu – po zapoznaniu się z kibaną – filtrami i ich zastosowaniami – analiza była już tylko przyjemnością.

  2. Hej,
    czy orientujesz się czy w Kibanie jest możliwość hierarchizowania alarmów?
    Tak, aby otrzymać:

    1. wizualizację dotyczącą alarmu nadrzędnego – jeżeli spojrzę na listę alarmów, to pozostałe podrzędne alarmy też zobaczę na czerwono, ale chcę, aby system powiadomił mnie treścią alarmu nadrzędnego. Czyli: wyzwalaj alarm gdy nastąpi dane zdarzenie i nie występuje N-zdarzeń nadrzędnych;
    2. konfigurację zwłoki – ponieważ alarmy podrzędne mogą pojawić się przed alarmem nadrzędnym.

Comments are closed.