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

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.

Статья будет короткая, так как процесс очистки индексов в 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.