Elasticsearch w stosie ELK to podstawa, ale omnibus na podstawach nie kończy. Teraz trzeba zmierzyć się z literą L, czyli Logstash’em. Logstash to nic innego, jak narzędzie do przetwarzania różnych logów tak, aby pasowały do modelu danych używanego w Elasticsearchu.
Jako że robota jest na wczoraj, a czasu brakuje, ściągnij instalator Logstasha z https://www.elastic.co/downloads/logstash.
Na koniec, żeby mieć materiał do eksperymentów, potrzebny będzie generator logów, do pobrania z https://github.com/kiritbasu/Fake-Apache-Log-Generator. Generator nie jest obowiązkowy, ale dobrze wyposażony (wyposażona?) omnibus ma różne przydatne narzędzia. Niestety, generator wymaga Pythona, którego możesz nie mieć, ale wystarczy zajrzeć na https://www.python.org/download/ i go pobrać.
Po zainstalowaniu Logstasha i Pythona oraz pobraniu generatora logów, trzeba tego ostatniego rozpakować i zainstalować. W katalogu, w którym jest rozpakowany Fake Apache Log Generator, wykonaj na konsoli (cmd, terminal, whatever) polecenie:

pip install – requirements.txt

Jak wszystko pójdzie jak po maśle i dodatkowe biblioteki się pięknie zainstalują, czas na wygenerowanie roboczego logu.

python apache-fake-log-gen.py -n 100 -o LOG

I znowu, jeśli nic się nie powaliło, dostaniesz testowy log Apache o długości 100 wierszy. Możesz sobie wygenerować dowolnie duży log, ale przecież czasu nie ma, a robota czeka.
Wskazane jest, żeby ten log przenieść do katalogu, gdzie będziesz trzymać również inne logi, np. /var/log/my-apache-logs. Zresztą, zrobisz to, gdzie chcesz. Ważne, żeby pamiętać, gdzie te logi siedzą.
Teraz uwaga, bo to ważne: musisz stworzyć konfigurację dla Logstasha, może być na bazie poniższego przykładu.

input {
file {
path => "/var/my_apache_logs/*.log"
}
}
filter {
grok {
match => { "message" => "%{COMBINEDAPACHELOG}"}
}
geoip {
source => "clientip"
add_field => [ "[geoip][coordinates]", "%{[geoip][longitude]}" ]
add_field => [ "[geoip][coordinates]", "%{[geoip][latitude]}" ]
}

mutate {
convert => { "[geoip][coordinates]" => "float" }
}
}
output {
stdout { codec => rubydebug }
elasticsearch {
hosts => [ "localhost:9200" ]
index => "logstash-apache-%{+YYYY.MM.dd}"
}
}

Plik konfiguracyjny powinien znaleźć się tam, gdzie został rozpakowany/zainstalowany Logstash. Zapisz go pod nazwą apache-config.conf, bo takiej będę używać w tym przykładzie. Zresztą, każdy ma jakiś klucz do nazywania plików, a ja po prostu każdą konfigurację Logstasha zapisuję pod taka nazwą, żeby potem nie szukać w panice, co do jakich logów zostało skonfigurowane. Konfiguracja składa się z trzech części i raczej musisz wiedzieć, za co one odopwiadają.

Input
Sekcja ta instruuje Logstasha, skąd będzie pobierał dane wejściowe (w twoim przypadku są to teraz pliki z logami, więc warto skorzystać z plugina input file). Logstash będzie przetwarzać pliki ze wskazanych katalogów, a dodatkowo można go poinstruować maskami (wildcards), że do końca nie wiesz, jakie będą konkretne nazwy, albo po prostu brać wszystkie pliki z katalogu.

Filter
W sekcji Filter definiujesz filtry do przetwarzania logów. Jeśli log ma strukturę, jest wiele gotowych wzorców w filtrze grok. Jeśli żaden z gotowych wzorców nie pasuje albo trudno taką strukturę w logu znaleźć, można i trzeba samemu napisać zestaw regex-ów do wydobywania tego, co nas będzie interesować.
Testowy log Apache na szczęście ma strukturę i jest dla niego gotowy szablon grok. Dzięki temu wszystkie pola, takie jak adres IP czy metoda HTTP, będą wyciągane bez regexowej gimnastyki. Dodatkowo, korzystam z filtra geoip w celu rozwiązania adresów IP na lokacje geograficzne. To się potem przyda do atrakcyjnej wizualizacji w Kibanie, ale o tym później. Kolejny filtr, mutate, zapewni współrzędnym geograficznym właściwy format. Filtrom Logstasha i zaawansowanej konfiguracji przyjrzymy się w niedalekiej przyszłości.

Output
W tej sekcji trzeba zdefiniować, gdzie mają trafić dane z Logstasha. U mnie, do Elasticsearcha, a konkretnie do indeksu, którego nazwę definiuje się wg domyślnego schematu:
logstash- %{+YYYY.MM.dd}
Do szybkich eksperymentów, dobrze jest zostawić również stdout jako tymczasowo-debugowy podgląd tego, czy i jak działa Logstash. Docelowo, w rozwiązaniach produkcyjnych, stdout raczej trzeba usunąć.

Skomplikowane to nie jest, ale ta składnia i nazwy parametrów mogą drażnić co wrażliwsze oko. Do końca przeprawy z Logstashem zostaje tylko uruchomić go (pewnie wejdziesz do katalogu $INSTALL/logstash/bin):

./logstash -f apache-config.conf

Pamiętaj, że to tylko tymczasowe uruchomienie, nie jako serwis.
Logstash powinien wyrzucić na ekran litanię mało interesujących komunikatów, a ty możesz odetchnąć, jeśli nie było żadnych błędów. Teraz zostaje tylko sprawdzić w Elasticsearchu, czy do wskazanego indeksu trafiły dane z logu. Na konsoli Kibany uruchom:

GET /nazwa-naszego-indeksu/_search
{
"query": { "match_all": {} }
}

U mnie wszystko było, jak trzeba, a u ciebie? Ale dane to za mało, żeby naszą podróż z ELK uznać za zakończoną. W następnej części o tym, jak zwizualizować dane w sposób efektowny i efektywny.