Thank you for reading this post, don't forget to subscribe!

В дан­ной ста­тье будет рас­смот­ре­но как уста­но­вить и настро­ить стек Elasticsearch, Kibana, fluentd   и Elasticsearch, Kibana, Logstash.

Elasticsearch: Elasticsearch явля­ет­ся гиб­ким и мощ­ным реше­ни­ем с откры­тым исход­ным кодом, зада­чей кото­рой явля­ет­ся рас­про­стра­не­ние, поиск в реаль­ном вре­ме­ни и ана­ли­ти­ка полу­чен­ных дан­ных . Бла­го­да­ря раз­ра­бот­ке архи­тек­ту­ры с нуля для исполь­зо­ва­ния в рас­пре­де­лен­ных сре­дах, где надеж­ность и мас­шта­би­ру­е­мость долж­ны иметь глав­ное зна­че­ние, Elasticsearch дает воз­мож­ность лег­ко вый­ти за рам­ки про­сто­го пол­но­тек­сто­во­го поис­ка. Бла­го­да­ря сво­ей проч­ной набор API-интер­фей­сов и запро­сов, DSL, плюс кли­ен­ты для наи­бо­лее попу­ляр­ных язы­ков про­грам­ми­ро­ва­ния, Elasticsearch постав­ля­ет на в буду­щем без­гра­нич­ные воз­мож­но­сти в орга­ни­за­ции тех­но­ло­гии поиска.

Kibana: Kibana явля­ет­ся визу­а­ли­за­то­ром дан­ных движ­ка Elasticsearch, что поз­во­ля­ет нам изна­чаль­но вза­и­мо­дей­ство­вать со все­ми дан­ны­ми в Elasticsearch через поль­зо­ва­тель­ские инстру­мен­таль­ные пане­ли. дина­ми­че­ские пане­ли Kibana могут сохра­нят­ся, раз­де­лять­ся и экс­пор­ти­ро­вать­ся, отоб­ра­жать изме­не­ния запро­сов в Elasticsearch в режи­ме реаль­но­го вре­ме­ни. Вы може­те выпол­нять ана­лиз дан­ных в поль­зо­ва­тель­ском интер­фей­се Kibana, исполь­зуя зара­нее раз­ра­бо­тан­ные инстру­мен­таль­ные пане­лей или обнов­лять эти пане­ли мони­то­рин­га в режи­ме реаль­но­го вре­ме­ни для ана­ли­за дан­ных по лету.

Fluentdtd-agent: Fluentd явля­ет­ся реше­ни­ем с  откры­тым исход­ным кодом для сбо­ра дан­ных кото­рое поз­во­ля­ет уни­фи­ци­ро­вать сбор дан­ных для боль­ше­го пони­ма­ния и удоб­ства даль­ней­ше­го анализа.

Logstash — это кон­вей­ер обра­бот­ки дан­ных, кото­рый полу­ча­ет сырые дан­ные (напри­мер, логи) из одно­го или несколь­ких  источ­ни­ков, обра­ба­ты­ва­ет их и улуч­ша­ет филь­тра­ми, а затем отправ­ля­ет резуль­тат одно­му или несколь­ким полу­ча­те­лям. Elastic реко­мен­ду­ет в каче­стве полу­ча­те­ля исполь­зо­вать Elasticsearch

Curator - так как логи, в нашем слу­чае, хра­нить более чем за 30 дней нету смыс­ла, мы исполь­зу­ем шту­ку, кото­рая уме­ет ходить в Elasticsearch и под­чи­щать индек­сы стар­ше чем 30 дней.

НАСТОЯТЕЛЬНО реко­мен­ду­ет­ся настро­ить ntpd на ноде, что­бы предот­вра­тить непра­виль­ные отмет­ки вре­ме­ни в ваших логах. Вот при­мер установки:

Установим JAVA

