Суть задачи сводится к тому, чтобы добавить новое поле в index elasticsearch, в котором будет содержаться id сессии пользователя в простом текстовом виде. Далее по этому полю можно будет делать группировку, чтобы посмотреть перемещение пользователя по сайту и другую информацию о его запросах.

Для того, чтобы организовать просмотр перемещения посетителя по сайту, нам необходимо выводить в лог apache информацию об этой сессии и реальном ip адресе клиента. Рассказываю далее, как все это сделать.

Я буду показывать настройку на примере сайта на Bitrix. В WordPress все это настраивается точно так же, один в один.

Реальный ip адрес посетителя bitrix в логах apache

Если вы используете преднастроенное окружение bitrixenv, то ничего особенного для вывода реального ip адреса в лог apache делать не надо. Напомню, для тех, кто не в курсе, о чем идет речь. Bitrixenv — набор рецептов ansible, которые автоматически разворачивают веб сервер на основе nginx и apache. На nginx приходят все запросы клиентов, а дальше проксируются на apache для исполнения php кода. Если ничего дополнительно не настраивать, то в логах apache все запросы будут с ip адреса 127.0.0.1.

При этом, в bitrixenv в настройках nginx для сайтов указано, что реальный ip адрес посетителя надо записывать в отдельный заголовок.

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

В apache можно взять информацию из этого заголовка и поместить сразу в лог файл.

LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

Все, этого достаточно, чтобы в лог файле apache выводился реальный ip адрес посетителя. Теперь разберемся с session id.

Вывод Session ID посетителя Битрикс в лог apache

Каждому посетителю сайта на Битриксе прописывается в Cookie PHPSESSID с уникальным идентификатором сеанса. Он остается постоянным в рамках одного посещения. По крайней мере на первый взгляд это так. Я не занимался подробно исследованием того, как это работает. Задачи не стояло.

Host: 10.20.1.5
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://10.20.1.5/photo/
Cookie: BITRIX_SM_GUEST_ID=2; BITRIX_SM_LAST_VISIT=22.04.2020+15%3A19%3A08; BITRIX_CONVERSION_CONTEXT_s1=conversion_visit_day; PHPSESSID=f62568ad389b9ef0bba3c6d3650f7155; BITRIX_SM_SOUND_LOGIN_PLAYED=Y
Upgrade-Insecure-Requests: 1
Pragma: no-cache
Cache-Control: no-cache

Идентификатор PHPSESSID мы и будем выводить в лог файл apache. Сделать это очень просто, так как apache по умолчанию умеет анализировать куки и выводить информацию из них в лог. Делается это вот так.

LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %{PHPSESSID}C" combined

Если хотите вывести в лог все содержимое куки, то используйте такую конструкцию — %{Cookie}i. В нашем случае это излишне. Хватит только PHPSESSID. Перезапускаем apache и смотрим, что у нас будет в логе.

10.20.1.1 - - [22/Apr/2020:15:45:59 +0300] "GET / HTTP/1.0" 200 47747 "http://10.20.1.5/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0" f62568ad389b9ef0bba3c6d3650f7155

IP адрес и ID сессии присутствуют в логе. В данном случае ip адрес серый, потому что тестовое окружение настроено в локальной сети. Теперь нам нужно настроить grok фильтр elastic на парсинг измененного лог файла. Затем добавить новое поле в индекс elasticsearch, чтобы с ним можно было работать.

Добавление произвольного поля в Elastic Cloud

Перемещаемся в Kibana. Первым делом проверим, какой pipeline для обработки логов загружен в Elasticsearch. Для этого идем в интерфейс Kibana, в раздел Dev Tools -> Console и вводим туда запрос

GET _ingest/pipeline/filebeat-*access*

Запоминаем точное название пайплайна — filebeat-7.6.2-apache-access-default. Напоминаю, что такое pipeline. Мы используем легковесный filebeat для передачи логов в elastic. В отличие от logstash, filebeat сам не умеет выполнять сложный парсинг логов на основе grok фильтров. Этим занимается сама нода elastic на основе pipeline, который ей передает filebeat.

Теперь идем на целевой сервер, где работает apache и filebeat. Дефолтный pipeline должен располагаться в файле /usr/share/filebeat/module/apache/access/ingest/default.json. Необходимо проверить, что его содержимое соответствует тому, что было в выводе в консоли Kibana. В дефолтной установке это должно быть так.

Нам нужно изменить этот pipeline. Для этого останавливаем filebeat.

# systemctl stop filebeat

Редактируем default.json, предварительно сохранив копию исходного файла на всякий случай.

