Thank you for reading this post, don't forget to subscribe!
Базовая архитектурная схема мониторинг стека имеет вид:
Алгоритм действий состоит из следующих шагов:
1.Базовое описание стека
2.Установка и настройка Elasticsearch+Kibana-коллектора(серверной части)
3.Настройка аутентификации и авторизации в Elasticsearch/Kibana
4.Установка и настройка Cerebro и Curator-сервисов
5.Создание пользователя fluentd с необходимыми привиллегиями в Elastcisearch, который будет использоваться в Fluentd/Filebeat-агентах для аутентификации/авторизации в Elasticsearch
6.Установка и настройка на целевом хосте Fluentd-агента, с помощью которого собираем логи(все логии, кроме mysql-логов)
7.Установка и настройка на целевом хосте Filebeat-агента, с помощью которого собираем только MySQL error/slow-логи
8.Создание и сохранение Search, Vizualization, Dashboard в Kibana
1.Базовое описание стека
Mониторинг стек состоит из следующих компонентов:
Elasticsearch— хранение, индексация, поиск логов
Fluentd – сбор, фильтрация, парсинг логов, их буферизация и отправка на Elasticsearch
Kibana – визуализация логов/данных через выполнения API-запросов к Elasticsearch
Cerebro – просмотр и управление Elasticsearch индексами, шаблонами, нодами
Curator – работа с Elasticsearch-индексами( удаление индексов старше определенного количества времени, в нашем случае больше 14 дней)
Caddy – Обратный прокси-сервер для Kibana
Elasticsearch, Kibana, Caddy, Cerebo, Curator, запущены на одном сервере (физическом или виртуальном, не важно) через docker-compose
SSL-терминирование происходит на Cloudflare и чистый http направляется на Caddy-сервис, который выступает в качестве proxy-сервера к Kibana
Вместо Caddy можно использовать Nginx, на котором настроить базовую аутентификацию для доступа к Kibana, такой Nginx будет выступать в качестве прокси-сервера к Кибана.
Также на этом Nginx сервере можно настроить SSL-терминирование(если не используется сторонний сервис по SSL-терминированию)
Доступ к Elasticsearch ограничен по сети с помощью OpenVPN-туннеля(т.е. Elasticsearch доступен снаружи только через Openvpn-туннельный адрес), несмотря на то, что также будет включена базовая аутентификация и авторизация в Elasticsearch
Если нет возможности/желания ограничивать доступ на уровне туннелей, тогда альтернативным вариантом могут быть
А) базовая аутентификация + SSL на Elasticsearch
Б) ограничение доступа к порту Elastisearch на уровне файрволла iptables(правила добавляем в цепочку DOCKER-USER)
Например:
|
1
|
# iptables -I DOCKER-USER -s target-host/32 -p tcp -m tcp --dport 9200 -j ACCEPT
|
|
1
|
# iptables -I DOCKER-USER 2 -p tcp -m tcp --dport 9200 -j DROP
|
Реализован сбор следующих логов:
1. Docker nginx access/error-logs
2. Docker PHP-FPM logs
3. System logs (/var/log/messages – Centos, /var/log/syslog – Ubuntu/Debian)
4. Secure logs (/var/log/secure – Centos, /var/log/auth.log – Ubuntu/Debian)
5. Bash history (/var/log/bash_history) – все выполненные консольные команды на серверах
6. MySQL error/slow logs
Nginx access лог и php-fpm логи собираем с Docker-контейнеров Nginx и PHP-FPM
Nginx error-логи Docker-контейнеров собираем из log-файла, который монтируется с хоста в контейнер
System и Security логи собираем из соответствующих лог файлов на хосте
Все выполненные на целевых хостах команды собираются/дублируются в файл /var/log/bash_history, с которого и собираются bash-history-логи
MySQL логи ошибок и медленных запросов собираются с помощью filebeat(чтобы просто посмотреть альтернативу fluentd)
Сбором логов на целевых хостах занимается Fluentd-агент(для всех вышеуказанных логов, за исключением логов MySQL, сбор которых я преднамеренно оставил за Filebeat-агентом, чтобы рассмотреть его как альтернативу Fluentd-агенту)
Fluentd собирает, фильтрует(отбрасывая ненужные для нас логи контейнеров), парсит, буферизирует логи и порциями отправляет в Elasticsearch
Запущенные контейнеры и прослушиваемые порты на интерфейсах имеют вид
|
# docker-compose ps
|
|
1
2
3
4
5
6
7
|
Name Command State Ports
----------------------------------------------------------------------------------------------------------------------
caddy /sbin/tini -- caddy -agree ... Up 0.0.0.0:80->80/tcp
cerebro /docker-entrypoint.sh /opt ... Up 127.0.0.1:9000->9000/tcp
curator /docker-entrypoint.sh cron ... Up
elasticsearch /usr/local/bin/docker-entr ... Up 10.10.111.1:9200->9200/tcp,127.0.0.1:9200->9200/tcp, 9300/tcp
kibana /usr/local/bin/kibana-docker Up 127.0.0.1:5601->5601/tcp
|
Иерархия каталогов/файлов имеет следующий вид
2. Установка и настройка Elastcisearch+Kibana-коллектора(серверной части)
Перед запуском логгинг стека необходимо выполнить первоначальную его настройку
1.Копирование файл-шаблона env-example с переменными для docker-compose в .env
(файл, который docker-compose читает при своем запуске) и указать в .env-файле значения для следующей переменной
|
1
|
KIBANA_SERVER_NAME
|
– URL, на котором доступна Kibana (например, kibana.mydomain.com)
2.Создание и запуск пока ТОЛЬКО Elasticsearch и Caddy-контейнеров
При необходимости измените значение переменной
|
1
|
ELASTICSEARCH_JVM_HEAP
|
Если необходимо отключить аутентификацию/авторизацию в Elasticsearch/Kibana, тогда измените значение опции
|
1
|
xpack.security.enabled
|
на false
Кстати, по умолчанию для free base лицензии она выключена
Сравнение лицензий Elastic Stack доступно по ссылке
https://www.elastic.co/subscriptions
Также измените строку, указав в ней IP-адрес, на который будут подключаться клиенты(fluentd-агенты)
|
1
|
- "10.10.111.1:9200:9200"
|
|
1
|
# docker-compose up -d --no-deps elasticsearch caddy
|
Проверяем,что требуется аутентификация для доступа в Elasticsearch
|
1
|
# curl http://127.0.0.1:9200
|
Данные(индексы, служебные данные), логи и конфигурационный файл Elasticsearch монтируется с хоста в docker-контейнер
Конфигурационный файла elasticsearch.yml имеет вид:
|
1
2
3
4
5
|
cluster.name: "docker-cluster"
network.host: 0.0.0.0
xpack.security.enabled: true
bootstrap.memory_lock: true
xpack.monitoring.enabled: true
|
|
1
|
cluster.name:
|
— произвольное имя
|
1
|
network.host: 0.0.0.0
|
— интерфейс, на котором elastcisearch будет слушать запросы внутри docker-контейнера( а уже через опцию ports в docker-compose.yml файле мы выбрасываем Elasticsearch наружу на нужный нам интерфейс)
|
1
|
xpack.security.enabled: true
|
– включение аутентификации/авторизации в Elasticsearch/Kibana
|
1
|
bootstrap.memory_lock: true
|
– указать для Elasticsearch сразу откусывать/забирать весь размер выделяемой для него оперативной памяти( в нашем случае 4GB)
|
1
|
xpack.monitoring.enabled: true
|
— включение мониторинга Elastcisearch и Kibana
Это позволяет смотреть утилизацию ресурсов, время выполнения запросов к Elasticsearch и другую полезную информацию по ElasticSearch и Kibana
Кроме включения поддержки мониторинга Elasticsearch/Kibana на уровне указанной выше настройки необходимо также произвести непосредственную активацию мониторинга в WEB-интерфейсе Kibana
|
1
|
Kibana->Stack Monitoring
|
В результе появляется страница с базовой информацией о Elasticsearch и Kibana инстансах
Т.к. нода/инстанс с Elasticsearch один и нет кластера, поэтому по умолчанию его статус желтый, а не зеленый.
Более детальная информация о Elasticsearch/Kibana доступны при нажатии на вкладках
|
1
|
Overview/Instances/Nodes/Indices
|
Статистика по Elasticsearch/Kibana хранится в служебных индексах с именами
|
1
2
|
.monitoring-es-7-год.месяц.день
.monitoring-kibana-7-год.месяц.день
|
Для удаления старых индексов можно использовать либо сервис curator либо настроить Index lifecycle policy
Например, в Index Lifecycle Policy (Kibana->Management->Index Lifecycle Policy) создается политика по удалению индексов старше 7 дней:
После чего необходимо назначить это политику на индексные шаблоны
|
1
2
|
Kibana->Management->Index Lifecycle Policy->Policy name->Actions->Add policy to index template->
Select Index template->
|
|
1
2
|
- .monitoring-es
- .monitoring-kibana
|
Таким образом указанные выше служебные индексы по мониторингу Elasticsearch/Kibana старше 7 дней будут автоматически удаляться.
Конфигурационный файл Kibana kibana.yml имеет вид:
|
1
2
3
4
|
server.host: "0"
elasticsearch.hosts: [ "http://elasticsearch:9200" ]
xpack.monitoring.ui.container.elasticsearch.enabled: true
csp.strict: true
|
|
1
|
server.host: "0"
|
— на каком интерфейсе внутри docker-контейнера будет слушать запросы Kibana( в данном случае это аналогично 0.0.0.0 — всем интерфейсам(однако наружу на хост будет выброшен только 127.0.0.1 интерфейс для Kibana(например, можно использовать его через ssh-туннель напрямую подключаясь к Kibana, не используя Caddy-сервис)
|
1
|
elasticsearch.hosts: - ["http://elasticsearch:9200"]
|
– URL, по которому доступен Elastcisearch
|
1
|
xpack.monitoring.ui.container.elasticsearch.enabled: true
|
– включение Cgroup-based мониторинга для Elastcisearch, запущенного в контейнере
https://www.elastic.co/guide/en/kibana/7.2/monitoring-settings-kb.html
|
1
|
csp.strict: true
|
– включение Content Security Policy в Kibana(заблокирует доступ к Kibana с любого браузера, который не обеспечивает даже элементарный набор защит CSP)
https://www.elastic.co/guide/en/kibana/7.2/production.html
3.Настройка аутентификации и авторизации в Elasticsearch/Kibana
1.Генерирование паролей для дефолтных (уже существующих в поставке) пользователей
|
1
|
# docker-compose exec elasticsearch bash
|
|
1
|
[root@db313cef264d elasticsearch]# bin/elasticsearch-setup-passwords auto
|
|
1
2
3
4
5
6
7
8
9
10
11
12
|
Changed password for user elastic
PASSWORD elastic = elasticsearchpassword
Changed password for user kibana
PASSWORD kibana = kibanapassword
Changed password for user apm_system
PASSWORD apm_system = password1
Changed password for user logstash_system
PASSWORD logstash_system = password2
Changed password for user beats_system
PASSWORD beats_system = password3
Changed password for user remote_monitoring_user
PASSWORD remote_monitoring_user = password4
|
Elasticsearch становится доступным с логином/паролем
|
1
2
3
|
http://127.0.0.1:9200/
Login: elastic
Password: elasticsearchpassword
|
Проверка успешной аутентификации
|
1
|
# curl -u elastic:elasticsearchpassword http://127.0.0.1:9200/
|
|
1
|
# curl -u elastic:elasticsearchpassword http://127.0.0.1:9200/_xpack/security/_authenticate?pretty
|
2.Настройка Kibana для аутентификации в Elasticsearch
Заполняем переменные для аутентификации/авторизации в Elasticsearch в .env-файле
|
1
|
# nano .env
|
|
1
2
|
KIBANA_ELASTICSEARCH_USERNAME=kibana
KIBANA_ELASTICSEARCH_PASSWORD=kibanapassword
|
3.Создание и запуск Kibana контейнера
|
1
|
# docker-compose up -d --no-deps kibana
|
|
1
|
# docker-compose logs kibana
|
Заходим в Web-интрефейс Kibana под пользователем elastic и с паролем, сгенерированным ранее(в нашем случае с паролем elasticsearchpassword)
|
1
2
3
|
http://${KIBANA_SERVER_NAME}
Login: elastic
Password: elasticsearchpassword
|
После чего в Kibana->Management появляется меню Security, в котором есть возможность добавлять пользователей и роли
На данном этапе мы создали и запустили следующие контейнеры/сервисы
Elasticsearch, Kibana, Caddy
4.Установка и настройка Cerebro и Curator-сервисов
Для запуска контейнеров Curator и Cerebro нам необходимо создать отдельного пользователя, который будет использоваться этими службами для аутентификации и авторизации в ElasticSearch
Создание служебного пользователя (например, с именем myuser) и назначение ему дефолтной роль superuser
Роль superuser – это существующая в заводской поставке роль с макcимально полными правами
Т.к. эти контейнеры(Cerebro, Curator) запускаются локально, то с точки зрения безопасности приемлемо дать полный доступ для этого пользователя myuser путем назначение ему роли superuser
|
1
|
Kibana->Management->Security->Users->Create user
|
После чего добавляем этого служебного пользователя и пароль в соответствующие переменные в .env-файле
|
1
2
3
4
|
CURATOR_USERNAME=myuser
CURATOR_PASSWORD=myuserpassword
CEREBRO_USERNAME myuser
CEREBRO_PASSWORD=myuserpassword
|
Создание и запуск Cerebro и Curator контейнеров
|
1
|
# docker-compose up -d --no-deps cerebro curator
|
Рассмотрим конфигурацию сервиса Curator
В основном конфигурационном файле curator.yml
указываем подключение к elastcisearch
|
1
2
|
hosts:
- elasticsearch
|
При создании контейнера будет выполнен скрипт docker-entrypoint.sh, в котором происходит замена переменных с логином/паролем для аутентификации в Elasticsearch на их фактические значения. А переменные в контейнер пробрасываются благодаря описанию их в docker-compose.yml файле, который читает значения этих переменных из своего .env-файла
|
1
2
3
|
environment:
CURATOR_USERNAME: ${CURATOR_USERNAME}
CURATOR_PASSWORD: ${CURATOR_PASSWORD}
|
Во втором файле, который используется curator-ом указываются действия, которые необходимо выполнить над индексами
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
1:
action: delete_indices
description: >-
Delete indices older than 14 days (based on index name)
Ignore the error if the filter
does not result in an actionable list of indices
options:
ignore_empty_list: True
disable_action: False
filters:
- filtertype: pattern
kind: prefix
value: '^(nginx-*|php-fpm-*|filebeat-*).*'
- filtertype: age
source: name
direction: older
timestring: '%Y.%m.%d'
unit: days
unit_count: 14
|
В action 1 выполняется удаление всех индексов, попадающих под указанный шаблон и которые были изменены более 14 дней назад
Т.е. логи nginx,php-fpm,mysql(они хранятся в индексе filebeat) храним только за последнии 14 дней
В action 2 выполняется удаление всех индексов, попадающих под указанный шаблон и которые были изменены более 30 дней назад
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
2:
action: delete_indices
description: >-
Delete indices older than 30 days (based on index name)
Ignore the error if the filter
does not result in an actionable list of indices
options:
ignore_empty_list: True
disable_action: False
filters:
- filtertype: pattern
kind: prefix
value: '^(system-*|secure-*|bash-history-*).*'
- filtertype: age
source: name
direction: older
timestring: '%Y.%m.%d'
unit: days
unit_count: 30
|
Т.е. системные логи, логи безопасности и логи с консольными командами храним только за последние 30 дней
Рассмотрим конфигурацию сервиса Cerebro
Подобно сервису Curator, у сервиса Cerebro также
При создании контейнера будет выполнен скрипт docker-entrypoint.sh, в котором происходит замена переменных(username/password) с логином/паролем для аутентификации в Elasticsearch на их фактические значения, которые будут находиться в конфигурационном файле application.conf
Также в этом конфигурационном файле настраивается подключение к Elasticsearch
|
1
2
3
4
5
6
7
8
9
10
|
hosts = [
{
host = "http://elasticsearch:9200"
name = "My Elasticsearch"
auth = {
username = "CEREBRO_USERNAME"
password = "CEREBRO_PASSWORD"
}
}
]
|
5.Создание пользователя fluentd с необходимыми привиллегиями в Elastcisearch, который будет использоваться в Fluentd/Filebeat-агентах для аутентификации/авторизации в Elasticsearch
1.Создание роли с именем fluentd для пользователя fluentd, с которым fluentd-агенты будут авторизовываться в Elasticsearch
|
1
2
3
4
5
6
|
Kibana->Management->Security->Role->Create role
Role name: fluentd
Elasticsearch->
Cluster privilleges->monitor
Если необходима поддержка filebeat, тогда добавляем также следующие кластерные привиллегии
manage_pipeline, manage_ingest_pipelines, manage_ilm, manage_index_templates
|
|
1
2
3
|
Run as Privileges->оставляем пустым
Index privileges->nginx-error-*, php-fpm-*, system-*, nginx-access*,filebeat-*,secure-*,bash_history-*
Privilleges->все кроме All, delete, delete_index
|
В поле Index privileges добавляем все индексы, в которые будут записывать fluentd/filebeat-агенты
(filebeat записывает все свои логии(включая логи MySQL) в один индекс с именем, которое попадает под паттерн filebeat-*
2.Создание пользователя fluentd, с которым fluentd-агенты будут аутентифицироваться и авторизовываться в Elasticsearch
|
1
2
3
4
5
6
|
Kibana->Management->Security->User->Create user
Username: fluentd
Password: mypassword
Confirm password: mypassword
Full name: Fluentd Agent
Roles: fluentd
|
6.Установка и настройка на целевом хосте Fluentd-агента, с помощью которого собираем логи(все логии, кроме mysql-логов)
В качестве fluentd-агента будем использоваться td-agent(стабильный fluentd-агент выпускаемый компание Treasure Data, Inc)
Сравнительная характеристика Fluentd и td-agent
https://www.fluentd.org/faqs
Установка td-agent на RPM/DEB-based дистрибутивах
https://docs.fluentd.org/installation/install-by-rpm
https://docs.fluentd.org/installation/install-by-deb
RPM-based дистрибутив ( в нашем случае Centos 7)
Импортируем ключ,которым подписаны пакеты в репозитарии
|
1
|
# rpm --import https://packages.treasuredata.com/GPG-KEY-td-agent
|
Добавление репозитарий с fluentd-агентом
|
1
2
3
4
5
6
7
|
cat >/etc/yum.repos.d/td.repo <<'EOF'
[treasuredata]
name=TreasureData
baseurl=http://packages.treasuredata.com/3/redhat/\$releasever/\$basearch
gpgcheck=1
gpgkey=https://packages.treasuredata.com/GPG-KEY-td-agent
EOF
|
|
1
|
# cat /etc/yum.repos.d/td.repo
|
|
1
2
3
4
5
|
[treasuredata]
name=TreasureData
baseurl=http://packages.treasuredata.com/3/redhat/\$releasever/\$basearch
gpgcheck=1
gpgkey=https://packages.treasuredata.com/GPG-KEY-td-agent
|
Установка fluentd-агент
|
1
|
# yum install -y td-agent
|
Изменяем дефолтный systemd-unit файл для fluentd-агента
По умолчанию fluentd запускается под пользователем и группой td-agent, которые не имеет право на чтение для лог файлов контейнеров, системных логов и т.д.
Поэтому изменяем владельца/группу, под которыми запускается fluentd-агент на root
|
1
|
# cp /usr/lib/systemd/system/td-agent.service /etc/systemd/system/
|
|
1
|
# sed -i -e 's/User=td-agent/User=root/g' -e 's/Group=td-agent/Group=root/g' /etc/systemd/system/td-agent.service
|
Перечитываем настройки Systemd-демона после изменения systemd-unit-файла
|
1
|
# systemctl daemon-reload
|
Настройка конфигурационного файла fluentd-агента
|
1
|
# nano /etc/td-agent/td-agent.conf
|
[codesyntax lang="php"]
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 |
<source> @type tail @id input_tail_messages <parse> @type syslog </parse> path /var/log/messages pos_file /var/log/td-agent/system.pos read_from_head false tag system.** enable_watch_timer true enable_stat_watcher false </source> <source> @type tail @id input_tail_bash_history <parse> @type syslog </parse> path /var/log/bash_history pos_file /var/log/td-agent/bash-history.pos read_from_head false tag bash.history.** enable_watch_timer true enable_stat_watcher false </source> <source> @type tail @id input_tail_secure <parse> @type syslog </parse> path /var/log/secure pos_file /var/log/td-agent/secure.pos read_from_head false tag secure.** enable_watch_timer true enable_stat_watcher false </source> <filter *.**> @type record_transformer enable_ruby <record> hostname "#{Socket.gethostname}" </record> </filter> <match system.**> @type elasticsearch host es_host port 9200 user fluentd password fluentd_password logstash_format true logstash_prefix system <buffer> @type file path /var/log/td-agent/buffer/system @include out_buffer_params.conf </buffer> </match> <match secure.**> @type elasticsearch host es_host port 9200 user fluentd password fluentd_password logstash_format true logstash_prefix secure <buffer> @type file path /var/log/td-agent/buffer/secure @include out_buffer_params.conf </buffer> </match> <match bash.history.**> @type elasticsearch host es_host port 9200 user fluentd password fluentd_password logstash_format true logstash_prefix bash-history <buffer> @type file path /var/log/td-agent/buffer/bash-history @include out_buffer_params.conf </buffer> </match> # @include web.conf |
[/codesyntax]
Файл с настройками буферизации, подключаемый в основном конфигурационном файле td-agent.conf имеет вид
|
1
|
# nano /etc/td-agent/out_buffer_params.conf
|
|
1
2
3
4
5
6
7
8
9
|
flush_mode interval
retry_type exponential_backoff
flush_thread_count 2
flush_interval 5s
retry_forever
retry_max_interval 30
chunk_limit_size 2M
queue_limit_length 100
overflow_action block
|
Разберем конфигурационный файл /etc/td-agent/td-agent.conf
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<source>
@type tail
@id input_tail_messages
<parse>
@type syslog
</parse>
path /var/log/messages
pos_file /var/log/td-agent/system.pos
read_from_head false
tag system.**
enable_watch_timer true
enable_stat_watcher false
</source>
|
|
1
|
source
|
– источник, с которого считывать логи
|
1
|
@type tail
|
– модуль tail, который используется для чтения файла
|
1
|
@id input_tail_messages
|
– метка этого типа логов(используется в /var/log/td-agent/td-agent.log для удобства отличия различных логов)
|
1
|
parse
|
– модуль парсинга — используем дефолтный модуль syslog
|
1
|
path
|
– файл/файлы с какого/их читать логи
|
1
|
pos_file
|
– расположение и имя служебного файла, в который записывается текущая позиция и имя файла лога, с которого эта позиция была прочитана.
Это позволяет fluentd-агенту мониторить, на какой строке и в каком файле он закончил вычитывание логов
|
1
|
read_from_head
|
– читать ли файп с начало или нет
|
1
|
tag
|
– навешиваем тег на эти логи, что позволяет в дальнейшем на основании тегов направлять логи на различные модули парсинга, на различные типы выводов, проводить различные манипуляции с таким тегированными логами
|
1
|
filter
|
– для всех логов(независимо от тегов) добавляем поле hostname со значением полного доменного имени хоста, с которого fluentd считывает логи(это FQDN автоматически определяется fluentd-агентом)
|
1
2
3
4
5
6
7
|
<filter *.**>
@type record_transformer
enable_ruby
<record>
hostname "#{Socket.gethostname}"
</record>
</filter>
|
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
<match system.**>
@type elasticsearch
host es_host
port 9200
user fluentd
password fluent_password
logstash_format true
logstash_prefix system
<buffer>
@type file
path /var/log/td-agent/buffer/system
@include out_buffer_params.conf
</buffer>
</match>
|
На основе ранее проставленного тега определяем output/вывод куда нужно отправлять логи
|
1
|
@type elasticsearch
|
– отправляем вывод в Elasticsearch
Параметры подключения к Elasticsearch
|
1
2
3
4
|
host es_host
port 9200
user fluentd
password fluentd_password
|
Используем для индексов такой же формат, как и формат в logstash
|
1
|
logstash_format true
|
Имя индекса в Elasticsearch
|
1
|
logstash_prefix system
|
Перед отправкой в Elasticsarch логи собираются во временный буфер, чтобы не отправлять в Elastcisearch каждый event(лог), а выполнять отправку порциями
Тип буфера – файл ( не память, что тоже возможно)
Имя файла определяется параметром path
Параметры буфера подключаем из отдельного файла — @include
|
1
2
3
4
5
|
<buffer>
@type file
path /var/log/td-agent/buffer/system
@include out_buffer_params.conf
</buffer>
|
|
1
|
# cat /etc/td-agent/out_buffer_params.conf
|
|
1
2
3
4
5
6
7
8
9
|
flush_mode interval
retry_type exponential_backoff
flush_thread_count 2
flush_interval 5s
retry_forever
retry_max_interval 30
chunk_limit_size 2M
queue_limit_length 100
overflow_action block
|
Отправляет логи в Elastiсsearch каждые 5 секунд.
При недоступности Elasticsearch Fluentd пытается подключиться к нему с интервалом экспоненциально увеличивающимся до 30 секунд.
Если Elasticsearch не доступен — продолжает читать файл и складывает порции данных до установленного предела, достиг предела, останавливает чтение файла и запоминает позицию. При восстановлении связи с Elasticsearch Fluentd-агент начинает передачу собравшихся данных и возобновляет чтение файла с места остановки
Для сбора логов с Nginx и PHP-FPM контейнеров с этого сервера, необходимо расскомментировать строку
|
1
|
@include web.conf
|
и создать файл web.conf с таким содержанием
[codesyntax lang="php"]
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 |
<source> @type tail @id input_tail_nginx_error <parse> @type regexp expression ^(?<mytime>.*)\s(?<type>\[\w+\])\s(?<pid>\d+#\d+):\s(?<log>[^ ].*) </parse> path /path/to/nginx/error.log pos_file /var/log/td-agent/nginx-error.pos read_from_head true tag nginx.error.** enable_watch_timer true enable_stat_watcher false </source> <source> @type tail @id input_tail_containers path /var/lib/docker/containers/*/*.log pos_file /var/log/td-agent/docker.pos read_from_head false tag docker.** skip_refresh_on_startup false refresh_interval 10s enable_watch_timer true enable_stat_watcher false <parse> @type json time_format %Y-%m-%dT%H:%M:%S.%NZ </parse> </source> <filter docker.var.lib.docker.containers.*.*.log> @type record_transformer enable_ruby <record> container ${tag.split('.')[5]} name ${id = tag.split('.')[5]; JSON.parse(IO.read("/var/lib/docker/containers/#{id}/config.v2.json"))['Name']} </record> </filter> <match docker.var.lib.docker.containers.*.*.log> @type rewrite_tag_filter <rule> key name pattern /nginx/ tag docker.nginx.access </rule> <rule> key name pattern /php-fpm/ tag docker.php-fpm.access </rule> </match> <match docker.var.lib.docker.containers.*.*.log> @type null </match> <filter docker.php-fpm.access.**> @type parser key_name log <parse> @type regexp expression (?<remote_host>.*)\s(?<username>-)\s(?<mytime>.*)\s"(?<method>\w{3,7})\s(?<request_uri>.*)"\s(?<status>\d{3}) </parse> </filter> <filter docker.nginx.access.**> @type parser key_name log format /(?<remot_host>.*)\s\[(?<time>.*)\]\s"(?<method>\w{3,7})\s(?<request_uri>.*)\s(?<http_version>.*)"\s(?<status>\d{3})\s(?<bytes_sent>.*)\s"(?<http_referer>.*)"\s(?<request_time>\d+.\d+)\s(?<upstream_connect_time>.*)\s(?<upstream_header_time>.*)\s(?<upstream_response_time>.*)\s(?<http_x_forwarded_for>.*)\s"(?<http_user_agent>.*)"/ time_format %d/%b/%Y:%H:%M:%S %z </filter> <filter *.**> @type record_transformer enable_ruby <record> hostname "#{Socket.gethostname}" </record> </filter> <match nginx.error.**> @type elasticsearch host es_host port 9200 user fluentd password fluentd_password logstash_format true logstash_prefix nginx-error <buffer> @type file path /var/log/td-agent/buffer/nginx-error @include out_buffer_params.conf </buffer> </match> <match docker.nginx.access.**> @type elasticsearch host es_host port 9200 user fluentd password fluentd_password logstash_format true logstash_prefix nginx-access <buffer> @type file path /var/log/td-agent/buffer/nginx-access @include out_buffer_params.conf </buffer> </match> <match docker.php-fpm.access.**> @type elasticsearch host es_host port 9200 user fluentd password fluentd_password logstash_format true logstash_prefix php-fpm <buffer> @type file path /var/log/td-agent/buffer/php-fpm @include out_buffer_params.conf </buffer> </match> |
[/codesyntax]
Разберем содержимое файла web.yml
Парсим nginx error.log с помощью модуля regexp
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
<source>
@type tail
@id input_tail_nginx_error
<parse>
@type regexp
expression ^(?<mytime>.*)\s(?<type>\[\w+\])\s(?<pid>\d+#\d+):\s(?<log>[^ ].*)
</parse>
path /path/to/nginx/error.log
pos_file /var/log/td-agent/nginx-error.pos
read_from_head true
tag nginx.error.**
enable_watch_timer true
enable_stat_watcher false
</source>
|
Fluentd-редактор регулярных выражений
http://fluentular.herokuapp.com
Читаем логи ВСЕХ контейнеров,навешиваем на них тег(docker.**)
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
<source>
@type tail
@id input_tail_containers
path /var/lib/docker/containers/*/*.log
pos_file /var/log/td-agent/docker.pos
read_from_head false
tag docker.**
skip_refresh_on_startup false
refresh_interval 10s
enable_watch_timer true
enable_stat_watcher false
<parse>
@type json
time_format %Y-%m-%dT%H:%M:%S.%NZ
</parse>
</source>
|
Добавлям новые поля с идентификатором контейнера(container) и его именем(name)
со значениями этих полей, которые динамически определяются в результате парсинга докер-лог файла config.v2.json для каждого контейнера
|
1
2
3
4
5
6
7
8
9
|
<filter docker.var.lib.docker.containers.*.*.log>
@type record_transformer
enable_ruby
<record>
container ${tag.split('.')[5]}
name ${id = tag.split('.')[5]; JSON.parse(IO.read("/var/lib/docker/containers/#{id}/config.v2.json"))['Name']}
#hostname "#{Socket.gethostname}"
</record>
</filter>
|
Добавляем соответствуюшие теги (docker.nginx.access или tag docker.php-fpm.access) для логов с контейнеров nginx и php-fpm соответственно благодаря ранее установленному полю с именем контейнера. Именно по этому полю и определяем, с какого контейнера поступил лог
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<match docker.var.lib.docker.containers.*.*.log>
@type rewrite_tag_filter
<rule>
key name
pattern /nginx/
tag docker.nginx.access
</rule>
<rule>
key name
pattern /php-fpm/
tag docker.php-fpm.access
</rule>
</match>
|
Все остальные логи не nginx и не php-fpm контейнеров удаляем(т.к. они имеют теги, которые и попадают под нижеуказанный шаблон)
|
1
2
3
|
<match docker.var.lib.docker.containers.*.*.log>
@type null
</match>
|
Парсинг лога php-fpm контейнера(на основе ранее установленного тега docker.php-fpm.access)
|
1
2
3
4
5
6
7
8
|
<filter docker.php-fpm.access.**>
@type parser
key_name log
<parse>
@type regexp
expression (?<remote_host>.*)\s(?<username>-)\s(?<mytime>.*)\s"(?<method>\w{3,7})\s(?<request_uri>.*)"\s(?<status>\d{3})
</parse>
</filter>
|
Парсинг лога nginx access-лога контейнера nginx на основе ранее установленного тега docker.nginx.access)
|
1
2
3
4
5
6
|
<filter docker.nginx.access.**>
@type parser
key_name log
format /(?<remot_host>.*)\s\[(?<time>.*)\]\s"(?<method>\w{3,7})\s(?<request_uri>.*)\s(?<http_version>.*)"\s(?<status>\d{3})\s(?<bytes_sent>.*)\s"(?<http_referer>.*)"\s(?<request_time>\d+.\d+)\s(?<upstream_connect_time>.*)\s(?<upstream_header_time>.*)\s(?<upstream_response_time>.*)\s(?<http_x_forwarded_for>.*)\s"(?<http_user_agent>.*)"/
time_format %d/%b/%Y:%H:%M:%S %z
</filter>
|
Далее все по аналогии с вышеописанным системным логом
Формат Nginx-access-логов контейнера имеет вид
|
1
2
3
4
|
log_format main '$remote_addr [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'$request_time $upstream_connect_time $upstream_header_time $upstream_response_time '
'$http_x_forwarded_for "$http_user_agent"';
|
Добавлены полезные заголовки при подключении к upstream/backend-части
Проверка синтаксиса конфигурационного файла td-agent.conf
|
1
|
# /etc/init.d/td-agent configtest
|
Запуск fluentd-агента
|
1
|
# systemctl start td-agent
|
Настройка ротации логов fluentd-агента
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
cat > /etc/logrotate.d/td-agent <<'EOF'
/var/log/td-agent/td-agent.log {
daily
rotate 7
compress
#delaycompress
notifempty
create 644 td-agent td-agent
sharedscripts
postrotate
pid=/var/run/td-agent/td-agent.pid
if [ -s "$pid" ]
then
kill -USR1 "$(cat $pid)"
fi
endscript
}
EOF
|
Просмотр логов fluentd-агента
|
1
|
# tail -n 200 -f /var/log/td-agent/td-agent.log
|
|
1
|
# journalctl -n 200 -f -u td-agent
|
Установка и настройка fluent-агента на DEB-based дистрибутив ( в нашем случае Ubuntu 18.04)
|
1
|
# curl https://packages.treasuredata.com/GPG-KEY-td-agent | apt-key add -
|
|
1
|
# echo "deb http://packages.treasuredata.com/3/ubuntu/bionic/ bionic contrib" > /etc/apt/sources.list.d/treasure-data.list
|
|
1
|
# apt-get update && apt-get install -y td-agent
|
|
1
|
# cp /opt/td-agent/etc/systemd/td-agent.service /etc/systemd/system/td-agent.service
|
|
1
|
# sed -i -e 's/User=td-agent/User=root/g' -e 's/Group=td-agent/Group=root/g' /etc/systemd/system/td-agent.service
|
|
1
|
# systemctl daemon-reload
|
Содержимое конфигурационного файла fluentd-агента td-agent.conf аналогично указанному выше, за исключением имен системных файлов специфических для DEB-based-дистрибутивов
|
1
|
# nano /etc/td-agent/td-agent.conf
|
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<source>
@type tail
@id input_tail_messages
…
path /var/log/syslog
…
</source>
<source>
@type tail
@id input_tail_secure
…
path /var/log/auth.log
…
</source>
|
Проверка синтаксиса конфигурационного файла td-agent.conf
|
1
|
# /etc/init.d/td-agent configtest
|
Запуск fluentd-агента
|
1
|
# systemctl start td-agent
|
Настройка сбора логов выполненных команд – bash history
Настроим перехват выполненных всеми пользователями консольных команд и запись их в отдельный файл ,с которого fluentd-агент будет читать логи и отправлять их в Elasticsearch
Для этого в системном/глобальном /etc/profile.d каталоге создается файл, который будет перехватывать выполненные в консоли команды и отправлять их в rsyslog ( в locale1) с уровнем важности notice
А rsyslog-настроим на отправку этих логов в файл /var/log/bash_history
Для RPM-based-дистрибутивов необходимо выполнить скрипт
|
1
|
# cat logging.sh
|
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
#!/usr/bin/env bash
cat <<'EOF' > /etc/profile.d/logging.sh
function history_to_syslog
{
declare command
command=$(fc -ln -0)
if [ "$command" != "$old_command" ]; then
who=$(whoami)
cmd=$(history 1)
TTY=`tty`
HISNAME="`basename $TTY`"
ip=`who |grep pts/${HISNAME} |cut -f 2 -d \(|cut -f 1 -d \)`
logger -p local1.notice -t bash[$$] -- IP=$ip, USER=$who, PWD=$PWD, CMD=$command
fi
old_command=$command
}
trap history_to_syslog DEBUG
EOF
cat <<EOF > /etc/rsyslog.d/50-logging.conf
local1.notice /var/log/bash_history
EOF
touch /var/log/bash_history && chmod 600 /var/log/bash_history && chown root:root /var/log/bash_history
systemctl restart rsyslog
systemctl status rsyslog
|
Для DEB-based-дистрибутивов необходимо выполнить скрипт
|
1
|
# cat logging.sh
|
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
#!/usr/bin/env bash
cat <<'EOF' > /etc/profile.d/logging.sh
function history_to_syslog
{
declare command
command=$(fc -ln -0)
if [ "$command" != "$old_command" ]; then
who=$(whoami)
cmd=$(history 1)
TTY=`tty`
HISNAME="`basename $TTY`"
ip=`who |grep pts/${HISNAME} |cut -f 2 -d \(|cut -f 1 -d \)`
logger -p local1.notice -t bash[$$] -- IP=$ip, USER=$who, PWD=$PWD, CMD=$command
fi
old_command=$command
}
trap history_to_syslog DEBUG
EOF
cat <<EOF > /etc/rsyslog.d/60-logging.conf
local1.notice /var/log/bash_history
EOF
touch /var/log/bash_history && chmod 600 /var/log/bash_history && chown syslog:syslog /var/log/bash_history
systemctl restart rsyslog
systemctl status rsyslog
|
Добавление cron-заданий на хостах
Также на каждом хосте, с которого собираются логи рекомендую добавить следующие cron-задания
— удаление служебных sigdump-файлов с каталога /tmp (их создает fluentd)
— очистка файла с выполненными командами /var/log/bash_history
— рестарт fluentd-агент, если существуют файлы в модификацией больше 2-х минут
(Иногда fluentd-агент не может передать логи на Elastcisearch c ошибкой в своих логах о том, что не может покдлючиться к Elasticsearch, при этом, если вручную проверить доступность Elastcisearch c fluentd-хоста, то поделючение успешно (curl -u fluentd:fluentd_password http://:9200)
Примечательно,что простой перезапуск fluentd-агента тут же приводит к успешному подключению к Elasticsearch и отправки ему всех накопившихся логов)
|
1
|
# cat /var/spool/cron/root
|
|
1
2
3
4
5
6
7
8
|
### Delete td-agent sigdump-files
15 2 * * * find /tmp -type f -name "sigdump-[0-9]*.log" -exec rm {} \; > /dev/null 2>&1
### Clean up /var/log/bash_history file
15 2 * * * if [ -f /var/log/bash_history ]; then cat /dev/null > /var/log/bash_history; fi > /dev/null 2>&1
### Td-agent restart
*/5 * * * * /bin/bash /home/myuser/scripts/td-agent/restart_td_agent.sh > /dev/null 2>&1
|
|
1
|
# cat /home/devops/scripts/td-agent/restart_td_agent.sh
|
|
1
2
3
4
5
6
7
8
9
|
#!/bin/bash
DATE="$(date +"%Y-%m-%d_%H:%M")"
FILE_COUNT="$(find /var/log/td-agent/buffer/ -type f -mmin +2 | wc -l)"
if [ ${FILE_COUNT} -gt 0 ];
then
systemctl restart td-agent
echo "$DATE: td-agent was restarted" >> /tmp/td-agent.txt
fi
|
7.Установка и настройка на целевом хосте Filebeat-агента, с помощью которого собираем только MySQL error/slow-логи
В данном случае используем версию filebeat 7.2 т.к. Elasticsearch имеет такую версию
Установка filebeat-агент для RPM-based дистрибутивов
|
1
|
# rpm -ivh https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.2.0-x86_64.rpm
|
Установка filebeat-агента для DEB-based дистрибутивов
|
1
|
# curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.2.0-amd64.deb
|
|
1
|
# dpkg -i filebeat-7.2.0-amd64.deb
|
Настройка основного конфигурационного файла filebeat /etc/filebeat/filebeat.yml
|
1
|
# cp /etc/filebeat/filebeat.yml /etc/filebeat/filebeat.yml-original
|
Все поддерживаемые filebeat-ом опции доступны в отдельном файле
|
1
|
/etc/filebeat/filebeat.reference.yml
|
В дефолтном конфигурационного файла filebeat.yml были сделаны следующие изменения
|
1
|
# nano /etc/filebeat/filebeat.yml
|
Настроено подключение к elasticsearch
|
1
2
3
4
5
6
7
8
|
output.elasticsearch:
# Array of hosts to connect to.
hosts: ["es_host:9200"]
# Optional protocol and basic auth credentials.
#protocol: "https"
username: "fluentd"
password: "fluentd_password"
|
Отключена Index Lifecycle policy
|
1
2
3
|
#============================== Setup ILM =====================================
### Disable Index lifecycle policy
setup.ilm.enabled: false
|
Отключено логирование метрик
|
1
2
3
|
#================================ Logging ======================================
### Disable logging filebeat internal metrics
logging.metrics.enabled: false
|
Чтобы в логах filebeat не было записей типа
|
1
|
Jan 21 18:20:38 myhostname filebeat[28728]: 2020-01-21T18:20:38.818+0200 INFO [monitoring] log/log.go:145 Non-zero metrics in the last 30s {"monitoring": {"metrics": {"beat":{"cpu":{"system":{"ticks":700},"total":{"ticks":1670,"time":{"ms":16},"value":1670},"user":{"ticks":970,"time":{"ms":16}}},"handles":{"limit":{"hard":4096,"soft":1024},"open":7},"info":{"ephemeral_id":"22313d81-60cf-4ccf-985f-be5b5289b12a","uptime":{"ms":5190025}},"memstats":{"gc_next":4194304,"memory_alloc":2334840,"memory_total":73692712},"runtime":{"goroutines":39}},"filebeat":{"harvester":{"open_files":0,"running":0}},"libbeat":{"config":{"module":{"running":0}},"pipeline":{"clients":4,"events":{"active":0}}},"registrar":{"states":{"current":2}},"system":{"load":{"1":0.04,"15":0.12,"5":0.09,"norm":{"1":0.0025,"15":0.0075,"5":0.0056}}}}}}
|
Запрещено переписывать уже существующий шаблон (это и так дефолтная опция, но я также ее определил и принудительно)
|
1
2
3
|
#============================== Template =====================================
# Overwrite existing template
setup.template.overwrite: false
|
Немного подробнее про Index Lifecycle Policy для индексов
Начиная с 7-й версии Elastcisearch имеет политику индексов с rollover — создается политика rollover индексов больше 50 GB и/или старше 30 дней
Filebeat 7-й версии имеет дефолтную настройку на автоопределение и автовключение (если существует такая политика в Elastcisearch) благодаря своим настройкам
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
# Configure Index Lifecycle Management Index Lifecycle Management creates a
# write alias and adds additional settings to the template.
# The elasticsearch.output.index setting will be replaced with the write alias
# if ILM is enabled.
# Enabled ILM support. Valid values are true, false, and auto. The beat will
# detect availabilty of Index Lifecycle Management in Elasticsearch and enable
# or disable ILM support.
#setup.ilm.enabled: auto
# Configure the ILM write alias name.
#setup.ilm.rollover_alias: "filebeat"
# Configure rollover index pattern.
#setup.ilm.pattern: "{now/d}-000001"
|
В результате чего создаются индексы в формате
|
1
|
filebeat-%{[agent.version]}-<порядковый_номер>
|
Меня не устроил такой формат
Мне больше подошел формат с созданием ежесуточного индекса без каких-либо политик (дефолтное поведение filebeat до версии 7)
В результате чего формат индекса должен иметь вид
|
1
|
filebeat-%{[agent.version]}-год.месяц.день
|
Поэтому я отключил такую политику
|
1
|
# nano /etc/filebeat/filebeat.yml
|
|
1
2
|
### Disable Index lifecycle policy
setup.ilm.enabled: false
|
Включение модуля MySQL для сбора MySQL логов ошибок(error.log) и медленных логов(slow.log)
|
1
|
# filebeat modules enable mysql
|
Настройка конфигурационного файла MySQL-модуля в виде указания лога с ошибками и лога медленных запросов
|
1
|
# nano /etc/filebeat/modules.d/mysql.yml
|
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
# Module: mysql
# Docs: https://www.elastic.co/guide/en/beats/filebeat/7.2/filebeat-module-mysql.html
- module: mysql
# Error logs
error:
enabled: true
# Set custom paths for the log files. If left empty,
# Filebeat will choose the paths depending on your OS.
var.paths: ["/path/to/mysql/error.log"]
# Slow logs
slowlog:
enabled: true
# Set custom paths for the log files. If left empty,
# Filebeat will choose the paths depending on your OS.
var.paths: ["/path/to/mysql/slow.log"]
|
Проверка синтаксиса конфигурационного файла filebeat
|
1
|
# filebeat test config -e
|
Запуск, проверка состояния и добавление в автозагрузку filebeat-агента
|
1
|
# systemctl start filebeat
|
|
1
|
# systemctl status filebeat
|
|
1
|
# systemctl enable filebeat
|
Просмотр логов filebeat-агента
|
1
|
# journalctl -n 200 -u filebeat -f
|
После запуска filebeat и создания индекса с именем filebeat-7.2-год.месяц.день
Необходимо отредактировать шаблон filebeat-%{[agent.version]}( в нашем случае filebeat-7.2) удаляя из него политику
Например, начало индексного шаблона имеет вид
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
{
"order": 1,
"index_patterns": [
"filebeat-7.2.0-*"
],
"settings": {
"index": {
"lifecycle": {
"name": "filebeat-7.2.0",
"rollover_alias": "filebeat-7.2.0"
},
"mapping": {
"total_fields": {
"limit": "10000"
}
},
|
Удаляем блок с политикой
|
1
2
3
4
|
"lifecycle": {
"name": "filebeat-7.2.0",
"rollover_alias": "filebeat-7.2.0"
},
|
После чего все вновь создаваемые индексы будут попадать под обновленный индексный шаблон(в котором уже нет политики по rollover)
Для уже созданных индексов(если они создавались с поддержкой index lifecycle policy) нужно вручную удалить политику из этих индексов (назначенную автоматически при попадании индекса в индексный шаблон, на который была установлена политика)
|
1
|
Kibana->Management->Index Management->Index name->Manage index->Delete lifecycle policy
|
Загрузка дефолтных посиков, визуализаций, дашбордов из filebeat в Kibana
Filebeat поставляется с примерами поисков, визуализаций и дашбордов для визуализации данных Filebeat в Kibana
При первом знакомстве с Filebeat очень полезно включить загрузку дефолтных поисков, визуализаций и дашбордов в Kibana
Такую загрузку можно выполнить либо через команду
|
1
|
# filebeat setup --dashboards
|
либо настроить загрузку в файле конфигурации filebeat.yml
|
1
2
3
4
5
|
#============================== Dashboards =====================================
# These settings control loading the sample dashboards to the Kibana index. Loading
# the dashboards are disabled by default and can be enabled either by setting the
# options here, or by using the `-setup` CLI flag or the `setup` command.
#setup.dashboards.enabled: false
|
В любом случае, предварительно в конфиге filebeat.yml необходимо настроить подключение к kibana
|
1
2
3
4
5
6
7
8
9
10
11
|
#============================== Kibana =====================================
# Starting with Beats version 6.0.0, the dashboards are loaded via the Kibana API.
# This requires a Kibana endpoint configuration.
setup.kibana:
# Kibana Host
# Scheme and port can be left out and will be set to the default (http and 5601)
# In case you specify and additional path, the scheme is required: http://localhost:5601/path
# IPv6 addresses should always be defined as: https://[2001:db8::1]:5601
#host: "localhost:5601"
|
https://www.elastic.co/guide/en/beats/filebeat/7.2/load-kibana-dashboards.html
Размещение дополнительных файлов filebeat
|
1
|
/usr/share/filebeat/kibana/
|
— отсюда загружаются дашбоарды в Kibana
|
1
|
/usr/share/filebeat/module/
|
— дефолтная настройка модулей
|
1
|
/var/lib/filebeat/registry/filebeat/
|
— реестр с хранением служебной информации для отслеживаемых файлов(с которых собираются логи)
Filebeat уже содержит MySQL-дашбоард с логами ошибок и логами медленных запросов MySQL
Также в Kibana были созданы поиски, визуализации, дашбоарды на основе данных из индексов в Elasticsearch
На основом дашбоарде были сведены все остальные дашбоарды
Например Nginx-base дашбоард включает в себя несколько визуализаций
