# Laboratorium BiNSCh
## Niezawodność Elastic Stack
Celem laboratorium jest zapoznanie uczetników z rozwiązaniem Elastic Stack oraz oferowanymi przez niego metodami zapewniania niezawodności.
### Zadanie 0
Przed przystąpieniem do realizacji zadania laboratoryjnego dotyczącego Elastic Stack należy odpowiednio przygotować środowisko pracy. Przygotowany przez nas obraz maszyny wirtualnej możesz pobrać [tutaj](https://drive.google.com/file/d/1FlF4BtLPCglHdxbMXayNMlhFM7sY1rZT/view?usp=sharing). Maszyna wymaga *2vCPU, 4GB RAM oraz ~8GB przestrzeni dyskowej*. Maszyna posiada zainstalowany system operacyjny CentOS 8 wraz ze wszystkimi komponentami rozwiązania Elastic Stack.
**Login:** root
**Hasło:** studentkti
1. W pierwszej kolejności należy stworzyć sieć NAT Network. Należy w tym celu otworzyć menu **File -> Preferences (Ctrl+G)**, wybrać **Network**, a następnie stworzyć nową sieć.
2. Następnie należy zaimportować obraz przygotowanej maszyny wirtualnej ElasticStackVM: **Plik -> Importuj wirtualne urządzenie**.
**Uwaga!** W razie pojawienia się błędu "VBOX_E_FILE_ERROR", należy odznaczyć *”Import hard drives as VDI”* i spróbować ponownie.
3. Po zaimportowaniu maszyny, należy skonfigurować sieć. Udajemy się w tym celu do jej ustawień i sprawdzamy, czy w zakładce “Network” Adapter 1 ustawiony jest na stworzoną przez nas sieć typu NAT Network.
Maszyna posiada serwer SSH na porcie 22 (SSH). Możliwe jest wyprowadzenie portu 22 z maszyny wirtualnej na np. port 5022 lokalny - udając się do menu **File -> Preferences**, następnie **Network**, wybierając edycję stworzonej przez nas sieci, a następnie “**Port Forwarding**”.
4. Kolejnym krokiem jest sprawdzenie poprawności działania usług *Elasticsearch* oraz *Kibana*. Usługi *Logstash* oraz *Beats* powinny być zainstalowane, ale nie skonfigurowane.
*Elasticsearch:*
```
# systemctl status elasticsearch
Jeżeli usługa nie działa:
# systemctl start elasticsearch
# systemctl enable elasticsearch
```
*Kibana:*
```
# systemctl status kibana
Jeżeli usługa nie działa (Kibana nie uruchomi się bez działającego Elasticsearch):
# systemctl start kibana
# systemctl enable kibana
```
Jako, iż Kibana nasłuchuje tylko na localhost, przekierowujemy port przy użyciu usługi SSH.
##### Windows
Na systemach Windows można użyć w tym celu narzędzia PuTTY w zakładce **Connection -> SSH -> Tunnels**.
##### Unix
Na systemach Linux/itd. można użyć polecenia
```
ssh -L 5601:127.0.0.1:5601 root@127.0.0.1 -p <port ssh>
```
W naszym przypadku, będzie to `[wybrany port, raczej 5601]:localhost:5601` - w ten sposób przekierujemy Kibanę z localhost:5601 na zdalnym serwerze do wybranego przez nas portu na maszynie klienckiej.
Następnie sprawdzamy poprawność działania dashboardu pod adresem `http://localhost:5601/` w naszej lokalnej przeglądarce.
*Logstash:*
```
# systemctl status logstash
```
*Filebeats:*
```
# service filebeat status
```
### Zadanie 1
Pierwszym zadaniem jest konfiguracja usługi Logstash oraz Beats do zbierania logów systemowych. Aby możliwe było zbieranie logów systemowych konieczne jest przygotowanie odpowiednich do tego celu filtrów.
Pierwszym etapem jest przygotowanie pliku konfiguracyjnego dla komponentu Logstash. Tworzymy plik o nazwie **logstash-syslog.conf** w lokalizacji **/etc/logstash/conf.d/**.
```
input {
tcp {
port => 5000
type => syslog
}
udp {
port => 5000
type => syslog
}
}
filter {
if [type] == "syslog" {
grok {
match => { "message" => "%{SYSLOGTIMESTAMP:syslog_timestamp} %{SYSLOGHOST:syslog_hostname} %{DATA:syslog_program}(?:\[%{POSINT:syslog_pid}\])?: %{GREEDYDATA:syslog_message}" }
add_field => [ "received_at", "%{@timestamp}" ]
add_field => [ "received_from", "%{host}" ]
}
date {
match => [ "syslog_timestamp", "MMM d HH:mm:ss", "MMM dd HH:mm:ss" ]
}
}
}
output {
elasticsearch { hosts => ["localhost:9200"] }
stdout { codec => rubydebug }
}
```
Następnie uruchamiamy usługę Logstash
```
# systemctl start logstash
# systemctl enable logstash
```
oraz usługę Filebeat
```
# filebeat modules enable system
# filebeat setup
# service filebeat start
```
Po zakończeniu konfiguracji sprawdzamy w przeglądarce, czy usługa działa poprawnie. W tym celu wybieramy **Menu -> Observability -> Logs**.
**Uwaga!** Wykonaj **zrzut ekranu** potwierdzający wykonanie tej części zadania.
### Zadanie 2
Drugie zadanie ma na celu sprawdzenia jak na ciągłość logów wpływa brak dostępności poszczególnych usług mogący się pojawić np. w wyniku awarii.
1. Najpierw sprawdzamy, jak na ciągłość działania ma wpływ chwilowe wyłączenie usługi Logstash.
```
# systemctl stop logstash
```
**Uwaga!** Opisz jakie zachowanie obserwujemy w logach znajdujących się w Kibanie.
Uruchamiamy ponownie usługę Logstash. Co spowodowało ponowne uruchomienie usługi? Czy brak działania usługi wpłynął na ciągłość logowania zdarzeń? **Zapisz swoje obserwacje.**
2. Kolejnym etapem jest sprawdzenie jak na ciągłość logowania ma wpływ chwilowa nieciągłość pracy usługi Filebeat.
Wyłączamy usługę Filebeat
```
# service filebeat stop
```
Czekamy 5 minut i uruchamiamy usługę ponownie. Jak wyglądają logi systemowe znajdujące się w Kibanie? Czy wyłączenie usługi Filebeat ma wpływ na ciągłość logowania? **Zapisz swoje obserwacje.**
**Uwaga!** Wykonaj **zrzut ekranu** potwierdzający wykonanie tej części zadania. Zrzut powinien być zobrazowaniem Twoich obserwacji.
Na koniec wyłączamy usługę Filebeat.
### Zadanie 3
Celem trzeciego zadania jest konfiguracja klastra maszyn Elasticsearch. W tym celu należy sklonować wcześniej wykorzystywaną maszynę, tak aby mieć dwie jej instancje.
Aby umożliwić dostęp do maszyny za pośrednictwem protokołu SSH konieczne jest przekierowanie portu 22. W przypadku Sieci NAT VirtualBox’a, opcja przekierowania portów dostępna jest w: **Plik -> Globalne ustawienia -> Sieć**.
Zatrzymujemy usługę Elasticsearch na obu hostach
```
# systemctl stop elasticsearch
```
Sprawdzamy także status usług Kibana i Logstash. Jeżeli działają, to je wyłączamy.
```
# systemctl stop kibana
# systemctl stop logstash
```
Na jednej z dwóch maszyn wirtualnych uruchomimy wyłącznie usługę Elasticsearch, dlatego możemy zmniejszyć ilość RAM do niej przypisane do 2GB w ustawieniach VirtualBoxa. Będzie to maszyna, która będzie masterem w klastrze Elasticsearch. Po ponownym uruchomieniu maszyny wirtualnej zmieniamy wartości JVM heap w pliku **/etc/elasticsearch/jvm.options**
```
-Xms512m
-Xmx512m
```
Następnie przystępujemy do edycji pliku **/etc/elasticsearch/elasticsearch.yml**. Pola w pliku konfiguracyjnym, które trzeba odkomentować i uzupełnić zgodnie z poniższymi wytycznymi.
* `cluster.name` - nazwa klastra, ma zawierać pierwszą literę imienia i nazwisko, np. jnowak-cluster
* `node.name` - nazwa węzła, ma zawierać inicjały i numer węzła w klastrze, np. jn-master-1
* `network.host` - adres IP maszyny wirtualnej
* `http.port` - pozostawiamy wartość domyślną
* `discovery.seed_hosts` - lista adresów odpytywanych po uruchomieniu, dodajemy wszystkie adresy IP maszyn mających znaleźć się w klastrze
* `discovery.zen.minimum_master_nodes` - dodajemy parametr i ustawiamy jego wartość na 1
* `cluster.initial_master_nodes` - nazwy hostów, które mogą być masterem, ustawiamy nazwę hosta ze zmniejszoną ilością RAM
Konfiguracje dla obu hostów są bliźniacze za wyjątkiem pól `node.name` oraz `network.host`.
W ramach realizacji poprzedniego zadania nie zostały skonfigurowane wszystkie opcje wymagane do utworzenia klastra. Każdy z węzłów Elasticsearch utworzy zatem oddzielny klaster. Nawet jeżeli będziemy próbować skonfigurować węzły do działania w ramach jednego klastra, to Elasticsearch nie połączy ich ze sobą. Wynika to z faktu, że taka operacja nie jest możliwa bez utraty danych.
Jeżeli chcemy poprawnie stworzyć klaster należy usunąć wszystkie dane znajdujące się w katalogu **/var/lib/elasticsearch/**. Po wyczyszczeniu danych dla obu hostów uruchamiamy usługę Elasticsearch.
```
# systemctl start elasticsearch
# systemctl status elasticsearch
```
W celu sprawdzenia poprawności konfiguracji klastra Elasticsearch wykonujemy polecenie
```
# curl -XGET "http://<IP_maszyny_z_klastra>:9200/_cluster/state?pretty"
```
**Uwaga!** W celu potwierdzenia wykonania zadania prześlij plik konfiguracyjny **elasticsearch.yml** oraz **zrzut ekranu** obrazujący poprawne dołączenie hostów do klastra.
### Zadanie 4
Czwarte zadanie ma na celu sprawdzenie, czy możliwe jest skonfigurowanie Kibany do działania w trybie HA bez konieczności instalacji dodatkowych elementów jak HAProxy czy innego rodzaju LoadBalancer'a.
Pierwszym krokiem jest zatrzymanie usługi Kibana na obu maszynach
```
# systemctl stop kibana
```
Następnie przechodzimy do pliku konfiguracyjnego Kibany dla jednego z hostów - wybieramy ten który nie ma być masterem. Plik ten znajduje się w **/etc/kibana/kibana.yml**. Należy w nim zmienić wartości dla poniższych pól.
* **server.host** - localhost
* **elasticsearch.hosts** - adresy IP węzłów Elasticsearch wraz z portem, na których działają (9200), są to adresy węzłów skonfigurowanych w poprzednim zadaniu
Po zapisaniu konfiguracji uruchamiamy usługę Kibana na maszynie z przygotowaną konfiguracją.
Logujemy się do dashboardu Elastic Stack’a w przeglądarce pod adresem `http://localhost:5601`. (Należy pamiętać o przekierowaniu portu, gdyby połączenie było nieudane). Widzimy, że dashboard ładuje się poprawnie.
**Uwaga!** W celu potwierdzenia wykonania zadania prześlij plik **kibana.yml**. Zostanie on skorelowany z konfiguracją Elasticsearch.
### Zadanie 5
Zadanie piąte ma na celu wykazanie poprawności konfiguracji usługi Kibana umożliwiającej zapewnienie dostępności w przypadku awarii węzła Elasticsearch.
Wyłączamy usługę Elasticsearch na hoście z Kibaną, a następnie odświeżamy stronę w przeglądarce.
Jak zachowuje się usługa Kibana po wyłączeniu węzła Elasticsearch? **Zapisz swoje obserwacje.**
Logi generowane przez usługę Kibana są wyświetlane na wyjściu standardowym. Tworzymy zatem plik kibana.log i zapisujemy do niego ostatnie 50 logów poleceniem
```
# journalctl -u kibana | tail -n 50 > kibana.log
```
Analizując logi widzimy, że po wyłączeniu usługi Elasticsearch Kibana raportowała błędy, ale dzięki stworzonemu klastrowi węzłów Elasticsearch nie obserwowaliśmy niedostępności usługi.
**Uwaga!** W celu potwierdzenia wykonania zadania prześlij plik **kibana.log**. Upewnij się, że plik zawiera logi obrazujące wyłączenie usługi Elasticsearch, a następnie informacje o prawidłowej odpowiedzi.
Na koniec uruchamiamy ponownie usługę Elasticsearch na hoście z Kibaną.
### Zadanie 6
Szóste zadanie ma na celu utworzenie poprawnej konfiguracji komponentu Logstash na potrzeby zapewnienia HA.
1. Wybieramy hosta na którym konfigurowaliśmy Kibanę i przechodzimy do pliku **/etc/logstash/conf.d/logstash-syslog.conf**. W sekcji output dodajemy wszystkie hosty Elasticsearch znajdujące się w klastrze.
2. Następnie ustawiamy IP Kibany oraz hostów z Elasticsearch’em wraz z portami. W tym celu edytujemy plik **/etc/filebeat/filebeat.yml**.
3. Po przeprowadzeniu konfiguracji uruchamiamy usługi Logstash oraz Filebeat
```
# systemctl start logstash
# filebeat setup
# service filebeat start
```
**Uwaga!** W celu potwierdzenia wykonania zadania prześlij plik **logstash-syslog.conf** oraz **filebeat.yml**.
### Zadanie 7
Zadanie siódme ma na celu wykazanie poprawności konfiguracji usług Logstash oraz Filebeat (a także po części Kibany, czyli wszystkich komponentów Elastic Stack) umożliwiających zapewnienie dostępności w przypadku awarii węzła Elasticsearch.
W tym celu:
1. Uruchamiamy przeglądarkę i w Kibanie sprawdzamy, czy logi są poprawnie wyświetlane (**Menu -> Observability -> Logs**).
2. Następnie wyłączamy usługę Elasticsearch na maszynie z działającą Kibaną, Logstash’em oraz Filebeat’sem.
3. Po odświeżeniu strony powinniśmy obserwować ciągłość w działaniu wszystkich usług.
**Uwaga!** W celu potwierdzenia wykonania zadania załącz **logi Filebeat** obrazujące wyłączenie usługi Elasticsearch na jednej z maszyn klastra (ze znacznikiem czasu). Dodatkowo załącz **zrzut ekranu logów** w Kibanie dla czasu odpowiadającemu wystąpieniu błędu w Filebeat.
Sign in with Wallet
Connect another wallet