Берем следующий блок:

          "grok": {
              "field": "message",
              "patterns": [
                  "%{IPORHOST:destination.domain} %{IPORHOST:source.ip} - %{DATA:user.name} \\[%{HTTPDATE:apache.access.time}\\] \"(?:%{WORD:http.request.method} %{DATA:url.original} HTTP/%{NUMBER:http.version}|-)?\" %{NUMBER:http.response.status_code:long} (?:%{NUMBER:http.response.body.bytes:long}|-)( \"%{DATA:http.request.referrer}\")?( \"%{DATA:user_agent.original}\")?",
                  "%{IPORHOST:source.address} - %{DATA:user.name} \\[%{HTTPDATE:apache.access.time}\\] \"(?:%{WORD:http.request.method} %{DATA:url.original} HTTP/%{NUMBER:http.version}|-)?\" %{NUMBER:http.response.status_code:long} (?:%{NUMBER:http.response.body.bytes:long}|-)( \"%{DATA:http.request.referrer}\")?( \"%{DATA:user_agent.original}\")?",
                  "%{IPORHOST:source.address} - %{DATA:user.name} \\[%{HTTPDATE:apache.access.time}\\] \"-\" %{NUMBER:http.response.status_code:long} -",
                  "\\[%{HTTPDATE:apache.access.time}\\] %{IPORHOST:source.address} %{DATA:apache.access.ssl.protocol} %{DATA:apache.access.ssl.cipher} \"%{WORD:http.request.method} %{DATA:url.original} HTTP/%{NUMBER:http.version}\" (-|%{NUMBER:http.response.body.bytes:long})"
              ],

И приводим его к следующему виду:

          "grok": {
              "field": "message",
              "patterns": [
                  "%{IPORHOST:source.address} - %{DATA:user.name} \\[%{HTTPDATE:apache.access.time}\\] \"(?:%{WORD:http.request.method} %{DATA:url.original} HTTP/%{NUMBER:http.version}|-)?\" %{NUMBER:http.response.status_code:long} (?:%{NUMBER:http.response.body.bytes:long}|-)( \"%{DATA:http.request.referrer}\")?( \"%{DATA:user_agent.original}\")? ?%{WORD:session_id}"
              ],

Важно соблюдать структуру файла, все табуляции, отступы и пробелы.

Мы добавили в конец новое поле для парсинга через встроенный grok фильтр ?%{WORD:session_id} и удалили лишние фильтры, которые нужны для совместимости с разными версиями apache. Предложенный фильтр проверен на версии Apache/2.4.6 и его стандартном формате логов, плюс текстовое поле с сессией.

Так же для удобства рекомендую удалить строки ниже:

      {
          "remove": {
              "field": "message"
          }
      },

Тогда в elastic будут в том числе сохраняться строки из лога в оригинальном виде, а не только распарсенные значения. Это бывает полезно для разбора полетов. По-умолчанию они удаляются для экономии места.

Теперь возвращаемся в консоль Kibana и удаляем текущий pipeline из elastic, так как мы туда загрузим новый.

DELETE _ingest/pipeline/filebeat-7.6.2-apache-access-default

Идем на сервер и запускаем filebeat

# systemctl start filebeat

Смотрим его лог на наличие ошибок. Их быть не должно. Если есть, то надо проверять внимательно default.json, не нарушен ли его формат при редактировании. Расположение пробелов и отступов важно. При проверке статуса сервиса ошибок быть не должно.

# systemctl status filebeat

Видим, что новый pipeline загружен. Идем в консоль Kibana и проверяем, что это так.

GET _ingest/pipeline/filebeat-7.6.2-apache-access-default

Идем в Discovery и проверяем наличие нового поля session_id. Рядом с ним должен быть восклицательный знак.

Идем в Management -> Kibana -> Index Patterns. Выбираем индекс filebeat-* и жмем справа вверху на обновление — refresh field list.

После этого тут же проверяем через поиск, что в индексе появилось новое поле session_id.

Теперь можно вернуться в Discovery и осуществлять поиск по полю session_id.

На этом все. Новое поле в elasticsearch добавлено. Можно использовать в визуализациях и дашбордах.

Часто задаваемые вопросы по теме статьи (FAQ)

Подойдет ли этот же grok фильтр для парсинга логов в logstash?

Да, подойдет. Формат grok фильтров одинаков и в ingest node, где в данном случае происходит обработка логов, и в logstash.Есть ли разница в настройке Elastic Cloud и собственного ELK сервера?

Принципиальной разницы в настройке нет. Это абсолютно одинаковые продукты. Первый развернут в публичном облаке, второй на ваших собственных серверах.Будут ли корректно обрабатываться логи, если в них не будет присутствовать запись с session id?

Да, будут. В фильтре перед %{WORD:session_id} стоит вопросительный знак, который делает необязательным наличие этой строки в логе.

Сообщение Добавление произвольного поля в Elastic на примере session_id в Bitrix появились сначала на Clip-Clap.

У меня есть целый цикл статей про настройку и эксплуатацию ELK Stack для сбора логов с различных приложений. Так же я подробно рассказал, как установить и настроить ELK Stack себе, если у вас есть под него мощности и компетенции. В целом, там нет чего-то сильно сложного, но тем не менее, все равно необходимо повозиться, чтобы все заработало.

Не обязательно все это разворачивать и настраивать у себя, если хочется просто попробовать продукт, чтобы понять, нужен он вам или нет. Есть сервис — https://cloud.elastic.co, где можно за 2 минуты зарегистрировать и развернуть свой стэк на базе Elasticsearch и Kibana. Отличие от описанного мной способа разворачивания стека в том, что тут не будет Logstash. Во многих случаях можно обойтись без него, так что это не критично. Особенно для того, чтобы просто попробовать.

Итак, прежде чем приступить к настройке, зарегистрируйтесь в облаке и активируйте учетную запись.

Запуск Elastic Stack в Elastic Cloud

При первом входе в личный кабинет у вас будет возможность создать Deployment с Elasticsearch.

Дальше нужно выбрать платформу, где вы хотите произвести установку сервиса, и регион. Я для теста выбрал Google Cloud Platform во Frankfurt. Все остальное оставил по дефолту. Дальше внизу жмете Create Deployment и ждете, когда он развернется. Обычно 2-3 минуты.

Дожидаемся окончание процесса установки и переходим в Kibana.

Логинимся в Kibana с учетными данными, которые указаны в личном кабинете, в Deployment. Username обычно elastic и какой-то пароль. При первом входе вам предложат залить набор демо данных, чтобы посмотреть функционал системы. Если хотите — посмотрите. Я там и так все видел, поэтому отказываюсь Буду лить свои логи от apache.

После выбора оказываетесь на главной странице Kibana. По сути Elastic Stack вы уже развернули и он готов принимать данные. Вот так, быстро и просто все настроилось. И DevOps не нужен

Можете тут осмотреться и познакомиться с системой.

Сбор логов через Filebeat в Elasticsearch

В качестве примера возьму, как обычно, свой «любимый» bitrix. Так выходит, что работать с ним приходится довольно часто, так что использую его в своих статьях в качестве примера.

Итак, у нас развернут Bitrixenv для любого битрикс сайта. Система — Centos 7, логи будем собирать с веб сервера Apache. Для Nginx никакой разницы не будет, так как дефолтный формат логов у них один и тот же.

Нам необходимо установить на сервер filebeat и настроить его на отправку логов в наш кластер. Инструкция, как это сделать, есть в самой Kibana. Для этого идите на главную страницу и выберите Add log data.

Далее выбирайте Apache Logs и вкладку RPM.

Ниже будет подробная инструкция о том, как настроить отправку логов через filebeat в Elastic. Идем на сервер и ставим filebeat.

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

Открываем конфигурационный файл /etc/filebeat/filebeat.yml и указываем реквизиты доступа, как они показаны в Kibana.

cloud.id: ":ZXVyb3BlLXdlc3QzLmdjcC5jbG91ZC5lcy5pbyRiNLPeRmNlODBkNzY0OTYxODk3YWVmZGZlNmI1ZWVjYyQ0NjdjOTQzNGJlYjk0YTk1YjBmYTQ5ZWQ4NTdkMzYzMA=="
cloud.auth: "elastic:5344qwZjFyM9Q23THCuMxcSm"

Активируем модуль для apache.

# filebeat modules enable apache

Если у вас логи располагаются в дефолтном месте — /var/log/httpd/access_log и error_log, то больше ничего делать не надо. Если где-то в другом месте или с другими именами, то укажите до них путь в конфиге /etc/filebeat/modules.d/apache.yml примерно так:

- module: apache
  access:
    enabled: true
    var.paths: ["/path/to/log/apache/access.log*"]
  error:
    enabled: true
    var.paths: ["/path/to/log/apache/error.log*"]

Теперь загружаем дефолтные дашборды в кибану следующей командой.

# filebeat setup

И запускаем filebeat.

# systemctl enable --now filebeat

Идем в Kibana в раздел Discovery и наблюдаем там свои логи. У вас должен был появиться индекс filebeat-*.

Можете настроить список полей, которые вас интересуют в первую очередь, чтобы получить более наглядное представление.

Вы можете использовать поиск для группировки запросов по каким-то признакам, сохраненных в полях, на которые распарсен ваш лог. У вас уже есть готовый dashboard для логов apache. Идем в раздел Dashboard, через поиск находим дашборд для apache и смотрим его.

У меня тестовый сайт на локалхосте, поэтому дашборд неинформативен. Если прогнать через него реальный сайт, можно получить полезные данные. Пример самостоятельной сборки dashboard в Kibana под свои потребности описан у меня в статьях — Dashboard для логов Nginx и Мониторинг производительности бэкенда.

Заключение

Вот и все. Мы очень быстро и просто настроил сбор логов в Elastic Stack, используя триальный период в 14 дней. Этого будет достаточно, чтобы протестировать продукт и понять, нужен ли он вам. Далее вы можете либо выбрать платный тарифный план в облаке, либо собрать все на своих мощностях.

В стандартном деплойменте, который вы развернули для теста, используется кластер. Данные хранятся в двух различных сегментах облака, в третьем расположен мастер. И еще по виртуалке под Kibana и APM (мониторинг приложений). Если вам нужны только логи и нет необходимости настраивать отказоустойчивость, достаточно будет только виртуалки с Kibana и Elasticsearch. Собрать свой Deployment под задачи можно в самом начале, там, где мы выбирали готовый. При своей сборке сразу же будет видна ее стоимость в час. В целом, все удоволствие начинается от 16$ в месяц.

В следующем материале расскажу, как вывести id сессии посетителя Битрикс в лог файл и затем с помощью Kibana следить за его перемещениями по сайту.

Сообщение Быстрая настройка Elastic Stack в Elastic Cloud для сбора логов появились сначала на Clip-Clap.

Схема работы будет следующая:

1. Настраиваем в nginx логирование времени ответа бэкенда с помощью переменной $upstream_response_time из параметров логирования.
2. Передаем лог nginx в elk stack.
3. Создаем визуализации и дашборд для удобного анализа логов.

Прежде чем двигаться дальше, вам необходимо ознакомиться со статьей по установке и настройке elk stack. Руководствуясь статьей, вам следует настроить сам сервер elk stack и сбор логов nginx на этот сервер. Подобный пример как раз рассмотрен в статье. После этого можно приступать к дальнейшим действиям.

Настройка nginx для мониторинга бэкенда

На web сервере nginx нам нужно выполнить несколько подготовительных действий. Во-первых, добавляем дополнительный log_format, который будет собирать полезную информацию, помимо той, что используется в дефолтной настройке. Я предлагаю сразу максимально полный формат, который я называю full и обычно использую. Для этого в /etc/nginx/nginx.conf в раздел http добавляем новый формат лога.

    log_format full	'$remote_addr - $host [$time_local] "$request" '
               'request_length=$request_length '
               'status=$status bytes_sent=$bytes_sent '
               'body_bytes_sent=$body_bytes_sent '
               'referer=$http_referer '
               'user_agent="$http_user_agent" '
               'upstream_status=$upstream_status '
               'request_time=$request_time '
               'upstream_response_time=$upstream_response_time '
               'upstream_connect_time=$upstream_connect_time '
               'upstream_header_time=$upstream_header_time';

Здесь много дополнительной информации, которая может быть полезна для анализа. В данной статье я буду анализировать только время ответа бэкенда — upstream_response_time. Если вам интересны какие-то еще значения, можете их добавлять по аналогии.

Далее идем в виртуальный хост, за которым будем следить и правим его настройки. Я не буду приводить полный конфиг виртуального хоста. Покажу только те параметры, которые нас интересуют в рамках заданной темы.

Задаем формат лога виртуального хоста:

access_log /web/sites/serveradmin.ru/logs/access.log full;

Далее я всю статику добавляю в отдельный location и отключаю для него лог. Доступ к этим файлам мне нет необходимости логировать:

    location ~* ^.+.(js|css|png|jpg|jpeg|gif|ico|woff|woff2|swf|ttf|svg)$ {
    access_log off;
    expires 1y;
    add_header Cache-Control public;
    }

В отдельный location добавляю php запросы, которые как раз и будут попадать в лог.

    location ~ \.php$ {
    fastcgi_pass   unix:/var/run/php-fpm/php-fpm.sock;    
    ......
    }

Перечитывайте конфигурацию nginx и проверяйте лог виртуального хоста. Там должно быть примерно следующее:

5.45.207.63 - serveradmin.ru [05/Jan/2019:17:18:35 +0300] "GET /ustanovka-synology-os-na-obyichnyiy-kompyuter-hp-proliant-n54l-microserver/synology/ HTTP/1.1" request_length=302 status=200 bytes_sent=21246 body_bytes_sent=20644 referer=- user_agent="Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)" upstream_status=200 request_time=0.407 upstream_response_time=0.407 upstream_connect_time=0.000 upstream_header_time=0.401
207.46.13.33 - serveradmin.ru [05/Jan/2019:17:21:22 +0300] "GET /obnovlenie-chasovogo-poyasa-v-xenserver-6-5/ HTTP/1.1" request_length=281 status=200 bytes_sent=23846 body_bytes_sent=23244 referer=- user_agent="Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)" upstream_status=200 request_time=0.397 upstream_response_time=0.396 upstream_connect_time=0.000 upstream_header_time=0.390
5.45.207.63 - serveradmin.ru [05/Jan/2019:17:22:14 +0300] "GET /forum/astersik/ustanovka-free-pbx-13-na-sentos-7/ HTTP/1.1" request_length=267 status=200 bytes_sent=35598 body_bytes_sent=34756 referer=- user_agent="Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)" upstream_status=200 request_time=0.446 upstream_response_time=0.446 upstream_connect_time=0.000 upstream_header_time=0.435

Если у вас примерно так же, можно двигаться дальше. Смысл в том, что в логе должен быть параметр upstream_response_time и какое-то временное значение в секундах. Обычно меньше секунды, но это зависит от быстродействия бэкенда, за которым мы как раз и будем следить.

Grok фильтр logstash для парсинга лога

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

filter {
 if [type] == "nginx_access" {
    grok {
	match => { "message" => "%{IPORHOST:remote_ip} - %{DATA:virt_host} [%{HTTPDATE:access_time}] \"%{WORD:http_method} %{DATA:url} HTTP/%{NUMBER:http_version}\" request_length=%{INT:request_length} status=%{INT:status} bytes_sent=%{INT:bytes_sent} body_bytes_sent=%{NUMBER:body_bytes_sent} referer=%{DATA:referer} user_agent=\"%{DATA:user_agent}\" upstream_status=%{DATA:upstream_status} request_time=%{NUMBER:request_time} upstream_response_time=%{DATA:upstream_response_time} upstream_connect_time=%{DATA:upstream_connect_time} upstream_header_time=%{DATA:upstream_header_time}" }
	overwrite => [ "message" ]
    }
    mutate {
        convert => ["bytes_sent", "integer"]
        convert => ["body_bytes_sent", "integer"]
        convert => ["request_length", "integer"]
        convert => ["request_time", "float"]
        convert => ["upstream_status", "integer"]
        convert => ["upstream_response_time", "float"]
        convert => ["upstream_connect_time", "float"]
        convert => ["upstream_header_time", "float"]
    }
    ruby {
       code => 'event.set("request_time_ms",event.get("request_time")*1000)'
    }
    date {
        match => [ "access_time" , "dd/MMM/YYYY:HH:mm:ss Z" ]
	remove_field => [ "access_time" ]
    }
    geoip {
	source => "remote_ip"
	target => "geoip"
	add_tag => [ "nginx-geoip" ]
    }
 }

Привожу конфиг с рабочего сервера, который настраивал достаточно давно. Здесь выполняются следующие действия:

1. grok фильтр парсит строки лога
2. mutate конвертирует некоторые числовые поля в нужный формат, чтобы потом было удобнее работать
3. ruby фильтр добавляет новое поле request_time_ms просто умножая значение из существующего request_time на 1000. Это делается для более удобной визуализации значений. Целые числа более наглядны для визуализации
4. фильтр date берет время из поля access_time и использует его как время поступления лога в систему, заменяя @timestamp. Затем это поле удаляет, так как оно становится не нужно. Делается это для того, чтобы использовать только время из лога nginx, чтобы не было путаницы, когда порядок отправки логов по какой-то причине будет нарушен
5. geoip фильтр используется для построения гео карты. Об этом я отдельно рассказывал в статье по настройке дашборда для nginx

Перезапускайте logstash и идите в Kibana проверять поступление логов в указанном формате. Если все сделали правильно, то должно получиться примерно следующее:

Дашборд с временем ответа бэкенда

По сути вся настройка за мониторингом бэкенда сделана. Логи в нужном формате поступают в elasticsearch. Осталось только визуализировать их. Тут каждый может сделать так, как больше нравится ему. Я предложу свой вариант визуализации, но сразу скажу, что он меня не очень устраивает, но лучше не придумал сходу, а потом стало не очень актуально. Все, что надо, видно, а акцента на мониторинг работы web сервера я не делал.

Первая визуализация для upstream_response_time. Все запросы я разбил на несколько интервалов и вывел отдельно каждый интервал в столбец. Получилось примерно так:

Следующая визуализация показывает адреса запросов. Иногда эта картинка ломается, если какой-то запрос очень длинный и не помещается на экран. Не придумал, что с этим делать.

В следующей визуализации построил график на основе request_time. Напомню, что этот параметр я как раз умножал на 1000, чтобы получились целые значения. С ними нагляднее. Получилось вот так.

Обращаю внимание, что хвост я ограничил длиной в 2 секунды. Если этого не сделать, то отдельные очень длинные запросы растягивают график. Его становится неудобно анализировать. Вы подгоните этот параметр под свои условия работы. Возможно, вам нужен будет хвост длиннее, а может короче.

Отдельную визуализацию сделал для типов запросов.

Вот и все. Под графиками идет список самих логов. Весь дашборд получился таким:

Смотреть не очень удобно, потому что пишу статью на ноутбуке с низким разрешением. Смотреть лучше на большом мониторе.

Заключение

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

Я получаю уведомления от zabbix о том, что превышен средний трафик за интервал времени или высокая нагрузка на процессор. Открываю основной дашборд и сразу же анализирую, не спамит ли какой-то конкретный ip запросами. Далее смотрю по каким урлам идут запросы, есть ли ошибки web сервера.

Если все ок и нет явных нарушителей и ошибок, то смотрю на производительность сервера и время ответа бэкенда. Если в целом все нормально, не выходит за средние значения, значит все в порядке и высокая нагрузка не является проблемой в данный момент.

Заходить на сам web сервер по ssh и смотреть вручную логи нет необходимости. Это существенно экономит время. Не хватает только оповещений из elk stack по превышению каких-то пороговых значений, например количество пятисотых ошибок сервера.

Если грамотно настроить мониторинг логов с помощью elk stack, посадить за систему можно обычного оператора, не системного администратора. Весь первичный анализ он сможет сделать сам и составить подробный тикет для техподдержки с описанием проблемы. Либо можно отдать систему программисту, который будет очень рад возможности смотреть логи не бегая на сервер по ssh.

Получилась система из разряда must have для более ли менее серьезного web сервера. Я сейчас уже не представляю, как без нее администрировать веб сервер. По каждому инциденту надо лезть по ssh и смотреть, что случилось. Обычного мониторинга zabbix не достаточно. В elk stack можно настроить все, что угодно, вывести любые данные, которые актуальны для твоего проекта.

Сообщение Мониторинг производительности бэкенда с помощью ELK Stack появились сначала на Clip-Clap.

В своей статье я буду считать, что вы установили и настроили elk stack по моему материалу. Если это не так, то сами подредактируйте представленные конфиги под свои реалии. По большому счету, все самое основное по сбору логов windows серверов уже дано в указанной статье. Как минимум, там рассказано, как начать собирать логи с помощью winlogbeat. Дальше нам нужно их обработать и нарисовать функциональный дашборд для быстрого анализа поступающей информации.

Для того, чтобы оценить представленные мной графики и дашборды, рекомендую собирать логи сразу с нескольких серверов. Так можно будет оценить представленную информацию на практике. С одним сервером не так наглядно получится.

С визуализацией данных из windows журналов проблем нет никаких. Winlogbeat из коробки умеет парсить логи и добавлять все необходимые метаданные. Со стороны logstash не нужны никакие фильтры. Принимаем все данные как есть с winlogbeat.

Сбор windows логов

Приступим к настройке. Устанавливаем последнюю версию winlogbeat на сервер, с которого мы будем отправлять логи в elk stack. Вот конфиг с тестового сервера, по которому пишу статью:

winlogbeat.event_logs:
  - name: Application
    ignore_older: 72h
  - name: Security
  - name: System

tags: ["winsrv"]

output.logstash:
  hosts: ["10.1.4.114:5044"]

logging.level: info
logging.to_files: true
logging.files:
  path: C:/Program Files/Winlogbeat/logs
  name: winlogbeat
  keepfiles: 7

Теперь настраивает logstash на прием этих логов. Добавляем в конфиг:

    else if "winsrv" in [tags] {
        elasticsearch {
            hosts     => "localhost:9200"
            index    => "winsrv-%{+YYYY.MM}"
        }
    }

Я формирую месячные индексы с логами windows серверов. Если у вас очень много логов или хотите более гибкое управление занимаемым объемом, то делайте индексы дневные, указав winsrv-%{+YYYY.MM.dd}.

Перезапускайте службы на серверах и ждите поступления данных в elasticsearch.

Dashboard в Kibana для Windows Server

После того, как данные из логов windows серверов начали поступать в elk stack, можно приступить к их визуализации. Я предлагаю такую информацию для Dashboard в kibana:

• Количество логов с разбивкой по серверам
• Количество записей в каждом журнале
• Разбивка по уровням критичности (поле level)
• Разбивка по ID событий в логах (поле event_id)
• Список имен компьютеров, фигурирующих в логах (поле event_data.Workstation)
• Список пользователей в логах (поле event_data.TargetUserName)
• Разбивка по IP адресам (поле event_data.IpAddress)

Визуализации создаются достаточно просто, плюс они все похожи друг на друга. Вот пример одной из них — разбивка по рабочим станциям:

А вот какой Dashbord у меня получился в итоге:

В самом низу идет список логов с сырым текстом события. Отдельно представляю дашборд для файлового сервера windows.

Сбор и анализ логов Windows Fileserver

Для файлового сервера настраиваем сбор логов в ELK Stack точно так же, как я показал выше. Для визуализации данных я настроил отдельный дашборд в Kibana со следующей информацией:

• Имена пользователей, которые обращаются к файлам (поле event_data.SubjectUserName)
• Типы запросов, которые выполняются (поле file_action)
• Список доступа к файлам (формируется из сохраненного фильтра поиска)

Возможно, кому-то будет актуально выводить на дашборд еще и информацию об именах файлов, к которым идет доступ. Информация об этом хранится в поле event_data.ObjectName. Лично я не увидел в этом необходимости.

Заключение

Материал написан исключительно на основании своего видения и небольшого опыта использования elk stack. Нигде не видел статей и мыслей на данную тему, так что буду рад предложениям, замечаниям. Ко всему прочему, я практически не администрирую windows сервера.

Сообщение Настраиваем сбор логов Windows Server в ELK Stack появились сначала на Clip-Clap.

Ранее я рассказал, как установить и настроить elk stack, потом как загружать и анализировать логи nginx и samba. Теперь пришел черед логов Mikrotik. Я уже рассказывал, как отправлять логи микротика на удаленный syslog сервер, в качестве которого может выступать в том числе syslog-ng. В данном случае на самом микротике ничего особенного делать не надо. Будем точно так же отправлять данные на удаленный syslog сервер, в качестве которого будет трудиться logstash.

Я некоторое время рассуждал на тему парсинга и разбора логов. Но посмотрев на типичную картину стандартных логов mikrotik, понял, что ничего не выйдет. События очень разные и разобрать их одним правилом grok не получится. Если нужен парсинг и добавление метаданных к событиям, необходимо определенные события выделять и направлять отдельным потоком в logstash, где уже обрабатывать своим фильтром. Например, отдельный фильтр можно настроить на парсинг подключений к vpn или подключение по winbox с анализом имен пользователей.

Я же буду просто собирать все логи скопом и складывать в единый индекс. У записей не будет метаданных, по которым можно строить дашборды и анализировать данные. Но тем не менее, это все равно удобно, так как все логи в одном месте с удобным и быстрым поиском.

Настройка logstash на прием логов микротик

В конфиге /etc/logstash/conf.d/input.conf добавляем секцию для приема syslog логов. Вместе с логами от beats конфиг будет выглядеть вот так:

input {
    beats {
	port => 5044
    }
    syslog {
	port => 5045
	type => syslog
    }
}

В конфиге с фильтрами filter.conf я разделил с помощью тэгов логи обычных роутеров, свитчей и wifi точек доступа по ip адресам. Получилось примерно так:

    else if [host] == "10.1.4.19" or [host] == "10.1.5.1" {
        mutate {
            add_tag => [ "mikrotik", "gateway" ]
        }
    }
    else if [host] == "10.1.4.66" or [host] == "10.1.3.110" or [host] == "10.1.3.111" {
        mutate {
            add_tag => [ "mikrotik", "wifi" ]
        }
    }
    else if [host] == "10.1.4.14" or [host] == "10.1.5.33" {
        mutate {
            add_tag => [ "mikrotik", "switch" ]
	}
    }

Это простой случай, когда устройств мало. Если у вас много устройств, то лучше наверно придумать что-то другое, чтобы не нагружать logstash лишними правилами. Да и в ручную править конфиг неудобно. Как лучше поступать в таком случае — не знаю, не продумывал тему. Наверно имеет смысл разделить потоки по разным портам и на этом основании принимать решение о дальнейшей обработке.

Отправляем полученные логи в elasticsearch, настроив конфиг output.conf:

    else if "mikrotik" in [tags] {
        elasticsearch {
            hosts     => "localhost:9200"
            index    => "mikrotik-%{+YYYY.MM}"
        }
    }

Я просто складываю все логи с тэгом mikrotik в один индекс с разбивкой по месяцам. На типы gateway, switch и wifi не разделяю, хотя можно это сделать. Тэги я добавил просто для удобства просмотра логов. С помощью тэгов можно будет быстро группировать логи по типу устройств.

Перезапускаем logstash и идем настраивать микротики на отправку логов на удаленный сервер.

Отправка логов mikrotik на удаленный сервер

Подключаемся к Mikrotik по winbox и идем в раздел System -> Logging. Изначально там вот так, если вы ничего не меняли.

Идем на вкладку Actions, выбираем remote и указываем параметры:

В данном случае:

• 10.1.4.114 — сервер elk, точнее с logstash;
• 5045 — порт, по которому logstash принимает syslog подключения.

После этого идем на вкладку Rules и дублируем стандартные правила, указывая action remote или добавляем новые правила для отправки логов. Должно получиться примерно вот так:

Все, микротик настроен на отправку логов на удаленный сервер. Больше на нем ничего делать не надо. Идем в web интерфейс Kibana.

Добавление индекса mikrotik в kibana

Если в предыдущих разделах вы все сделали правильно, в elasticsearch должны начать поступать данные от микротиков в индекс mikrotik-*. Идем в Kibana в раздел Management -> Index Patterns и добавляем новый индекс.

После этого можно в разделе Discover просматривать логи. При этом работает группировка по тэгам, которые характеризуют тип устройства.

На этом по настройке хранения логов mikrotik в elk stack все. Надеюсь, было полезно.

Заключение

Получилась простая статья по сбору логов. Для тех, кто уже работал с ELK Stack тут ничего нового нет. По сути, никакого анализа и графиков нет, а именно это чаще всего интересует при использовании elk. Я просто не придумал, что может быть полезного в логах микротика, что требует какого-то детального разбора и построения дашбордов. Если у кого-то есть идеи или примеры grok фильтров, прошу поделиться.

Сообщение Централизованный сбор логов Mikrotik в ELK Stack появились сначала на Clip-Clap.

Для установки и настройки файлового сервера samba можно воспользоваться одной из моих статей:

• Настройка файлового сервера Samba с интеграцией в Active Directory
• Быстрая и простая настройка samba

Дальнейшее описание подойдет для обоих случаев. И для интеграции с AD, и для одиночного сервера с авторизацией по IP или имени пользователя.

Для того, чтобы samba записывала в лог все операции с файлами, необходимо настроить логирование. Как это сделать я рассказал уже давно в отдельной статье — настройка логов доступа в samba. Дальше в статье я буду считать, что у вас настроено примерно так же. Формат логов очень важен, так как ниже я предложу свой вариант grok фильтра для парсинга.

Сбор логов samba

Для сбора логов с samba сервера необходимо на него установить filebeat. Как это сделать рассказано в моей статье по установке и настройке elk stack. Создаем простой конфиг для filebeat — /etc/filebeat/filebeat.yml.

filebeat.inputs:
- type: log
  enabled: true
  paths:
      - /var/log/samba/audit.log
  fields:
    type: smb-audit
  fields_under_root: true
  scan_frequency: 5s

output.logstash:
  hosts: ["10.1.4.114:5044"]

Минимум опций. Просто отправляем все записи лога самбы audit.log в logstash по адресу 10.1.4.114 и устанавливаем тип — smb-audit. Это сделано для удобства в дальнейшей обработке и вычленении логов самбы из общего потока данных. Идентичные настройки будут на всех серверах samba.

Парсинг логов samba в logstash

Нам нужно принять логи с samba в logstash, обработать их и передать в elasticsearch. Для приема логов в конфиге logstash /etc/logstash/conf.d/input.conf (напомню, что у меня для удобства конфиг разделен на 3 части input.conf, filter.conf, output.conf) у меня уже есть строки:

input {
    beats {
	port => 5044
    }
}

Так что ничего добавлять не надо. Дальше нам нужно настроить фильтрацию логов. Для этого в filter.conf добавляю строки:

	else if [type] == "smb-audit" {
	mutate {
	    gsub => ["message","[\\|]",":"]
	    gsub => ["message","  "," "]
	    }
        grok {
            match => [ "message" , "%{MONTH:syslog_month} %{MONTHDAY:syslog_day} %{TIME:syslog_time} %{HOSTNAME:srv_name} smbd_audit: XS:%{GREEDYDATA:user_name}:%{IP:user_ip}:%{WORD:share_name}:%{WORD:action}:%{DATA:sucess}:%{GREEDYDATA:path}"]
	    overwrite => [ "message" ]
            }
    }

В данном случае выше в конфиге у меня уже есть другие правила. Если же данное правило у вас будет единственным, то else не нужно указывать. Расскажу, что делают данные правила. Плагин mutate и операция gsub в первой строке заменяет в логе самбы все обратные слеши \ и | на : Это сделано для того, чтобы потом было проще использовать фильтр grok. Вторая операция gsub заменяет двойной пробел на единичный. Это сделано для того, чтобы убрать двойной пробел в логах самбы, когда в числе месяца используется одна цифра. Вот пример:

Nov  6 18:00:41 xmdoc smbd_audit: XS\kobelev|10.1.4.49|documents|open|ok|r|Конструкторы/_Проекты/15667/проработка.dwg

Nov 13 12:04:47 xmdoc smbd_audit: XS\ignatev|10.1.4.81|documents|open|ok|r|Конструкторы/_Проекты/02649.обрамление.dwg

В первом случае после Nov стоят 2 пробела. Это усложняет настройку парсинга. Поэтому лишние пробелы и символы убираем. После работы фильтра mutate мы получим вот такую строку:

Nov 6 18:00:41 xmdoc smbd_audit: XS:kobelev:10.1.4.49:documents:open:ok:r:Конструкторы/_Проекты/15667/проработка.dwg

Дальше вступает в дело фильтр grok и его правило обработки:

%{MONTH:syslog_month} %{MONTHDAY:syslog_day} %{TIME:syslog_time} %{HOSTNAME:srv_name} smbd_audit: XS:%{GREEDYDATA:user_name}:%{IP:user_ip}:%{WORD:share_name}:%{WORD:action}:%{DATA:sucess}:%{GREEDYDATA:path}

Оно не идеальное, но мои запросы удовлетворяет. Проверить работу фильтра можно в grok debugger. На выходе будет вот такой json:

{
  "user_ip": "10.1.4.49",
  "share_name": "documents",
  "syslog_time": "18:00:41",
  "srv_name": "xmdoc",
  "user_name": "kobelev",
  "syslog_month": "Nov",
  "path": "r:Конструкторы/_Проекты/15667/проработка.dwg",
  "syslog_day": "6",
  "sucess": "ok",
  "action": "open"
}

В моем случае не парсится значение домена XS из лога, так как все делается в рамках одного домена, и я просто опустил это действие. Вам нужно подработать правило под свои реалии. Если у вас много доменов, добавьте отдельное поле для имени домена. Если это не нужно, просто поменяйте на свой домен. Из названия полей думаю и так понятно, что я сделал. Я выделил ключевые для меня значения, которые дальше буду использовать в графиках и дашбордах. Я не смог отдельно выделить путь файла без лишних символов в начале. Не помню точно, с чем конкретно это связано, но в целом, проблема в том, что лог сильно изменяется в зависимости от проводимой операции. Единым фильтром было трудно все охватить, пришлось бы разделять разные события на разные потоки и анализировать отдельно. Я посчитал, что это не имеет смысла.

Если у вас samba не в домене, то лог будет немного другой. Вот пример строки лога и моего grok фильтра для обработки. Исходный лог:

Nov 13 11:40:54 xb-share smbd_audit: 10.1.5.20|scans|realpath|ok|Отсканированные счета/2018/счет.pdf

После работы фильтра mutate:

Nov 13 11:40:54 xb-share smbd_audit: 10.1.5.20:scans:realpath:ok:Отсканированные счета/2018/счет.pdf

Дальше вступает в дело grok фильтр

%{MONTH:syslog_month} %{MONTHDAY:syslog_day} %{TIME:syslog_time} %{HOSTNAME:srv_name} smbd_audit: %{IP:user_ip}:%{WORD:share_name}:%{WORD:action}:%{DATA:sucess}:%{GREEDYDATA:path}

И на выходе получаем обработанные данные:

{
  "user_ip": "10.1.5.20",
  "share_name": "scans",
  "syslog_time": "11:40:54",
  "srv_name": "xb-share",
  "syslog_month": "Nov",
  "path": "Отсканированные счета/2018/счет.pdf",
  "syslog_day": "13",
  "sucess": "ok",
  "action": "realpath"
}

Теперь эти данные надо передать в elasticsearch. Добавляем в конфиг output.conf строки:

    else if [type] == "smb-audit" {
        elasticsearch {
            hosts     => "localhost:9200"
            index    => "smb-audit-%{+YYYY.MM}"
        }
    }

Обращаю внимание, что данными настройками я формирую месячные индексы, а не дневные. Если у вас большой объем данных за день и вы не планируете хранить данные за несколько месяцев, то разбивайте индексы на дни.

Если других правил у вас нет, то else уберите. После этого нужно перезапустить logstash и проверять через kibana поступление обработанных логов.

Дашборд в ELC Stack для логов samba

Я немного поразмышлял и собрал вот такой dashboard для логов samba.

На этом дашборде расположены следующие визуализации:

1. Количество запросов с конкретного IP.
2. Количество запросов по доменному имени пользователя.
3. Распределение запросов между тремя файловыми серверами.
4. Распределение по типам операций.
5. Список исходных логов.

При выборе конкретного сервера, мы получаем дашборд с информацией только по нему. То же самое по пользователям, ip, операциям и т.д. Стало ОЧЕНЬ удобно анализировать работу серверов. К примеру, если у вас в сети появится шифровальщик, вы сразу же это увидите на дашборде и узнаете ip источника проблемы. Про банальное — узнать, кто у удалил или изменил файл я и не говорю.

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

Заключение

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

В следующей статье расскажу, как сделать то же самое, только для файловых серверов на windows. Там примерно такой же dashboard будет, но сбор и анализ логов другие.

Сообщение Сбор и анализ логов samba в ELK Stack появились сначала на Clip-Clap.

Полностью ошибка в логе logstash выглядит следующим образом:

[INFO ][logstash.outputs.elasticsearch] retrying failed action with response code: 403 ({"type"=>"cluster_block_exception", "reason"=>"blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];"})

Получил я ее несколько раз, когда оставалось очень мало свободного места на диске с данными elasticsearch. При достижении примерно 5% свободного места, данные переставали поступать в elasticsearch и появлялась эта ошибка. Исправить ее можно следующим образом. Во первых, перенести данные на более емкий диск или почистить его. Потом идем в Kibana -> Dev Tools и выполняем команду:

PUT weblogs-2018.09.10/_settings
{
  "index": {
  "blocks": {
  "read_only_allow_delete": "false"
}
}
}

weblogs-2018.09.10 — имя индекса, куда не шли данные. После выполнения команды перезапустил logstash на сервере и данные пошли в текущий индекс.

Скорее всего для записи будут недоступны и системные индексы. Проверьте, какие у вас используются. Точно должен быть .kibana. Если используете мониторинг, то для него тоже свои системные индексы создаются. Они тоже могут быть заблокированы для записи.

Сообщение Ошибка в elasticsearch — FORBIDDEN/12/index read-only / allow delete (api) появились сначала на Clip-Clap.

Статья будет короткая, так как процесс очистки индексов в elasticsearch с помощью curator в базовом варианте очень прост.

Установка curator

Для начала установим curator. Сделать это можно разными способами. Самый простой — из репозитория packages.elastic.co от авторов продукта. Подключим его в CentOS 7.

# rpm --import https://packages.elastic.co/GPG-KEY-elasticsearch
# mcedit /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

Подключаем репозиторий в Debian 8/Ubuntu

# wget -qO - https://packages.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -
# mcedit /etc/apt/sources.list.d/curator.list

deb [arch=amd64] https://packages.elastic.co/curator/5/debian stable main

Отдельный репозиторий для Debian 9

# deb [arch=amd64] https://packages.elastic.co/curator/5/debian9 stable main

Устанавливаем curtator:

# yum install elasticsearch-curator
# apt update && apt install elasticsearch-curator

Так же curator можно установить через pip. Для Debian/Ubuntu достаточно просто выполнить:

# apt install python-pip

Установка curator через pip:

# pip install elasticsearch-curator

Настройка curator для очистки elasticsearch

Сделаем для примера простое задание на закрытие и удаление индексов с шаблоном nginx-* старше 14-ти дней. Для этого создадим директорию для конфигов curator и сами конфиги.

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

Заполняем файлы следующим содержимым. Сначала общий конфиг.

# mcedit /etc/curator/config.yml

client:
  hosts:
    - 127.0.0.1
  port: 9200
  url_prefix:
  use_ssl: False
  certificate:
  client_cert:
  client_key:
  ssl_no_validate: False
  http_auth:
  timeout: 30
  master_only: False

logging:
  loglevel: INFO
  logfile:
  logformat: default
  blacklist: ['elasticsearch', 'urllib3']

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

# mcedit /etc/curator/action.yml

actions:
  1:
    action: close
    description: >-
      Close indices older than 14 days (based on index name).
    options:
      ignore_empty_list: True
      delete_aliases: False
      disable_action: False
    filters:
    - filtertype: pattern
      kind: prefix
      value: nginx-
    - filtertype: age
      source: name
      direction: older
      timestring: '%Y.%m.%d'
      unit: days
      unit_count: 14

  2:
    action: delete_indices
    description: >-
      Delete indices older than 14 days (based on index name).
    options:
      ignore_empty_list: True
      disable_action: False
    filters:
    - filtertype: pattern
      kind: prefix
      value: nginx-
    - filtertype: age
      source: name
      direction: older
      timestring: '%Y.%m.%d'
      unit: days
      unit_count: 14

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

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

# /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 утра.

Сообщение Очистка elasticsearch с помощью curator появились сначала на Clip-Clap.

Начнем создание дашборда с самого сложного — настройки гео карты запросов. На официальном сайте есть подробный мануал на тему создания GeoIP карты. В нем вроде бы все понятно. Никаких особых настроек не требуется. Все работает из коробки. Но у меня никак не хотело работать все то, что там описано. Пришлось прилично поковыряться с elasticsearch и его шаблонами, чтобы разобраться в чем причина.

Все дело в том, что описанный в инструкции способ работает из коробки, только если вы используете стандартный шаблон для индексов в формате logstash-*. Скорее всего у вас будет много разных шаблонов и индексов после того, как вы запустите систему в промышленную эксплуатацию.

Основная сложность тут в том, что для работы geoip карты вам нужны в шаблоне поля с типом geo_point. После создания индекса, тип полей уже нельзя поменять. То есть просто преобразовать данные на основе ip в координаты не сложно, это умеет делать модуль geoip в logstash. Но вот дальше вы никак не превратите координаты в виде числа в geo_point данные. Нужно в самом начале создать шаблон с такими полями.

Надеюсь понятно объяснил Если не понятно сразу, то сообразите дальше по ходу моего рассказа. Я сам пока разобрался в этой кухне, прилично поковырялся и нагуглился.

В дальнейшем я буду считать, что ваш elasticsearch и kibana настроены примерно как у меня в инструкции. Фильтр logstash, отвечающий за обработку логов nginx выглядит следующим образом:

if [type] == "nginx-ext-access" {
        grok {
            match => [ "message" , "%{COMBINEDAPACHELOG}+%{GREEDYDATA:extra_fields}"]
            overwrite => [ "message" ]
            }
        mutate {
            convert => ["response", "integer"]
            convert => ["bytes", "integer"]
            convert => ["responsetime", "float"]
            }
        geoip {
            source => "clientip"
            target => "geoip"
            add_tag => [ "nginx-geoip" ]
            }
        date {
            match => [ "timestamp" , "dd/MMM/YYYY:HH:mm:ss Z" ]
            remove_field => [ "timestamp" ]
            }
        useragent {
            source => "agent"
            }
    }

И вот так логи уходят в elasticsearch

if [type] == "nginx-ext-access" {
        elasticsearch {
            hosts     => "localhost:9200"
            index    => "nginx-ext-%{+YYYY.MM.dd}"
        }
    }

Создание index шаблона

Как я уже сказал выше, для того, чтобы у вас заработала geoip карта, у вас должны быть в шаблоне индекса поля типа geo_point. Если их не будет, то вы сразу при создании визуализации с Coordinate Map получите ошибку:

No Compatible Fields: The "nginx-*" index pattern does not contain any of the following field types: geo_point

Что я только не делал, после того, как получил эту ошибку. Я проверял работу geoip модуля. Смотрел поля с координатами на основе ip адреса. Все было в порядке и все было на месте.

Но geoip карта в Kibana не работала. Погуглив немного эту тему, я потихоньку стал понимать, в чем тут дело.

Для начала посмотрим шаблон нашего индекса с логами nginx. Для этого идем в Management -> Index Management. Выбираем наш индекс и смотрим Mapping. Нас интересует поле location.

Оно имеет тип float, а нам нужно, судя по статье на сайте, тип geo_point.

Дальше стал разбираться, как изменить тип поля в шаблоне. Оказалось, что это сделать нельзя. Тип полей можно установить только в момент создания индекса из шаблона. Значит нужно понять, как сделать свой шаблон с нужными полями.

Для начала посмотрим, какие шаблоны у нас сейчас установлены. Для этого идем в Dev Tools и выполняем команду:

GET /_template

Обращаем внимание на шаблон logstash. В нем есть все, что нам нужно. Если ваш индекс будет иметь шаблон logstash-*, то вам ничего настраивать не надо, все заработает из коробки. Мы же добавим новый шаблон nginx* и установим у него параметры полей, необходимые для работы geoip карты.

Выполняем следующий код для создания шаблона nginx по аналогии с шаблоном logstash.

PUT _template/nginx
{
"index_patterns": [
      "nginx*"
    ],
    "settings": {
      "index": {
        "refresh_interval": "5s"
      }
    },
    "mappings": {
      "_default_": {
        "dynamic_templates": [
          {
            "message_field": {
              "path_match": "message",
              "match_mapping_type": "string",
              "mapping": {
                "type": "text",
                "norms": false
              }
            }
          },
          {
            "string_fields": {
              "match": "*",
              "match_mapping_type": "string",
              "mapping": {
                "type": "text",
                "norms": false,
                "fields": {
                  "keyword": {
                    "type": "keyword",
                    "ignore_above": 256
                  }
                }
              }
            }
          }
        ],
        "properties": {
          "@timestamp": {
            "type": "date"
          },
          "@version": {
            "type": "keyword"
          },
          "geoip": {
            "dynamic": true,
            "properties": {
              "ip": {
                "type": "ip"
              },
              "location": {
                "type": "geo_point"
              },
              "latitude": {
                "type": "half_float"
              },
              "longitude": {
                "type": "half_float"
              }
            }
          }
        }
      }
    },
    "aliases": {}
  }

Проверяем список доступных шаблонов.

Все в порядке. Теперь новые индексы, попадающие под этот шаблон, будут содержать необходимые поля. Можете либо удалить текущие индексы, для создания новых, либо подождать, когда они сами создадутся в соответствии с вашими правилами.

Прежде чем двигаться дальше, проверьте, что у вас в шаблоне индекса действительно есть поле geo_point. Идем в Management -> Index Patterns и смотрим поля нашего индекса, предварительно обновив их, нажав Refresh field list.

Если у вас так же, можно двигаться дальше.

На всякий случай расскажу про неправильный путь, по которому я пошел изначально, пытаясь решить проблему с шаблоном. Я узнал, что logstash хранит свои шаблоны в директории /usr/share/logstash/vendor/bundle/jruby/2.3.0/gems/logstash-output-elasticsearch-9.2.0-java/lib/logstash/outputs/elasticsearch (пипец какой путь :)). Я решил изменить его шаблон, для этого просто отредактировал файл elasticsearch-template-es6x.json, поменяв шаблон для индекса. Перезапустил logstash, но ничего не изменилось. Этот шаблон был залит в elasticsearch при первом запуске. Потом уже не меняется. Его надо удалить, чтобы он установился заново с моими изменениями. Я не стал это делать, а просто загрузил новый шаблон.

Настройка координатной карты в Kibana

Теперь создадим географическую карту с распределением запросов nginx по этой карте на основе ip адресов. Идем в раздел Visualize и добавляем Coordinate Map. Выбираем индекс с логами nginx. Указываем в карте поле с координатами — geoip.location.

Запускаете визуализацию и смотрите результат.

Теперь эту карту можно добавить на дашборд вместе с остальными графиками. Не буду рассказывать, как добавить обычные графики. Там хоть и не совсем все очевидно, но не так сложно. Лучше самим разобраться и порисовать различные графики, чтобы понять, какая визуализация для вас наиболее удобна. Я подобрал по своему вкусу. Много раз перерисовывал и переделывал, пока не удовлетворился результатом.

Настройка Dashboard для nginx

Я настроил вот такой дашборд в Kibana для логов Nginx (кликабельно, большая картинка, откройте в отдельной вкладке, чтобы рассмотреть).

Здесь представлена следующая информация:

1. Geoip карта
2. Распределение запросов по странам.
3. Список самых популярных урлов.
4. Список самых активных IP.
5. Распределение запросов по типам ответов.
6. Траффик.
7. Непосредственно логи nginx в чистом виде.

С таким дашбордом очень удобно расследовать инциденты и просто смотреть статистику. Выбираем, к примеру, код ошибки и смотрим всю информацию по нему. Сразу подсвечиваются ip, которые спамят запросы. По ним тут же можно получить всю информацию — откуда они и по каким урлам спамят. И так далее. В общем, очень удобно. Я уже не представляю большой веб проект без такого дашборда. Раньше анализ логов для меня был гораздо сложнее. И как я раньше админил без такого инструмента Век живи — век учись.

Сообщение Dashboard для логов Nginx в Kibana+Elasticsearch появились сначала на Clip-Clap.

Введение

Информации на тему сбора логов с удаленных серверов и интернете достаточно много. Ничего сложного тут нет, я и сам уже описывал подобную настройку в статье про сбор логов с mikrotik. Но решение получилось кривоватое, в комментариях написаны замечания. Я и сам знал о них, но простого и быстрого решения я не смог найти, на тот момент меня устраивал и такой вариант. Сейчас же решил все сделать аккуратно и красиво, чтобы было удобно пользоваться. В процессе поиска информации в интернете решил попробовать syslog-ng. С ним у меня не возникло никаких затруднений, сразу получилось то, что требовалось, поэтому я остановил свой выбор на нем.

Настраивать сервер сбора логов будем на системе CentOS 7. Если у вас еще не подготовлен сервер, то читайте мою информацию по установке и базовой настройке centos. Для небольшого количества устройств, нагрузка на сервер будет незначительная, поэтому имеет смысл размещать сервер на виртуальной машине. Если у вас нет готового гипервизора, можете посмотреть мою информацию на тему настройки linux гипервизора proxmox или бесплатного решения microsoft — Windows Hyper-V Server 2016.

Установка и настройка syslog-ng

С установкой нет ничего сложного. Установить syslog-ng можно одной командой:

# yum install -y syslog-ng

Сразу переходим к настройке. Файл конфигурации располагается по адресу /etc/syslog-ng/syslog-ng.conf. Чтобы сервер начал принимать логи с удаленного устройства, его необходимо прописать в конфиг. Делается это просто. В самый конец конфигурационного файла добавляем информацию о новом устройстве:

destination d_xs-zabbix { file("/var/log/!remote/xs-zabbix.log"); };
filter f_xs-zabbix { netmask("10.1.3.29/255.255.255.255"); };
log { source(net); filter(f_xs-zabbix); destination(d_xs-zabbix); };

Соответственно для второго сервера нужно добавить еще 3 строки, например так:

destination d_xs-web { file("/var/log/!remote/xs-web.log"); };
filter f_xs-web { netmask("10.1.3.38/255.255.255.255"); };
log { source(net); filter(f_xs-web); destination(d_xs-web); };

И так далее. Добавляете столько серверов, сколько нужно. Не забудьте создать папку для логов. В моем примере это папка /var/log/!remote, сами файлы создавать не надо, служба автоматически их создаст, когда придет информация с удаленных серверов.

Запускаем syslog-ng и добавляем в автозагрузку:

# systemctl start syslog-ng
# systemctl enable syslog-ng

Проверим, запустилась ли служба:

# netstat -tulnp | grep syslog
udp 0 0 0.0.0.0:514 0.0.0.0:* 25960/syslog-ng

Все в порядке, слушает 514 udp порт. Не забудьте открыть этот порт в iptables, если у вас включен фаерволл. Сервер готов к приему логов.

Отправка логов syslog на удаленный сервер

Теперь идем на добавленные в syslog-ng сервера и настраиваем там отправку логов на наш сервер. Сделать это очень просто. Открываем файл конфигурации rsyslog. В CentOS он живет по адресу /etc/rsyslog.conf и добавляем туда строку:

*.* @10.1.3.22

10.1.3.22 — ip адрес syslog-ng сервера. Перезапустите rsyslog:

# service rsyslog restart

и проверяйте логи на сервере syslog-ng в указанной папке. Правило *.* отправит все логи в указанное направление. Это не всегда нужно, можно отредактировать правила. Для этого надо ознакомиться с документацией по syslog. Там нет ничего сложного, мне не хочется на этом сейчас подробно останавливаться. В интернете есть примеры. Приведу пару своих.

*.*;local5.none @10.1.3.22

В данном случае у меня по local5.notice идет лог самбы по доступу к сетевой шаре. Мне не нужно собирать эту информацию и я ее отключил. Вот еще пример:

*.info @10.1.3.22

С этого сервера сыпалось много лишней информации уровня debug. Я ограничил отправляемые сообщения уровнем info. И так далее.

Ротация логов syslog-ng

В завершение приведу пример своего правила ротации логов. Рекомендую ротацию настроить сразу, не оставлять на потом. Создаем файл /etc/logrotate.d/syslog-ng

# mcedit /etc/logrotate.d/syslog-ng

/var/log/!remote/*.log {
    daily
    rotate 180
    olddir /var/log/!remote/old
    missingok
    compress
    sharedscripts
    postrotate
    /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
}

По этому правилу ротация логов происходит раз в день. Старые логи перемещаются в папку /var/log/!remote/old и сжимаются. Хранятся логи за последние 180 дней.

Заключение

Я привел частный случай настройки хранения логов с удаленных устройств. Решение в лоб. В простых случаях этого достаточно. Лично мне удобно смотреть информацию в текстовых файлах. Это требуется редко, сделано на всякий случай для расследования инцидентов, если таковые возникают. Эту же задачу, к примеру, можно решить с помощью заббикс.

Для более удобного сбора и последующего просмотра информации существуют готовые решения с написанными веб панелями. Я посмотрел на некоторые из них. Что-то мне показалось слишком сложным в настройке, где-то веб интерфейс не понравился. Для себя остановился на приведенном варианте.

Сообщение Настройка syslog-ng для централизованного сбора логов появились сначала на Clip-Clap.

Настраиваем удаленный сервер rsyslog

У меня в хозяйстве имелся сервер Debian. Решил хранить логи с микротиков именно на нем. В составе Debian уже имеется сервис сбора логов с удаленных источников rsyslog. Необходимо только включить в нем необходимый функционал. Правим файл /etc/rsyslog.conf:

Раскомментируем строки

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

чтобы получать логи по UDP, либо

# provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514

чтобы получать логи по TCP

И в секцию RULES добавим несколько строк для удобного хранения файлов логов от разных удаленных источников:

# Зададим шаблон создания имен файлов (на основании IP адреса клиента)
$template FILENAME,"/var/log/!remote/%fromhost-ip%/syslog.log"

# Укажем сохранять сообщения от любого источника (*) с любым приоритетом (*) в файл, заданный шаблоном
# Например, клиенты (10.0.0.2,10.0.0.3...) будут раскладываться в соответствующие каталоги /var/log/10.0.0.2/syslog.log
 *.* ?FILENAME

Перезапускаем rsyslog для применения настроек:

/etc/init.d/rsyslog restart

Теперь наш сервер готов принимать логи с удаленных источников. Хранить он их будет в папке /var/log/!remote Для каждого источника будет создана папка с именем IP адреса этого источника.

Настраиваем пересылку логов в Mikrotik

Теперь настраиваем в роутере хранение логов на удаленном сервере. Для этого заходим в раздел System -> Logging, выбираем закладку Actions, два раза щелкаем по строчке remote. Открывается окно настроек. В нем вводим адрес удаленного сервера сбора логов. Порт на свое усмотрение либо оставляем по-умолчанию, либо меняем на свой. Больше ничего добавлять не надо.

Дальше в разделе Rules создаем необходимое правило хранения:

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

Сообщение Mikrotik логирование на удаленный сервер rsyslog появились сначала на Clip-Clap.