идём на сайт:
https://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html
регистрируемся(если нет акка­ун­та) и кача­ем отту­да пакет jdk-8u221-linux-x64.rpm
после чего ста­вим пакет:
[root@centos7 ~]# yum localinstall jdk-8u221-linux-x64.rpm

 

 

Установка Elasticsearch вариант 1

Копи­ру­ем пуб­лич­ный ключ репозитория:

rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch
Под­клю­ча­ем репо­зи­то­рий Elasticsearch:

vim /etc/yum.repos.d/elasticsearch.repo
[elasticsearch-7.x]
name=Elasticsearch repository for 7.x packages
baseurl=https://artifacts.elastic.co/packages/7.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1

 

При­сту­па­ем к уста­нов­ке еластика:

# yum install elasticsearch
В в завер­ше­нии уста­нов­ки доба­вим elasticsearch в авто­за­груз­ку и запу­стим его с дефолт­ны­ми настройками:

# systemctl daemon-reload
# systemctl enable elasticsearch.service

пра­вим файл
/etc/elasticsearch/jvm.options
меняем
-Xms1g
-Xmx1g
на
-Xms256m
-Xmx256m
если не жал­ко опе­ра­тив­ку може­те оста­вить и 1 гига­байт по умолчанию

# systemctl start elasticsearch.service
Про­ве­ря­ем, запу­сти­лась ли служба:

# systemctl status elasticsearch.service

 

Установка Kibana вариант 1

Импор­ти­ру­ем ключ репозитория:

# rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch
Добав­ля­ем кон­фиг репозитория:

# vim /etc/yum.repos.d/kibana.repo
[kibana-7.x]
name=Kibana repository for 7.x packages
baseurl=https://artifacts.elastic.co/packages/7.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md

Запус­ка­ем уста­нов­ку Kibana:

# yum install kibana
Добав­ля­ем Киба­на в авто­за­груз­ку и запускаем:

# systemctl daemon-reload
# systemctl enable kibana.service
# systemctl start kibana.service
Про­ве­ря­ем состо­я­ние запу­щен­но­го сервиса:

# systemctl status kibana.service
По-умол­ча­нию, Kibana слу­ша­ет порт 5601. Толь­ко не спе­ши­те его про­ве­рять после запус­ка. Киба­на стар­ту­ет дол­го. Подо­жди­те при­мер­но мину­ту и проверяйте.

# netstat -tulnp | grep 5601
tcp 0 0 127.0.0.1:5601 0.0.0.0:* LISTEN 27401/node

 

 

Настройка elasticsearch и kibana

Настрой­ки Elasticsearch нахо­дят­ся в файле:
/etc/elasticsearch/elasticsearch.yml
На началь­ном эта­пе нас будут инте­ре­со­вать сле­ду­ю­щие параметры:

path.data: /var/lib/elasticsearch # дирек­то­рия для хра­не­ния данных
network.host: 127.0.0.1 # слу­ша­ем толь­ко локаль­ный интерфейc
По-умол­ча­нию Elasticsearch слу­ша­ет все име­ю­щи­е­ся сете­вые интер­фей­сы. Нам это не нуж­но, так как дан­ные в него будет пере­да­вать logstash/fluentd, кото­рый будет уста­нов­лен локаль­но. Обра­щаю отдель­ное вни­ма­ние на пара­метр для дирек­то­рии с дан­ны­ми. Чаще все­го они будут зани­мать зна­чи­тель­ное место, ина­че зачем нам Elasticsearch 🙂 Поду­май­те зара­нее, где вы буде­те хра­нить логи. Все осталь­ные настрой­ки я остав­ляю дефолтными.

После изме­не­ния настро­ек, надо пере­за­пу­стить службу:

# systemctl restart elasticsearch.service
Смот­рим, что получилось:

# netstat -tulnp | grep 9200
tcp6 0 0 127.0.0.1:9200 :::* LISTEN 14130/java
Elasticsearch повис на локаль­ном интер­фей­се. При­чем я вижу, что он слу­ша­ет ipv6, а про ipv4 ни сло­ва. Но его он тоже слу­ша­ет, так что все в порядке.

 

