🥇Дружим ELK и Exchange. Часть 1

Начинаю серию статей, где хочу поделиться своим опытом подключения Exchange и ELK. Этот стэк поможет обрабатывать большие объемы логов и не задаваться вопросом, при каком размере привычные инструменты логирования откажутся нам помогать. Давайте знакомиться с новым бойцом с логами.

Exchange обладает достаточно разветвлённой системой логирования. Самые востребованные логи – логи трэкинга, которые отслеживают пошаговое прохождение конкретного письма внутри почтовой организации; логи веб-сервера, которые отслеживают каждую новую сессию пользователя в системе, и логи конкретных веб-приложений с разной степенью детализации сессии. Также Exchange умеет хранить сырые логи протоколов smtp, imap и pop3.

Какие инструменты мы можем использовать для работы с логами:

Штатный командлет Get-MessageTrackingLog: удобно обрабатывать логи трэкинга;
Утилита logparser: для логирования использует псевдо-SQL язык для поиска и работает достаточно быстро;
Внешний SQL-сервер: для особо специфических случаев (например, анализ данных за большие промежутки времени).

Всё это работает неплохо, когда у нас пара серверов и объем обрабатываемых логов измеряется десятками-сотнями гигабайт. А что, если счёт серверов идёт на десятки, а размер логов перевалил за терабайт? Эта схема, вероятнее всего, начинает сыпаться.

И вот что происходит: Get-MessageTrackingLog начинает отваливаться по тайм-ауту, logparser упирается в потолок 32-битной архитектуры, а выгрузка в SQL-сервер ломается в самый неподходящий момент, не переварив многострочный exception от сервиса.

Тут на сцену выходит новый игрок – стэк ELK, который специально заточен под жонглирование огромными объемами логов в разумные сроки и с терпимым потреблением ресурсов.

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

Установка

Итак, файл-архив агента filebeat можно скачать с этого сайта.

Мы выполним установку простой распаковкой содержимого zip-файла. Например, в c:Program Filesfilebeat. Затем необходимо запустить PowerShell-скрипт install-service-filebeat.ps1, который идёт в комплекте, для установки сервиса filebeat.

Теперь мы готовы начать настраивать файл конфигурации.

Отказоустойчивость

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

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

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

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

Подробнее об этом можно почитать в документации в параграфах: How does Filebeat keep the state of files и How does Filebeat ensure at-least-once delivery?

Настройка

Вся настройка выполняется в файле конфигурации формата yml, который разбит на несколько секций. Рассмотрим некоторые из них, которые участвуют в процессе сбора логов с серверов Exchange.

Блок обработки логов

Блок обработки логов начинается с поля:

filebeat.inputs:

Мы будем использовать общий инструмент сбора логов:

- type: log

Далее указываем статус (включен) и пути до папки с логами. Например, в случае с логами IIS настройки могут быть следующими:

    enabled: true
    paths:
	- C:inetpublogsLogFilesW3SVC1*.log
	- C:inetpublogsLogFilesW3SVC2*.log

Ещё одна важная настройка: как filebeat должен считывать многострочные записи. По умолчанию filebeat считает одну строку лог-файла одной записью. Это работает хорошо, пока у нас в лог не начинают поступать исключения, связанные с некорректной работой сервиса. В этом случае исключения могут состоять из нескольких строк. Поэтому filebeat должен считать многострочную запись как одну, если следующая строка начинается с даты. Формат записи логов в Exchange такой: каждая новая запись в лог-файл начинается с даты. В конфигурации это условие выглядит таким образом:

multiline:
	pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
	negate: true
	match: after

Имеет смысл добавить тэги в отправляемую запись, например:

  tags: ['IIS', 'ex-srv1']

И не забыть исключить из обработки строки, начинающиеся с хэш-символа:

  exclude_lines: ['^#']

Итак, блок чтения логов будет выглядеть следующим образом:

