Elastic - przykładowe wdrożenie i integracja z Kibana
Logi aplikacji, różnych usług, czy też samego systemu operacyjnego są podstawowym i absolutnie kluczowym źródłem pozwalającym na weryfikację działania danego komponentu. Dzięki logom możemy wykryć różne anomalie (takie jak spadki wydajności, błędy w logice aplikacji, jak również ewentualne ślady złośliwej aktywności) i przyczyny zgłoszonych np. przez klienta problemów. Obecnie dostępne są odpowiednie rozwiązania (często bardzo kosztowne, ale jednocześnie skuteczne), które automatycznie są w stanie wykryć różne problemy (w tym te powiązane z bezpieczeństwem) z naszymi usługami i raportować o nich poprzez powiadomienia czy komunikaty na czytelnych panelach. Nie oznacza to oczywiście, że logi stają się reliktem przeszłości.
Logi w zdecydowanej większości przypadków zapisywane są do plików tekstowych (zwykle z rozszerzeniem .log) przechowywanych lokalnie na serwerze hostującym daną usługę. Dzięki temu dostęp do samych logów nie powinien być wyzwaniem dla osób odpowiadających za utrzymanie systemu. Ważne jest również zadbanie o sensowną rotację (usuwanie/archiwizowanie starszych wpisów), aby nie nastąpiła sytuacja wykorzystania całej przestrzeni dyskowej na logi. W tym celu stosuje się m.in. narzędzie logrotate.
W praktyce analiza logów niestety kojarzy się raczej negatywnie. Dla rozbudowanych aplikacji, które niejednokrotnie są uruchomione na kilku serwerach w ramach klastra, odnalezienie wpisu powiązane z konkretnym problemem jest zwyczajnie utrudnione. Zresztą bez znajomości składni narzędzi typu grep czy awk nawet przeszukanie jednego pliku może być skomplikowane, a nie zawsze do otwarcia logu można wykorzystać edytory tekstu, bo plik może zajmować kilkadziesiąt gigabajtów. Już nie wspominając o sytuacjach, gdzie aplikacja uruchomiona jest na zewnętrznym środowisku, do którego dostęp SSH jest znacznie ograniczony – prośby do administratorów po stronie klienta o przeszukanie czy udostępnienie logów są wtedy uzasadnione, ale mało komfortowe dla obu stron.
Elastic Stack
Rozwiązanie tych problemów stanowi Elastic Stack (poprzednio określany jako ELK stack i ta nazwa jest bardziej rozpowszechniona). Współcześnie to niemal standardowe narzędzie do agregacji logów w każdym większym środowisku i z tego powodu warto posiadać odpowiednią wiedzę o dostępnych w nim funkcjach i sposobach konfiguracji.
Uruchomiona instancja Elastic Stack powinna stać centralnym miejscem agregacji logów pochodzących z różnych usług i aplikacji. Dzięki odpowiednim regułom opartym na rolach (dostęp do indeksów i zarządzania Elasticsearch) można zapewnić uprawnienia dla różnych działów czy zespołów projektowych – aby odczyt logów danego projektu mogły wykonać wyłącznie wskazane osoby.
Elastic Stack składa się z trzech komponentów: Elasticsearch, Logstash i Kibana. Nietrudno zauważyć, że pierwsze litery tych nazw złożyły się w określenie ELK. Ich zastosowanie można bardzo łatwo określić i zapamiętać.
Elasticsearch jest rodzajem bazy danych, w której dane przechowywane są w formacie JSON. Umożliwia tzw. wyszukiwanie pełnotekstowe i z tego powodu znalazł szerokie zastosowanie w różnych aplikacjach, często powiązanych z e-commerce – nie jest to narzędzie przeznaczone wyłącznie do „obsługi” logów. Do obsługi Elasticsearch (operacje na danych, administracja instancją) wykorzystywany jest standardowy protokół HTTP, co znacznie ułatwia przeprowadzenie różnych integracji. W ostatnim czasie wprowadzono szereg zabezpieczeń (X-Pack), które zresztą są domyślnie włączone.
Logstash umożliwia „dostosowane” logów do formatu przyjaznego dla człowieka, jak również bardziej zgodnego z zastosowaniem JSON. Konfiguracja odpowiednich reguł bywa problematyczna i zwykle wymaga wielu testów, bo nie każda aplikacja zapisuje logi w sensowny sposób.
Kibana z kolei stanowi graficzny interfejs do prezentowania danych zgromadzonych w Elasticsearch, ale pozwala też na całkiem wygodną administrację tą usługą.
Oprócz tego wymienić należy Filebeat, który odpowiada za przekazywanie logów do Logstash bądź też bezpośrednio do Elasticsearch – to jednak nie jest najlepsza opcja i zdecydowanie warto zachować porządek poprzez zastosowanie Logstash.
Elasticsearch można uruchomić w ramach natywnego klastra, co w dość łatwy sposób pozwoli na zachowanie high availability (przy założeniu wykorzystania trzech serwerów; sam klaster zadziała przy połączeniu dwóch maszyn). Kibana i Logstash nie posiadają żadnych wewnętrznych zależności. Konfiguracja Kibana przechowywana jest w samym Elaticsearch oraz na serwerach, więc wystarczy zastosować prosty load balacing. Logstash można uruchomić na dowolnej ilości serwerów – odpowiada wyłącznie za „modyfikację” zawartości i przesłanie jej do Elasticsearch.
Kibana raczej nie powinna być dostępna bezpośrednio. Warto uruchomić podstawowe reverse proxy przykładowo z użyciem nginx. Pozwoli to m.in. na zastosowanie własnej domeny i prawidłową obsługę protokołu HTTPS.
Co bardzo ważne, wszystkie wymienione rozwiązania zadziałają zarówno w systemach Linux, jak i Windows czy macOS. Proces instalacji jest oczywiście odmienny, natomiast konfiguracja w każdym przypadku będzie analogiczna.
Elasticseach wymaga minimum 8 GB pamięci operacyjnej, przy czym zalecane jest 16 GB. Do przechowywania danych najlepiej wykorzystać osobny dysk (lub kilka dysków połączonych LVM). W przypadku Linux’a dysk wystarczy zamontować w katalogu /var/lib/elasticsearch. „Minimalny” rozmiar storage to 10 GB. Elasticsearch powinien uruchomić się prawidłowo na instancji nie spełniającej tego wymogu, natomiast nie powinniśmy szukać oszczędności akurat w zasobach dyskowych.
Zostanie zaprezentowana konfiguracja pojedynczej instancji Elastic Stack agregującej logi serwera Apache hostującego przykładową witrynę WordPress. Korzystam z systemu Rocky Linux, co jednak nie ogranicza przygotowanego opisu do jednej grupy dystrybucji Linuxa – z powodzeniem te same kroki (z wyjątkiem procesu instalacji paczek) będą mogły zostać zastosowane w systemach opartych na Debian. SELinux został wyłączony.
Elasticsearch
Paczkę zawierającą Elasticsearch pobierzemy ze strony https://www.elastic.co/downloads/elasticsearch. Jako platformę wybieramy Linux x86_64. Obecnie najnowsza wersja Elastic Stack to 9.2.3. Same wydania są dość częste, bo w 2025 roku pojawiło się aż pięć wersji.
Wykonujemy instalację.
sudo dnf install ./elasticsearch-9.2.3-x86_64.rpm
Następnie trzeba dostosować dwie opcje w pliku /etc/elasticsearch/elasticsearch.yml:
- network.host: 0.0.0.0 (nie jest to konieczne do samego zbierania logów, bo Logstash będzie na tej samej maszynie, natomiast przeprowadzimy jeszcze integrację z WordPress)
- xpack.security.http.ssl -> enabled: false (Elasticsearch nie jest dostępny w sieci publicznej, więc nie ma rzeczywistego powodu do korzystania z HTTPS i „utrudniania” konfiguracji – HTTPS jest jednak wymagany w przypadku konfiguracji klastra)
Należy jeszcze zablokować możliwość korzystania ze swap (pamięci wymiany w systemach Linux). Jeśli na serwerze swap nie jest aktywny, to te kroki można pominąć. Do modyfikacji są pliki /usr/lib/systemd/system/elasticsearch.service (w sekcji Service dopisujemy LimitMEMLOCK=infinity) i /etc/sysconfig/elasticsearch (dopisujemy MAX_LOCKED_MEMORY=unlimited).
Przeładowujemy daemon systemd (ponieważ edytowaliśmy plik usługi – elasticsearch.service), aktywujemy i uruchamiamy usługę Elasticsearch.
sudo systemctl daemon-reload
sudo systemctl enable elasticsearch
sudo systemctl start elasticsearch
Elasticsearch domyślnie działa na portach 9200 i 9300, które należy odblokować na poziomie zapory sieciowej, jeśli jest aktywna w naszym systemie.
sudo firewall-cmd --permanent --add-port=9200/tcp
sudo firewall-cmd --permanent --add-port=9300/tcp
sudo firewall-cmd --reload
Można teraz wysłać proste zapytanie GET, aby zweryfikować działanie usługi.
Jak widać, została zwrócona odpowiedź 401, co oznacza, że wymagana jest autoryzacja. Jest to związane z działaniem wspomnianego X-Pack – jeszcze kilka lat temu Elasticsearch domyślnie nie wymagał autoryzacji. Wystarczyło uruchomić usługę, aby każdy zainteresowany (przy założeniu działającego dostępu sieciowego) miał możliwość jej odpytania.
Usługa działa i jest możliwa komunikacja, więc można zresetować hasło dla użytkownika administracyjnego elastic i użytkownika służącego do wdrożenia Kibana. Jako parametr URL podajemy adres, na którym nasłuchuje Elasticsearch.
sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password --url http://192.168.1.155:9200 -i -u elastic
sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password --url http://192.168.1.155:9200 -i -u kibana_system
Konfigurację Elasticsearch na ten moment można uznać za zakończoną i przejść do instalacji i uruchomienia Kibana.
Kibana
Adresy paczek RPM/DEB z wszystkimi komponentami Elastic Stack są tworzone według tego przykładu:
https://artifacts.elastic.co/downloads/kibana/kibana-9.2.3-x86_64.rpm
Nie trzeba więc sprawdzać za każdym razem odnośnika na stronie pobierania. Ta wiedza przyda się, jeśli przykładowo zamierzamy zautomatyzować (np. za pomocą Ansible) wdrożenia Elastic Stack.
Instalacja Kibana jest analogiczna – pobieramy paczkę i poleceniem dnf install dokonujemy instalacji w systemie. Kluczowe zmiany pozostają do wprowadzenia w pliku /etc/kibana/kibana.yml:
- server.publicBaseUrl: https://logs.avlab.pl (adres, na którym będzie dostępna Kibana)
- elasticsearch.hosts: [„http://192.168.1.155:9200”] (ponownie – jeśli Elasticsearch działa na adresie 127.0.0.1, to nie zmieniamy tej opcji)
- elasticsearch.password: „XXX” (hasło ustawione wcześniej poleceniem elasticsearch-reset-password)
Aktywujemy i uruchamiamy usługę.
sudo systemctl enable kibana
sudo systemctl start kibana
Jak opisano wyżej, warto uruchomić reverse proxy dla Kibana. Tutaj skorzystamy z najszybszej możliwości, czyli serwera nginx. Konfiguracja jest całkiem typowa dla reverse proxy i może wyglądać jak poniżej. Trzeba pamiętać o odblokowaniu dostępu do wykorzystywanych przez nginx portów – u nas domyślne, czyli 80 (przekierowanie na „wersję” HTTPS) i 443.
server {
listen 80;
server_name logs.avlab.local;
error_log /var/log/nginx/kibana.error.log error;
access_log /var/log/nginx/kibana.access.log;
if ($scheme != "https") { rewrite ^ https://$host$uri permanent; }
}
server {
listen 443 ssl;
server_name logs.avlab.local;
error_log /var/log/nginx/kibana.error.log error;
access_log /var/log/nginx/kibana.access.log;
ssl_certificate /ssl/kibana.crt;
ssl_certificate_key /ssl/kibana.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ecdh_curve X25519:prime256v1:secp384r1;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;
location / {
proxy_pass http://127.0.0.1:5601;
proxy_read_timeout 7200;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
}
Jeśli wszystko zostało poprawnie ustawione, to po wejściu na adres wskazany w konfiguracji zobaczymy poniższą stronę logowania.
Logujemy się z użyciem poświadczeń dla użytkownika elastic. Po udanym zalogowaniu od razy wybieramy Explore on my own przy komunikacie zachęcającym do dodania integracji. Interfejs Kibana mniej doświadczonym osobom może wydać się skomplikowany i niezbyt uporządkowany, ale w dalszej części pokażę, w jaki sposób można osiągnąć lepszą przejrzystość.
Monitoring Elasticsearch
Większe znaczenie niż eleganckie GUI ma jednak monitoring Elastic Stack. W zależności od wykorzystywanych przez nas narzędzi można zastosować różne metody monitoringu. W naszym przypadku używany jest Zabbix, który posiada naprawdę świetny template Elasticsearch Cluster by HTTP. Wymagane jest dodanie trzech zmiennych (makr) do konfiguracji hosta.
Widocznego użytkownika zabbix dodamy po wejściu w ikonę trzech poziomych pasków i dalej Stack Management. Przechodzimy do zakładki Users i wybieramy przycisk Create user. Dane powinny być uzupełnione analogicznie do poniższego zrzutu ekranu.
Zmiany zapisujemy przyciskiem Create user. Można podejrzeć konfigurację tego użytkownika po odpytaniu endpointa _security/user/zabbix (używając poświadczeń użytkownika elastic).
Konfiguracja roli i użytkownika do tworzenia i zapisu indeksów
Teraz do wykonania jest kluczowa konfiguracja pozwalająca na bezpieczny i działający zapis danych – w naszym przypadku logów. Po przejściu do zakładki Roles i wybraniu Create user uzupełniany pola analogicznie do podanych ustawień:
- Role name: web_write (polecam zachowanie tego porządku – nazwa serwera/projektu_write – rola pozwalająca na dostęp do zapisu dla indeksów)
- Cluster privileges: manage_index_templates, monitor
- Index privileges: web-* – create_index, write
Wyjaśnienia wymaga podanie nazwy indeksu jako web-*. Istotna jest konfiguracja „rotacji” indeksów, aby uniknąć wiadomej sytuacji wyczerpania przestrzeni dyskowej, a do właściwego działania niezbędne jest posiadanie kilku indeksów powiązanych z jednym „projektem”. Odpowiednią regułę rotacji dodaje się do opcji danego indeksu (co zostało opisane w dalszej części. Uruchomienie (realizowane automatycznie przez silnik Elasticsearch) tej reguły bez indeksu możliwego do zastąpienia będzie działać (skasuje indeks i wraz z nim dane), a Logstash utworzy kolejny indeks, jednak bez dodanej reguły rotacji dane będą wtedy przyrastać w nieskończoność – bo nowy indeks nie będzie posiadał tej konfiguracji.
Rolę zapisujemy przyciskiem Create role.
Następnie przechodzimy do zakładki Users i wybieramy Create user celem utworzenia użytkownika powiązanego z dodaną właśnie rolą web_write. Tutaj raczej nie są potrzebne dodatkowe tłumaczenia poszczególnych pól formularza. Ponownie zalecam zastosowanie reguły nazewnictwa – nazwa serwera/projektu_writer.
Logstash
Można przystąpić do instalacji i konfiguracji Logstash. Paczka znajduje się pod adresem https://artifacts.elastic.co/downloads/logstash/logstash-9.2.3-x86_64.rpm.
Komunikacja do Logstash będzie szyfrowana, więc musimy wcześniej przygotować dowolny certyfikat SSL, także self-signed.
Najpierw w konfiguracji OpenSSL (dla systemów RHEL jest to plik /etc/pki/tls/openssl.cnf) dodajemy w sekcji [ v3_ca ] opcję subjectAltName o wartości adresu IP hosta, na którym działa Logstash.
subjectAltName = IP: 192.168.1.155
Generujemy certyfikat i klucz oraz ustawiamy właściciela na użytkownika powiązanego z Logstash.
sudo openssl req -config /etc/pki/tls/openssl.cnf -x509 -days 3650 -batch -nodes -newkey rsa:2048 -keyout /ssl/logstash.key -out /ssl/logstash.crt
sudo chown logstash: /ssl/logstash*
Tworzymy ogólną konfigurację „serwera” w katalogu /etc/logstash/conf.d. Plik polecam nazwać jako beats.conf.
input {
beats {
client_inactivity_timeout => 600
port => 5044
ssl_enabled => true
ssl_certificate => "/ssl/logstash.crt"
ssl_key => "/ssl/logstash.key"
}
}
W tym samym katalogu tworzymy kolejny plik zawierający ustawienia dla konkretnego zestawu logów. Zamierzamy agregować logi z serwera Apache, dla którego istnieje gotowy moduł Filebeat i dlatego widoczna konfiguracja w sekcji filter nie jest szczególnie skomplikowana. Jeśli jednak moduł dla naszej aplikacji nie jest dostępny (dotyczy to m.in. zbierania logów z kontenerów Docker – nie ma przecież jednego formatu), to niestety trzeba będzie poświęcić sporo czasu na przygotowanie odpowiedniej konfiguracji. Służą to tego przede wszystkim filtry grok.
Widoczna nazwa apache_web de facto zabezpiecza przed możliwością przesłania logów do niewłaściwego indeksu. O ile przy logicznych ustawieniach ról taki scenariusz nie jest bardzo prawdopodobny, to jednak warto wcześniej założyć, że w przyszłości nasza instancja może nie być ograniczona do jednego serwera, z którego zbieramy logi. Z kolei jako nazwę indeksu podajemy web-%{+yyyy.MM.dd}. Może to być dowolny inny ciąg znaków (chociaż ten wydaje się najbardziej racjonalny), natomiast należy zachować przedrostek web-, bo wcześniej konfigurowaliśmy rolę posiadającą możliwość tworzenia i zapisu do tych właśnie indeksów (web-*).
Sekcja output zawiera wyłącznie „instrukcję” połączenia z serwerem Elasticsearch.
filter {
if [fields][log_type] == "apache_web" {
grok {
match => { "message" => "%{COMBINEDAPACHELOG}" }
remove_field => "message"
}
date {
match => [ "timestamp" , "dd/MMM/yyyy:HH:mm:ss Z" ]
target => "@timestamp"
}
mutate {
add_field => { "[@metadata][index]" => "web-%{+yyyy.MM.dd}" }
}
}
}
output {
if [fields][log_type] == "apache_web" {
elasticsearch {
hosts => ["192.168.1.155:9200"]
index => "%{[@metadata][index]}"
user => "web_writer"
password => "XXX"
action => "create"
}
}
}
Aktywujemy i startujemy usługę.
sudo systemctl enable logstash
sudo systemctl start logstash
Jeśli korzystamy z zapory sieciowej, to do odblokowania pozostaje port 5044.
Filebeat
Ostatnia usługa do uruchomienia to oczywiście Filebeat. Paczka znajduje się pod adresem https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-9.2.3-x86_64.rpm. Instalację i konfigurację wykonujemy na serwerze, z którego będą zbierane logi. Przed przystąpieniem do pracy trzeba pamiętać o skopiowaniu pliku z certyfikatem Logstash – w naszym przypadku znajduje się on w katalogu /ssl.
W pliku /etc/filebeat/filebeat.yml wprowadzamy szereg zmian:
- filebeat.inputs -> enabled: true
- paths: /home/www/wp/logs/apache/*.log (ścieżka do plików zawierających logi)
- fields:
server_name: web
log_type: apache_web (można dopisać to bezpośrednio po linii z paths)
- zakomentowanie output.elasticsearch (w tej sekcji także opcje hosts i preset)
- odkomentowanie output.logstash, a w niej hosts i ssl.certificate_authorities
- dopisanie do output.logstash opcji bulk_max_size: 1024
Wykonując polecenie
sudo filebeat modules list
wyświetlimy listę dostępnych modułów. Wszystkie domyślnie są wyłączone. Nas interesuje apache i dlatego wykonujemy
sudo filebeat modules enable apache
Oprócz tego w pliku /etc/filebeat/modules.d/apache.yml zmieniamy opcje (występują dwa razy – dla access i error logów) enabled na wartość true.
Aktywujemy i startujemy usługę Filebeat.
sudo systemctl enable filebeat
sudo systemctl start filebeat
Podstawowe operacje w Elasticsearch
Odpytując endpoint /_cat/indices zobaczymy, że indeksy zostały pomyślnie utworzone, a nawet zawierają dane.
Możemy od razu sprawdzić zawartość indeksów web-* – endpoint /web-*/_search. Jak widać, jest to format JSON.
Jeśli monitorujemy naszą instancję, to po utworzeniu nowego indeksu możemy spodziewać się alertu podobnego do tego z systemu Zabbix.
To jest całkowicie typowe zachowanie silnika Elasticsearch, gdy nie działa w ramach klastra – a tutaj operujemy na instancji standalone. Rozwiązanie stanowi wysłanie żądania PUT do endpointa _settings o następującej zawartości:
{
"index" : {
"number_of_replicas" : 0
}
}
W odpowiedzi zostanie zwrócone
{"acknowledged":true}
I teraz „health” wszystkich indeksów powinien być ponownie jako „green”
Lifecycle policy i index template
Możemy rozpocząć tworzenie lifecycle policy, która zapewni odpowiednią rotację indeksu, a tym samym będzie stanowić podstawowe, ale jednocześnie absolutnie kluczowe zabezpieczenie przed zbyt dużym wykorzystaniem storage. Całą konfigurację można w łatwy sposób przeprowadzić w Kibana. Przechodzimy do zakładki Index Lifecycle Policies i poprzez Create policy otwieramy kreator. Uzupełniamy poszczególne pole w ten sposób:
- Policy name – nazwa tworzonej polityki, w naszym przykładzie siedem_dni
- Hot phase -> Delete data after this phase (należy kliknąć ikonę kosza)
Dalej po rozwinięciu sekcji Advanced settings w Hot phase:
- odznaczyć opcję Use recommended defaults
- odznaczyć opcję Enable rollover
Ostatecznie w Delete phase:
- Move data into phase when: 7 days
Zmiany dodajemy za pomocą przycisku Save policy. Oczywiście ilość dni, przez którą przechowujemy indeksy, może być dłuższa. Politykę do indeksu przypisujemy wchodząc w Index Management, wybierając interesujący nas indeks, a następnie rozwijając menu Manage index opcję Add lifecycle policy.
Wskazujemy utworzoną wcześniej politykę i zapisujemy zmiany.
Jak wspomniałem, lifecycle policy będzie już działać poprawnie, ale usunie indeks, a wraz z nim dodaną politykę – kolejny indeks (w tym przykładzie web-2025.12.24) będzie przyrastać w nieskończoność. Zamiast dodawać lifecycle policy każdego dnia, trzeba utworzyć template dla naszego indeksu, aby to i inne ustawienia były aplikowane automatycznie przy każdym utworzeniu indeksu web-*.
Wracamy więc do zakładki Index Management i wybieramy Index Templates. Klikamy Create template i uzupełniamy opcje z zgodnie z tą instrukcją:
- Name – siedem_dni_web (nazwa-polityki_nazwa-indeksu, może być inna dowolna)
- Index patterns – web-*
- odznaczona opcja Create data stream (data stream nie jest odpowiedni dla logów, potrzebujemy standardowego indeksu)
Następnie przechodzimy do „kroku” Index settings, gdzie w polu tekstowym wklejamy tę zawartość:
{
"index": {
"lifecycle": {
"name": "siedem_dni"
},
"number_of_replicas": "0",
"mode": "standard"
}
}
Pozostaje zapisać utworzoną template przyciskiem Create template w ostatnim dostępnym „kroku” Review template.
Spaces
Możliwe, że najlepszą metodą zachowania porządku w Kibana jest zastosowanie spaces. Po zalogowaniu użytkownik będzie miał wybór „przestrzeni”, do której chciałby uzyskać dostęp, aby sprawdzić logi itd. W zakładce Spaces wybieramy Create space i podajemy nazwę tworzonej przestrzeni – u nas będzie to Serwer WWW.
Powinniśmy też ograniczyć widoczność różnych funkcjonalności dostępnych w Kibana – wystarczy nam dostęp do logów zebranych w indeksach. Dlatego w sekcji Set feature visibility rozwijamy gałąź Analytics i pozostawiamy zaznaczenie wyłącznie przy Discover. Odznaczany też wszystkie pozostałe gałęzie, czyli Elasticsearch, Observability, Security i Management. W tej ostatniej zaznaczamy jednak Data View Management. Wyżej znajduje się też „nowość” w Kibana, czyli Select solution view – osobiście radzę wybrać ten po prostu Classic.
Można nawet ustawić grafikę lub awatar.
Trzeba dodatkowo utworzyć kolejną rolę (np. serwer_www_view), która będzie posiadać wyłącznie możliwość odczytu (read) indeksów web-*. Rolę musimy przypisać do utworzonego space. Przy okazji warto ograniczyć też dostęp do funkcji Kibana, aby faktycznie uzyskać intuicyjny interfejs dla użytkowników – pamiętajmy, że niekoniecznie musi to być osoba techniczna.
Wystarczy już tylko utworzyć użytkownika z przypisaną rolą serwer_www_view.
Jeśli wylogujemy i zalogujemy się ponownie (wciąż jako użytkownik elastic), to powinniśmy zobaczyć poniższy komunikat.
Tworzenie data view
Musimy skonfigurować data view, czyli widok logów, jaki zobaczą użytkownicy. Rozwijamy menu (trzy poziome kreski) i przechodzimy do Discover, dalej rozwijamy pozycję All logs i wybieramy Create a data view. Ustawienia powinny wyglądać zgodnie ze zrzutem ekranu.
Po zapisaniu zmian przyciskiem Save data view to Kibana prawdopodobnie zobaczymy ten widok:
Widać, że logi są poprawnie zbierane, ale sam widok nie jest czytelny. Dlatego też z listy Available fields należy wybrać (najechać kursorem i wybrać znak plus) pola, które będą dostarczać pewną wartość dla osoby analizującej logi. Na początek proponuję url.original, http.request.method i http.response.status_code. Można dostosować szerokość tych kolumn poprzez przeciągnięcie wiersza z nazwą danej kolumny.
Po zakończeniu modyfikacji wybieramy przycisk Save i jeszcze raz podajemy nazwę date view, po czym finalnie zapisujemy ustawienia.
Adres z widokiem będzie miał postać https://logs.avlab.local/s/serwer-www/app/discover#/view/192453fc-687d-4c7f-b943-24f5ead38197.
Profile użytkowników
Użytkownicy mogą edytować swoje profile. Trzeba przyznać, że ilość dostępnych do wprowadzenia zmian jest imponująca, tym bardziej, że Kibana to jednak narzędzie techniczne.
Użytkownicy z rolą serwer_www_view zobaczą tylko jedną pozycję w menu.
Po wybraniu Discover powinien zostać załadowany przygotowany wcześniej widok – jednak nie zawsze tak się dzieje i wtedy najlepiej skopiować podany wyżej link (adres będzie bezpośrednio po zapisaniu widoku).
Integracja WordPress z Elasticsearch
Pokażę również sposób integracji istniejącej witryny WordPress z Elasticsearch. Na początek musimy zainstalować wtyczkę ElasticPress.
Nasza instancja wymaga autoryzacji, dlatego edytujemy plik wp-config.php dodając te dwie opcje:
define( 'EP_HOST', 'http://192.168.1.155:9200/' );
define( 'ES_SHIELD', 'elastic:XXX' );
W środowiskach produkcyjnych należy unikać wykorzystania użytkownika elastic do takich integracji. Z poziomu Kokpitu wchodzimy do zakładki ElasticPress i zaznaczamy checkboxy przy zawartości, która powinna zostać zapisana w Elasticsearch.
Klikamy kolejno Zapisz funkcje i Indeksuj swoją treść.
Indeks został pomyślnie utworzony.
Na podstawie przekazanych informacji powinniśmy bez większych trudności utworzyć data view prezentujący dane z WordPress – bezpośrednio w space Serwer WWW jako użytkownik elastic.
Zakres danych można szybko zmienić poprzez gotowe wartości dostępne po wybraniu ikony kalendarza. Domyślnie są wyświetlane dane z ostatnich 15 minut.
Dodałem indeks wpavlabpl* do utworzonej wcześniej roli serwer_www_view.
Podsumowanie
Wdrożenie Elastic stack pomoże zapanować nad logami, szczególnie w przypadku złożonych środowisk. Nie będzie konieczności ręcznego wyszukiwania logów na serwerach, ponieważ te będą w jednym, centralnym miejscu. Znacznie ułatwi to pracę, a co za tym idzie, przyspieszy proces analizy błędów – korzyści biznesowe są oczywiste. Korzystanie z tego rozwiązania będzie również świadczyć o pewnej fachowości zespołów technicznych.