Настрой­ка Kibana

Файл с настрой­ка­ми Киба­на рас­по­ла­га­ет­ся по пути:
/etc/kibana/kibana.yml.

На началь­ном эта­пе мож­но вооб­ще ниче­го не тро­гать и оста­вить все как есть. По-умол­ча­нию kibana слу­ша­ет толь­ко localhost и не поз­во­ля­ет под­клю­чать­ся уда­лен­но. Это нор­маль­ная ситу­а­ция, если у вас будет на этом же сер­ве­ре уста­нов­лен nginx в каче­стве reverse proxy, кото­рый будет при­ни­мать под­клю­че­ния и прок­си­ро­вать их в киба­на. Так и нуж­но делать в про­дак­шене, когда систе­мой будут поль­зо­вать­ся раз­ные люди из раз­ных мест. С помо­щью nginx мож­но будет раз­гра­ни­чи­вать доступ, исполь­зо­вать сер­ти­фи­кат, настра­и­вать нор­маль­ное домен­ное имя и т.д.

Если же у вас это тесто­вая уста­нов­ка, то мож­но обой­тись без nginx. Для это­го надо раз­ре­шить Киба­на слу­шать внеш­ний интер­фейс и при­ни­мать под­клю­че­ния. Изме­ни­те пара­метр server.host, ука­зав ip адрес сер­ве­ра, напри­мер вот так:

server.host: "10.1.4.114"
Если хоти­те, что­бы она слу­ша­ла все интер­фей­сы, ука­жи­те в каче­стве адре­са 0.0.0.0. После это­го Kibana надо перезапустить:

# systemctl restart kibana.service
Теперь мож­но зай­ти в веб интер­фейс по адре­су http://10.1.4.114:5601.

Мож­но про­дол­жать настрой­ку и тести­ро­ва­ние, а когда все будет закон­че­но, запу­стить nginx и настро­ить проксирование.

 

Проксирование подключений к Kibana через Nginx

Я не буду подроб­но рас­ска­зы­вать о том, что такое прок­си­ро­ва­ние в nginx. При­ве­ду при­мер кон­фи­га для пере­да­чи запро­сов с nginx в kibana. Я реко­мен­дую исполь­зо­вать ssl сер­ти­фи­ка­ты для досту­па к Kibana. Даже если в этом нет объ­ек­тив­ной необ­хо­ди­мо­сти, надо­еда­ют уве­дом­ле­ния бра­у­зе­ров о том, что у вас небез­опас­ное подключение.
созда­ём сертификат:

mkdir -p /certs
openssl genrsa -out /certs/test.ru.key 1024
openssl req -new -key /certs/test.ru.key -out /certs/test.ru.csr
здесь ука­за­ли наш домен
Common Name (eg, your name or your server's hostname) []:*.test.ru
openssl x509 -req -days 365 -in /certs/test.ru.csr -signkey /certs/test.ru.key -out /certs/test.ru.crt
cat /certs/test.ru.crt /certs/test.ru.key | tee /certs/test.ru.pem

Вот при­мер­ный кон­фиг nginx для прок­си­ро­ва­ния запро­сов к Kibana с огра­ни­че­ни­ем досту­па по паролю:

 

 

Созда­ем файл для поль­зо­ва­те­лей и паролей:

# htpasswd -c /etc/nginx/htpasswd.kibana kibanauser
Если ути­ли­ты htpasswd нет в систе­ме, то уста­но­ви­те ее:

# yum install -y httpd-tools
После это­го вый­дет запрос на ввод паро­ля. С помо­щью при­ве­ден­ной выше коман­ды мы созда­ли файл с инфор­ма­ци­ей о поль­зо­ва­те­ле и паро­ле kibanauser для огра­ни­че­ния досту­па к web пане­ли кибана.

====================================

перей­дём к настрой­ке сбор­щи­ков логов есть 2 вари­ан­та logstash/fluentd

 

Установка и настройка Logstash

Logstash уста­нав­ли­ва­ет­ся так же, как Elasticsearch и Kibana, из того же репо­зи­то­рия. Не буду еще раз пока­зы­вать, как его доба­вить. Про­сто уста­но­вим его и доба­вим в автозагрузку.

Уста­нов­ка Logstash в Centos 7:

# yum install logstash

Добав­ля­ем logstash в автозагрузку:

# systemctl enable logstash.service

Запус­кать пока не будем, надо его сна­ча­ла настро­ить. Основ­ной кон­фиг logstash лежит по адресу

/etc/logstash/logstash.yml
Я его тро­гать не буду, а все настрой­ки буду по смыс­лу раз­де­лять по раз­ным кон­фи­гу­ра­ци­он­ным фай­лам в директории

/etc/logstash/conf.d.

Созда­ем пер­вый кон­фиг input.conf, кото­рый будет опи­сы­вать при­ем инфор­ма­ции с beats агентов.

[root@centos7 ~]# vim /etc/logstash/conf.d/input.conf

Тут все про­сто. Ука­зы­ваю, что при­ни­ма­ем инфор­ма­цию на 5044 порт. Это­го доста­точ­но. Если вы хоти­те исполь­зо­вать ssl сер­ти­фи­ка­ты для пере­да­чи логов по защи­щен­ным соеди­не­ни­ям, здесь добав­ля­ют­ся пара­мет­ры ssl. Я буду соби­рать дан­ные из закры­то­го пери­мет­ра локаль­ной сети, у меня нет необ­хо­ди­мо­сти исполь­зо­вать ssl.

Теперь ука­жем, куда будем пере­да­вать дан­ные. Тут тоже все отно­си­тель­но про­сто. Созда­ём кон­фиг output.conf, кото­рый опи­сы­ва­ет пере­да­чу дан­ных в Elasticsearch.

[root@centos7 ~]# vim /etc/logstash/conf.d/output.conf

 

Здесь все про­сто — пере­да­вать все дан­ные в elasticsearch под ука­зан­ным индек­сом с мас­кой в виде даты. Насколь­ко я понял, раз­бив­ка индек­сов по дням и по типам дан­ных удоб­на с точ­ки зре­ния управ­ле­ния дан­ны­ми. Потом лег­ко будет выпол­нять очист­ку дан­ных по этим индек­сам. Я заком­мен­ти­ро­вал послед­нюю стро­ку. Она отве­ча­ет за логи­ро­ва­ние. Если ее вклю­чить, то все посту­па­ю­щие дан­ные logstash будет отправ­лять допол­ни­тель­но в систем­ный лог. В centos это /var/log/messages. Исполь­зуй­те толь­ко во вре­мя отлад­ки, ина­че лог быст­ро раз­растет­ся дуб­ля­ми посту­па­ю­щих данных.

Оста­ет­ся послед­ний кон­фиг с опи­са­ние обра­бот­ки дан­ных. Созда­ём кон­фиг filter.conf.
[root@centos7 ~]# vim /etc/logstash/conf.d/filter.conf

 

 

Пер­вое, что дела­ет этот фильтр, пар­сит логи nginx с помо­щью grok, если ука­зан соот­вет­ству­ю­щий тип логов, и выде­ля­ет из лога клю­че­вые дан­ные, кото­рые запи­сы­ва­ет в опре­де­лен­ные поля, что­бы потом с ними было удоб­но рабо­тать. В доку­мен­та­ции к filebeat хоро­шо опи­са­ны моду­ли, иду­щие в ком­плек­те, кото­рые все это и так уже уме­ют делать из короб­ки, нуж­но толь­ко под­клю­чить соот­вет­ству­ю­щий модуль.

Ока­за­лось, что моду­ли filebeat рабо­та­ют толь­ко в том слу­чае, если вы отправ­ля­е­те дан­ные напря­мую в elasticsearch. На него вы тоже ста­ви­те соот­вет­ству­ю­щий пла­гин и полу­ча­е­те отфор­ма­ти­ро­ван­ные дан­ные. Но у нас рабо­та­ет про­ме­жу­точ­ное зве­но logstash, кото­рый при­ни­ма­ет дан­ные. С ним, как я понял, пла­ги­ны filebeat не рабо­та­ют, поэто­му при­хо­дит­ся отдель­но в logstash пар­сить дан­ные. Это не очень слож­но, но тем не менее. Как я понял, это пла­та за удоб­ства, кото­рые дает logstash. Если у вас мно­го раз­роз­нен­ных дан­ных, то отправ­лять их напря­мую в elasticsearch не так удоб­но, как с исполь­зо­ва­ни­ем пре­до­б­ра­бот­ки в logstash. Я так понял этот момент.

Для филь­тра grok, кото­рый исполь­зу­ет logstash, есть удоб­ный дебаг­гер, где мож­но посмот­реть, как будут пар­сить­ся ваши дан­ные. Пока­жу на при­ме­ре одной стро­ки из кон­фи­га nginx. Напри­мер, возь­мем такую стро­ку из лога nginx:

180.163.220.100 - travvels.ru [05/Sep/2019:14:45:52 +0300] "GET /assets/galleries/26/1.png HTTP/1.1" 304 0 "https://travvels.ru/ru/glavnaya/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36"

И посмот­рим, как ее рас­пар­сит пра­ви­ло grok, кото­рое я исполь­зо­вал в кон­фи­ге выше.

%{IPORHOST:remote_ip} - %{DATA:user} \[%{HTTPDATE:access_time}\] \"%{WORD:http_method} %{DATA:url} HTTP/%{NUMBER:http_version}\" %{NUMBER:response_code} %{NUMBER:body_sent_bytes} \"%{DATA:referrer}\" \"%{DATA:agent}\"

Соб­ствен­но, резуль­тат вы може­те сами уви­деть в дебаг­ге­ре. Фильтр рас­пар­сит лог и на выхо­де сфор­ми­ру­ет json, где каж­до­му зна­че­нию будет при­сво­е­но свое поле, по кото­ро­му потом удоб­но будет в ела­сти­ке стро­ить отче­ты и делать выбор­ки. Толь­ко не забы­вай­те про фор­мат логов. При­ве­ден­ное мной пра­ви­ло соот­вет­ству­ет дефолт­но­му фор­ма­ту main логов в nginx. Если вы каким-то обра­зом моди­фи­ци­ро­ва­ли фор­мат логов, вне­си­те изме­не­ния в grok фильтр.

Вы може­те таким обра­зом пар­сить любые логи и пере­да­вать их в ела­стикс. Потом на осно­ве этих дан­ных стро­ить отче­ты, гра­фи­ки, дашборды.

Даль­ше исполь­зу­ет­ся модуль date для того, что­бы выде­лять дату из посту­па­ю­щих логов и исполь­зо­вать ее в каче­стве даты доку­мен­та в elasticsearch. Дела­ет­ся это для того, что­бы не воз­ни­ка­ло пута­ни­цы, если будут задерж­ки с достав­кой логов. В систе­ме сооб­ще­ния будут с одной датой, а внут­ри лога будет дру­гая дата. Неудоб­но раз­би­рать инциденты.

В кон­це я исполь­зую geoip фильтр, кото­рый на осно­ве ip адре­са, кото­рый мы полу­чи­ли ранее с помо­щью филь­тра grok и запи­са­ли в поле remote_ip, опре­де­ля­ет гео­гра­фи­че­ское рас­по­ло­же­ние. Он добав­ля­ет новые мет­ки и запи­сы­ва­ет туда гео­гра­фи­че­ские дан­ные. Для его рабо­ты мне было доста­точ­но опи­сать его в кон­фи­ге и ска­чать базу адре­сов в папку

/etc/logstash.

cd /etc/logstash/
wget http://geolite.maxmind.com/download/geoip/database/GeoLite2-City.mmdb.gz
gunzip GeoLite2-City.mmdb.gz

теперь попра­вил объ­ём потреб­ля­е­мой памя­ти, в файле:
/etc/logstash/jvm.options
меняем:
-Xms1g
-Xmx1g
на
-Xms256m
-Xmx256m
если не жал­ко опе­ра­тив­ку може­те оста­вить и 1 гига­байт по умолчанию
Закон­чи­ли настрой­ку logstash. Запус­ка­ем его:

systemctl start logstash.service
Може­те про­ве­рить на вся­кий слу­чай лог /var/log/logstash/logstash-plain.log, что­бы убе­дить­ся в том, что все в поряд­ке. Теперь настро­им аген­ты для отправ­ки данных.

Уста­нов­ка Filebeat для отправ­ки логов в Logstash
Уста­но­вим пер­во­го аген­та Filebeat на сер­вер с nginx для отправ­ки логов веб сер­ве­ра на сер­вер с ELK. Ста­вить мож­но как из обще­го репо­зи­то­рия, кото­рый мы под­клю­ча­ли ранее, так и по отдель­но­сти паке­ты. Как ста­вить — решать вам. В пер­вом слу­чае при­дет­ся на все хосты добав­лять репо­зи­то­рий, но зато потом удоб­но обнов­лять паке­ты. Если под­клю­чать репо­зи­то­рий не хочет­ся, мож­но про­сто ска­чать пакет и уста­но­вить его.

Ста­вим на Centos 7.

# curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-6.4.0-x86_64.rpm
# rpm -vi filebeat-6.4.0-x86_64.rpm

Или про­сто:

# yum install filebeat

[root@centos7 ~]# mv /etc/filebeat/filebeat.yml /etc/filebeat/filebeat.yml_default

После уста­нов­ки созда­ём при­мер­но такой кон­фиг /etc/filebeat/filebeat.yml для отправ­ки логов в logstash.

 

Неко­то­рые пояс­не­ния к кон­фи­гу, так как он не совсем дефолт­ный и мини­ма­ли­стич­ный. Я его немно­го моди­фи­ци­ро­вал для удобства.
Во-пер­вых, я раз­де­лил логи access и error с помо­щью отдель­но­го поля type, куда запи­сы­ваю соот­вет­ству­ю­щий тип лога: nginx_access или nginx_error. В зави­си­мо­сти от типа меня­ют­ся пра­ви­ла обра­бот­ки в logstash. Плюс, я вклю­чил мони­то­ринг и для это­го ука­зал адрес elastichsearch, куда filebeat пере­да­ет дан­ные мони­то­рин­га напря­мую. Пока­зы­ваю это для вас про­сто с целью про­де­мон­стри­ро­вать воз­мож­ность. Что­бы мони­то­ринг рабо­тал, его надо акти­ви­ро­вать в соот­вет­ству­ю­щем раз­де­ле в Kibana — Monitoring. И не забудь­те запу­стить elasticsearch на внеш­нем интер­фей­се. В пер­во­на­чаль­ной настрой­ке я ука­зал слу­шать толь­ко локаль­ный интерфейс.

Запус­ка­ем filebeat и добав­ля­ем в автозагрузку.

# systemctl start filebeat
# systemctl enable filebeat
Про­ве­ряй­те лог по адре­су /var/log/filebeat/filebeat. Он весь­ма инфор­ма­ти­вет. Если все в поряд­ке, уви­ди­те спи­сок всех логов в дирек­то­рии /var/log/nginx, кото­рые нашел filebeat и начал гото­вить к отправ­ке. Если все сде­ла­ли пра­виль­но, то дан­ные уже потек­ли в elasticsearch. Мы их можем посмот­реть в Kibana. Для это­го откры­ва­ем web интер­фейс и пере­хо­дим в раз­дел Discover. Так как там еще нет индек­са, нас пере­на­пра­вит в раз­дел Managemet, где мы смо­жем его добавить.
Вы долж­ны уви­деть индекс, кото­рый начал зали­вать logstash в elasticsearch. В поле Index pattern вве­ди­те nginx-* и нажми­те Next Step. На сле­ду­ю­щем эта­пе выбе­ри­те имя поля для вре­мен­но­го филь­тра. У вас будет толь­ко один вари­ант — @timestamp, выби­рай­те его и жми­те Create Index Pattern.

Созда­ние индек­са с данными

Новый индекс добав­лен. Теперь при пере­хо­де в раз­дел Discover, он будет откры­вать­ся по-умол­ча­нию со все­ми дан­ны­ми, кото­рые в него поступают.

====================================================

Установка fluentd

curl -L https://toolbelt.treasuredata.com/sh/install-redhat-td-agent3.sh | sh
[root@centos7 ~]# mv /etc/td-agent/td-agent.conf /etc/td-agent/td-agent.conf_default

одной коман­дой вводим:

td-agent-gem install fluent-plugin-elasticsearch \
fluent-plugin-record-modifier \
fluent-plugin-exclude-filter \
fluent-plugin-splunk-enterprise

vim /etc/td-agent/td-agent.conf

 

 

[root@centos7 ~]# systemctl start td-agent
[root@centos7 ~]# systemctl enable td-agent

Даль­ше пра­вим /etc/rsyslog.conf и добавляем:

*.* @192.168.1.170:42185

после чего перезапускаем:
systemctl restart rsyslog

 

Кон­фи­гу­ра­ци­он­ный файл нахо­дит­ся по адресу

/etc/td-agent/td-agent.conf и состо­ит из 6ти так назы­ва­е­мых сек­ций. Основ­ные мы сей­час рассмотрим.

• source — сек­ция опи­сы­ва­ет источ­ник дан­ных. В этом раз­де­ле мы опи­сы­ва­ем то, отку­да к нам посту­па­ют дан­ные, их источник.
• match — эта сек­ция опи­сы­ва­ет, что нам делать с дан­ны­ми, куда их напра­вить. Будь это пере­да­ча дру­го­му при­ло­же­нию или запись в файл.
• filter — не часто при­хо­дит­ся исполь­зо­вать эту сек­цию, поз­во­ля­ет нам изме­нять полу­чен­ные данные.
• system — содер­жит настрой­ки приложения.
• label — поз­во­ля­ет объ­еди­нить сек­ции match и filter. Упро­ща­ет внут­рен­ний роутинг, гру­бо гово­ря, будем в кон­фи­гу­ра­ции исполь­зо­вать мень­ше тегов.
• include — поз­во­ля­ет под­клю­чать кон­фи­гу­ра­ци­он­ные фай­лы. Полез­но при боль­шом коли­че­стве источников.

Основ­ное назна­че­ние раз­де­лов кон­фи­гу­ра­ции разо­бра­ли, теперь при­сту­пим к настрой­ке. Будем с одной маши­ны отправ­лять логи при помо­щи rsyslog по tcp протоколу.

source

Как и писал выше, в этом раз­де­ле мы будем опи­сы­вать источ­ник дан­ных для хра­не­ния. Мы будем при­ни­мать логи по сети от дру­го­го сер­ве­ра и скла­ды­вать их у себя в опре­де­лен­ной пап­ке. Для это­го доба­вим в кон­фиг следующее:

Этот кон­фиг гово­рит нам, что мы будем исполь­зо­вать вхо­дя­щий пла­гин syslog, слу­шать он будет порт 42185, на этот порт мы будем отправ­лять логи из дру­гих машин и поме­чать тегом rsyslog, этот тег мы будем исполь­зо­вать в сек­ции match.

match

Сооб­ще­ния мы уже можем при­ни­мать, теперь нуж­но их обра­бо­тать. Кон­фи­гу­ра­ция обработчика:

Здесь я буду исполь­зо­вать пла­гин copy, так как в буду­щем соби­ра­юсь не толь­ко сохра­нять логи в файл, но и отправ­лять в дру­гие источ­ни­ки, поэто­му type ука­зы­ва­ем copy. Далее внут­ри match объ­яв­ля­ем сек­цию store в кото­рой исполь­зу­ем пла­гин file. Этот пла­гин запи­сы­ва­ет посту­па­ю­щие сооб­ще­ния в файл, в дан­ной кон­фи­гу­ра­ции есть опция time_slice_format %Y%m%d, она гово­рит, что нуж­но сохра­нять один файл на в сут­ки. Дру­ги­ми сло­ва­ми, на одни сут­ки у нас будет один файл с логом.
Все, теперь мы гото­вы при­ни­мать логи. Пере­за­пу­стим fluentd(/etc/init.d/td-agent restart) и при­сту­пим к настрой­ке rsyslog на машине-отправителе.

mkdir /var/log/fluent/
chown -R td-agent:td-agent /var/log/fluent/

systemctl restart td-agent

 

Rsyslog

Rsyslog — попу­ляр­ный, быст­рый, гиб­кий сер­вис для управ­ле­ния лога­ми. Нам он нужен в част­но­сти, что­бы отда­вать логи на маши­ну с уста­нов­лен­ным fluentd.

Уста­нов­ка rsyslog

Уста­нов­ка очень три­ви­аль­на и про­ста, запуск одной коман­ды сде­ла­ет всё за вас:

yum install rsyslog

Настрой­ка отправ­ки логов

Откры­ва­ем файл кон­фи­гу­ра­ции nano /etc/rsyslog.conf и вно­сим правки(под sudo разумеется):

Я доба­вил эту стро­ку вна­ча­ле фай­ла, есте­ствен­но адрес и порт ука­зы­ва­ем того хоста, кото­рый будет при­ни­мать логи. Теперь все логи кото­рые опи­са­ны в кон­фи­гу­ра­ци­он­ных фай­лах будут успеш­но достав­ле­ны на маши­ну с fluentd демо­ном. Пере­за­пус­ка­ем service rsyslog restartи через неко­то­рое вре­мя по ука­зан­но­му пути, кото­рый мы ука­за­ли в кон­фи­ге fluentd, обна­ру­жим фай­лы с лога­ми от уда­лен­но­го сервера.

 

Установка curator

rpm --import https://packages.elastic.co/GPG-KEY-elasticsearch

vim /etc/yum.repos.d/curator.repo

[curator-5]
name=CentOS/RHEL 7 repository for Elasticsearch Curator 5.x packages
baseurl=https://packages.elastic.co/curator/5/centos/7
gpgcheck=1
gpgkey=https://packages.elastic.co/GPG-KEY-elasticsearch
enabled=1

yum install elasticsearch-curator

mkdir /etc/curator
touch /etc/curator/action.yml
touch /etc/curator/config.yml

vim /etc/curator/config.yml

 

Даль­ше файл с необ­хо­ди­мы­ми действиями:

vim /etc/curator/action.yml

 

Обра­щаю вни­ма­ние на фор­ма­ти­ро­ва­ние фай­ла. Отсту­пы в нача­ле стро­ки важ­ны. Они долж­ны быть имен­но такие, как у меня в примере.

Кон­фиг сде­лан на осно­ве при­ме­ров из офи­ци­аль­ной доку­мен­та­ции. Реко­мен­дую все подроб­но­сти искать там. Запус­ка­ем очистку:

/usr/bin/curator --config /etc/curator/config.yml /etc/curator/action.yml
В кон­со­ли уви­ди­те инфор­ма­тив­ный вывод выпол­ня­е­мых команд по очист­ке индек­сов. После завер­ше­ния очист­ки, не забудь­те доба­вить зада­ние в cron.

 crontab -e
4 4 * * * /usr/bin/curator --config /etc/curator/config.yml /etc/curator/action.yml
Очист­ка индек­сов будет выпол­нять­ся каж­дый день в 4 утра.