filebeat.inputs:
- type: log
  enabled: true
  paths:
	- C:inetpublogsLogFilesW3SVC1*.log
	- C:inetpublogsLogFilesW3SVC2*.log
  multiline:
	pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
	negate: true
	match: after
  tags: ['IIS', 'ex-srv1']
  exclude_lines: ['^#']

Блок отправки логов

Отдельные записи в лог файле filebeat отправляет в виде объекта json, в котором конкретная запись из лога содержится в единственном поле message. Если мы хотим как-то работать с этой информацией, нам необходимо это поле предварительно распарсить на отдельные поля. Сделать это можно, например, в logstash. Он и будет являться получателем записей из filebeat. Вот как это может выглядеть в файле конфигурации filebeat:

output.logstash:
  hosts: ["logstash1.domain.com:5044"]

Если серверов несколько, то для них можно включить балансировку: тогда filebeat будет отправлять логи не на первый доступный сервер из списка, а распределять отправляемые логи между несколькими серверами:

hosts: ["logstash1.domain.com:5044", "logstash2.domain.com:5044"]
  loadbalance: true

Filebeat при обработке логов в отправляемый json помимо записи лога, которая содержится в поле message, добавляет некоторое количество метаданных, которое сказывается на размере документа, попадающего в elastic. Эти метаданные можно выборочно из отправки убрать. Делается это в блоке processor с помощью процессора drop_fields. Исключить можно, например, следующие поля:

processors:
- drop_fields:
	fields: ["agent.ephemeral_id", "agent.hostname", "agent.id", "agent.type", "agent.version", "agent", "ecs.version", "ecs", "input.type", "input", "log.offset", "version"]

К выбору исключаемых полей стоит подойти аккуратно, ведь часть из них может использоваться на стороне elastic для построения индексов.

Итак, блок отправки логов будет выглядеть следующим образом:

output.logstash:
  hosts: ["logstash1.domain.com:5044", "logstash2.domain.com:5044"]
  loadbalance: true
 
processors:
- drop_fields:
	fields: ["agent.ephemeral_id", "agent.hostname", "agent.id", "agent.type", "agent.version", "agent", "ecs.version", "ecs", "input.type", "input", "log.offset", "version"]

Настройки логирования filebeat

Имеет смысл выставить следующие настройки логирования:

Уровень логирования info;
Записываем логи в файлы, расположенные по дефолту (директория logs, в директории установки filebeat);
Имя файла лога — filebeat;
Хранить последние 10 файлов логов;
Запускать ротацию при достижении размера 1Мб.

Финально блок настройки логирования будет выглядеть так:

logging.level: info
logging.to_files: true
logging.files:
  name: filebeat
  keepfiles: 10
  rotateeverybytes: 1048576

Итоговая конфигурация

Мы собрали конфигурацию, и теперь она выглядит следующим образом:

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - C:inetpublogsLogFilesW3SVC1*.log
    - C:inetpublogsLogFilesW3SVC2*.log
  multiline:
    pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
    negate: true
    match: after
  tags: ['IIS', 'ex-srv1']
  exclude_lines: ['^#']
 
output.logstash:
  hosts: ["logstash1.domain.com:5044", "logstash2.domain.com:5044"]
  loadbalance: true
 
processors:
- drop_fields:
    fields: ["agent.ephemeral_id", "agent.hostname", "agent.id", "agent.type", "agent.version", "agent", "ecs.version", "ecs", "input.type", "input", "log.offset", "version"]
 
logging.level: info
logging.to_files: true
logging.files:
  name: filebeat
  keepfiles: 10
  rotateeverybytes: 1048576

Важно понимать, что формат файла конфигурации — yml. Поэтому важно правильно расставлять пробелы и знаки минуса.

Filebeat умеет проверять файл конфигурации и, если синтаксис будет содержать ошибки, — укажет, в какой строке и в каком месте строки синтаксис неверен. Проверка выполняется следующим образом: