Dotychczas ćwiczyliśmy podstawowe funkcje wizualizacyjne Kibany. Jeśli chodzi o wizualizacje, jesteś już omnibusem (no, prawie). Ale umiejętność robienia cegieł to jest nic w porównaniu do umiejętności zbudowania muru, a może nawet domu. Tak też dzisiaj zajmiemy się wykorzystaniem posiadanych już umiejętności do zbudowania pierwszego dashboardu. A stąd już bardzo blisko do zbudowania pierwszej aplikacji do analizy twoich danych. Swoją drogą, konia z rzędem temu, kto zaproponuje trafne tłumaczenie tego terminu na polski. Tablica, pulpit, licho wie, co jeszcze…
Żeby stworzyć nowy dashboard, przejdź do sekcji Dashboard i kliknij Add. Niezwykle odkrywcze, prawda?
Dalej wykorzystamy wcześniej zapisane wizualizacje, tj. Log_count, Country_count, CountryWithResponse_count i GeoMap_count.
Trzeba kliknąć każdą z nich, a następnie poukładać na ekranie, np. tak, jak na poniższym obrazku.
Każdy z widgetów ma kilka kontrolek w prawym górnym rogu (edycja, przenoszenie, usuwanie) i jedną w prawym dolny rogu (zmiana rozmiaru). Wydaje się gotowe, ale wszystko wygląda mocniej na ciemnym tle, więc leć do menu Options (na górze ekranu) i włącz Dark theme.
Taki dashboard zapisz pod nazwą Apache_Log.
Możesz sprawdzić, że został zapisany klikając menu Open.
To w zasadzie koniec podstaw ELK. Przeszliśmy razem wszystkie etapy od instalacji przez konfiguracje, przetwarzanie danych z różnych źródeł do ich wizualizacji w formie dashboardu. Wydawałoby się, że nie ma o czym już więcej pisać, ale jest jedna rzecz, która zwróciła być może i twoją uwagę. Prawdziwy omnibus – tak sądzi większość – wszystko o wszystkim wie. Może niekoniecznie jest we wszystkim ekspertem, ale się orientuje. Ja się zorientowałem w czasie tego cyklu, że Logstash popełnił pewne wykroczenie na danych z logów Apache. Jeśli przejrzysz dane w indeksie, zobaczysz, że Logstash wczytał bytes
jako pole typu string
. A przecież bytes
to wielkość strony wyrażona w bajtach, więc to pole powinno być typu integer
! Jak to naprawić? Nie da się, ponieważ raz stworzony indeks przy wczytywaniu danych z Logstasha nie pozwala na zmianę typu pola. Ale nie ma sytuacji bez wyjścia, bo jeśli ciągle dysponujesz logami wygenerowanymi przez Fake Log Generator, to zrobimy nowy indeks na bazie tych logów, ale tym razem z właściwą konfiguracją.
1. Najpierw usuniemy stare indeksy z Elastisearcha. W konsoli Kibany (sekcja Dev Tools) wpisujesz i uruchamiasz polecenie:
DELETE /logstash-apache-*
2. Możesz sprawdzić, że wszystkie pasujące do wzorca indeksy zostały usunięte poleceniem:
GET /_cat/indices?v
Nie powinno być żadnych indeksów pasujących do wzorca logstash-apache-*
.
3. Usuń wzorzec indeksu z Kibany.
4. Zatrzymaj Logstasha, tak dla świętego spokoju, bo będziemy zmieniać jego konfigurację. Otwórz apache-config.conf i zmień zawartość sekcji mutate tak, żeby była zgodna z poniższą:<br>mutate {<br>convert => {<br>"[geoip][coordinates]" => "float"<br>"bytes" => "integer"<br>}<br>}<br>
5. Zapisz plik konfiguracyjny i ponownie uruchom Logstasha:
./logstash -f apache-config.conf
Czasami Logstash zachowuje się jak cwaniak albo uparty osioł i z jakichś powodów nie chce wczytać danych z logów, które już wcześniej widział. Ponieważ to tylko testowe dane, to najprostszą metodą jest usunąć pierwszy wpis z każdego wygenerowanego logu i zapisać go na dysku. Logstash rozpozna zmianę i wczyta zmienione logi do nowo stworzonego indeksu.
6. Wprowadź na nowo wzorzec indeksu w sekcji Management i po stworzeniu wzorca wyszukaj pola bytes
w indeksie.
Tadam! Bajty zostały skonwertowane ze string na numer i o to nam chodziło.
A teraz już ze spokojnym sumieniem możesz się udać na zasłużony odpoczynek, choć nie na długo, bo niebawem następna seria ciekawostek o stosie ELK. Stay tuned.