Sidebar

Zabbix Summit 2022
Register for Zabbix Summit 2022

6 Мониторинг файлов журналов

Обзор

Zabbix можно использовать для централизованного мониторинга и анализа файлов журналов с/без поддержки ротации журналов.

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

Для наблюдения за файлом журнала у вас должно быть:

  • Работающий Zabbix агент на узле сети
  • Настроенный элемент данных для мониторинга журнала

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

Настройка

Проверка параметров агента

Убедитесь, что в файле конфигурации агента:

  • Параметр 'Hostname' совпадает с именем узла сети в веб-интерфейсе
  • Для обработки активных проверок в параметре 'ServerActive' указаны сервера
Настройка элемента данных

Настройте элемент данных для мониторинга журнала.

Все обязательные поля ввода отмечены красной звёздочкой.

Специально для элементов данных наблюдения за журналами вам необходимо указать:

Тип Здесь выберите Zabbix агент (активный).
Ключ Используйте один из следующих ключей
log[] или logrt[]:
Эти два элемента данных позволяют выполнять мониторинг файлов журналов и фильтровать записи в журналах по их содержимому при помощи регулярного выражения, если присутствует.
Например: log[/var/log/syslog,error]. Убедитесь, что у файла имеются права на чтение для пользователя 'zabbix', в противном случае состояние элемента данных будет 'неподдерживается'.
log.count[] или logrt.count[]:
Эти два ключа элементов данных позволяют получить только количество совпадающих строк.
Для получения более подробных сведений касательно использования этих элементов данных и их параметров смотрите раздел поддерживаемых ключей элементов данных Zabbix агентом.
Тип информации Заполняется автоматически:
Для элементов данных log[] или logrt[] - Журнал (лог);
для элементов данных log.count[] или logrt.count[] - Числовой (целое положительное).
Если используется опциональный параметр вывод, вы можете вручную выбрать подходящий тип информации, отличный от "Журнал (лог)".
Обратите внимание, что выбор не журнального типа информации приведет к потере локального штампа времени.
Интервал обновления (в сек) Этот параметр определяет как часто Zabbix агент будет проверять наличие любых изменений в файле журнала. Указав этот параметр равным 1 секунде, вы можете быть уверенными, что получите новые записи как можно скорее.
Формат времени журнала В этом поле вы можете опционально задать шаблон для анализа штампа времени строки журнала.
Если оставить пустым, штамп времени не будет анализироваться.
Поддерживаемые заменители:
* y: Год (0001-9999)
* M: Месяц (01-12)
* d: День (01-31)
* h: Час (00-23)
* m: Минута (00-59)
* s: Секунда (00-59)
Например, рассмотрим следующую строку из файла журнала Zabbix агента:
" 23480:20100328:154718.045 Zabbix agent started. Zabbix 1.8.2 (revision 11211)."
Она начинается шестью символами обозначающими PID, далее следует дата, время, и остальная часть строки.
Форматом времени журнала для такой строки является "pppppp:yyyyMMdd:hhmmss".
Обратите внимание, что символы "p" и ":" являются лишь заменителями и могут быть любыми символами, за исключением "yMdhms".

Важные замечания

  • Сервер и агент следят за размером наблюдаемого журнала и временем последней модификации (для logrt) двумя счетчиками. Кроме того:
    • Также агент использует номера inode (на UNIX/GNU/Linux), индексы файлов (на Microsoft Windows) и MD5 суммы первых 512 байт файла журнала для улучшения выбора в случае когда файлы журнала усекаются и ротируются.
    • На системах UNIX/GNU/Linux предполагается, что файловые системы где хранятся файлы журналов, сообщают числа inode, которые могут быть использованы для слежения за состоянием файлов.
    • На системах Microsoft Windows Zabbix агент определяет тип файловой системе на которой находятся файлы журналов:
      • На файловой системе NTFS 64-битные файловые индексы.
      • На файловых системах ReFS (только Microsoft Windows Server 2012) 128-битные файловые ID.
      • На файловых системах где файловые индексы меняются (т.е. FAT32, exFAT) используется запасной алгоритм для получения разумного подхода в неопределенных условиях, когда сжатие файла журнала приводит в результате к множеству файлов журналов с одинаковым временем изменения.
    • Номера inode, индексы файлов и суммы MD5 собираются Zabbix агентом. Они не передаются Zabbix серверу и теряются в случае остановки Zabbix агента.
    • Не меняйте время последней модификации файлов журналов, используя утилиту 'touch', не копируйте файл журнала с последующим восстановлением его имени (это изменит идентификатор inode файла). В обоих случаях файл будет рассматриваться как другой и будет проанализирован с самого начала, что может привести к дубликатам оповещений.
    • Если имеется несколько совпадающих файлов журналов для элемента данных logrt[] и Zabbix агент следит за наиболее новым из них и этот более новый файл журнал удаляется, сообщение с предупреждением будет записано "there are no files matching "<шаблон регулярного выражения>" in "<директория>". Zabbix агент игнорирует файлы журналы со временем изменения меньше чем последнее время модификации полученное агентом во время проверки элемента данных logrt[].
  • Агент начинает читать файл журнала с той позиции, на которой он остановился последний раз.
  • Количество байт уже проанализированное (счётчик размера) и время последней модификации (счетчик времени) хранятся в базе данных Zabbix и отправляются агенту, для уверенности, что агент начнет читать файл журнала с этой позиции в случаях, когда агент только что был запущен или агент получил элементы данных, которые были ранее деактивированы или не поддерживались. Однако, если агент получает ненулевой размер счётчика от сервера, но элементы данных logrt[] или logrt.count[] не найдены и не удается найти соответствующие файлы, счётчик размера сбрасывается в 0, чтобы начать анализ сначала, если файлы появятся позже.
  • Всякий раз, когда файл журнала становится меньше, чем значение счетчика размера известное агенту, счетчик обнуляется и агент начинает читать файл журнала с самого начала, принимая во внимание счетчик времени.
  • Eсли есть несколько файлов журналов, с одинаковым последним временем модификации файла в соответствующей папке, агент пытается корректно проанализировать все файлы журналы с одинаковым временем модификации и избежать пропущенных данных или проанализировать данные дважды, несмотря на это невозможно охватить все возможные ситуации. Агент не предполагает какую либо определенную схему ротации файлов журналов, либо определяет ее. Когда есть несколько фалов журналов с одинаковым последним временем изменения, агент будет обрабатывать их лексикографически в порядке убывания. Таким образом, для некоторых схем ротации файлы журналы будут проанализированы в их оригинальном порядке. Для других же схем ротации журналов первоначальный порядок файла журнала не будет соблюдаться, что может привести к получению найденных по шаблону строк файла журнала в измененном порядке (проблема не случится, если файлы журнала имеют разное время последнего изменения).
  • Zabbix агент обрабатывает новые записи файла журнала один раз за Период обновления секунд.
  • Zabbix агент отправляет не более чем макс. кол-во строк записей из файла журнала за секунду. Это ограничение предотвращает перегрузку сети и ресурсов процессора и переопределяет значение по умолчанию предусмотренное параметром MaxLinesPerSecond в файле конфигурации агента.
  • Для поиска необходимой строки Zabbix обрабатывает в 10 раза больше строк, чем указано в параметре MaxLinesPerSecond. Таким образом,например, если элемент данных log[] или logrt[] имеет Интервал обновления 1 секунда, по умолчанию агент будет анализировать не более чем 200 строк файла журнала и будет отправлять не более чем 20 совпавших записей Zabbix серверу за одну проверку. Увеличением параметра MaxLinesPerSecond в файле конфигурации агента или указанием параметра макс. кол-во строк в ключе элемента данных, лимит можно увеличить вплоть до 10000 проанализированных записей в журнале и 1000 совпадающих записей для отправки Zabbix серверу за одну проверку. Если Интервал обновления указан значением в 2 секунды, лимиты для одной проверки могут быть увеличены в два раза больше, чем для Интервала обновления в 1 секунду.
  • Кроме того, значения log и log.count всегда ограничены 50% размера буфера отправки у агента, даже если в буфере нет значений не связанных с данными из файлов журналов. Таким образом, чтобы значения макс. кол-во строк будут отправлены за одно подключение (а не за несколько подключений), параметр BufferSize агента должен быть по крайней мере равен макс. кол-во строк x 2.
  • При отсутствии элементов данных журналов весь размер буфера используется для значений не связанных с данными из журналов. Когда появляются значения от файлов журналов они заменяют устаревшие данные не связанные с файлами журналов, если требуется, до максимального уровня 50%.
  • Для записей в файле журнала длиннее 256КБ, только первые 256КБ сопоставляются с регулярным выражением, остальная часть игнорируется. Однако, если Zabbix агент был остановлен в процессе обработки длинной строки, внутреннее состояние агента теряется и длинная строчка может быть проанализирована иначе после перезапуска агента.
  • Специальное примечание для разделителей пути "\": если формат_файла представлен как "file\.log", тогда там не должно быть папки "file", поскольку невозможно однозначно определить, экранируется ли это символ "." или это первый символ в имени файла.
  • Регулярные выражения для logrt поддерживаются только в именах файлов, совпадение регулярного выражения с папкой не поддерживается.
  • В UNIX элементы данных logrt[] становится НЕПОДДЕРЖИВАЕМЫМ, в случае если папка, где файл журнала должен был бы находиться, не существует.
  • В Microsoft Windows, если папка не существует элемент данных не переводится в состояние НЕПОДДЕРЖИВАЕТСЯ (например, если в ключе элемента данных папка указана с ошибкой)
  • Отсутствие файла журнала для элемента данных logrt[] не переводит его в состояние НЕПОДДЕРЖИВАЕТСЯ. Ошибки чтения файлов журналов для элемента данных logrt[] записываются в журнал агента как предупреждения, но не переводят элемент данных в состояние НЕПОДДЕРЖИВАЕТСЯ.
  • Журнал Zabbix агента может быть очень полезен для поиска причин почему элементы данных log[] или logrt[] становятся НЕПОДДЕРЖИВАЕМЫМИ. Zabbix может мониторить свой файл журнала агента, за исключением случая когда он в режиме DebugLevel=4.

Извлечение совпадающей части регулярного выражения

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

Начиная с Zabbix 2.2.0, элементы данных файлов журналов расширены возможностью получения извлечения требуемых значений из строк файла. Добавился дополнительный параметр вывод у элементов данных log и logrt.

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

И так, например

log[/путь/к/файлу,"large result buffer allocation.*Entries: ([0-9]+)",,,,\1]

должен позволить получить количество записей со следующего содержания:

Fr Feb 07 2014 11:07:36.6690 */ Thread Id 1400 (GLEWF) large result
       buffer allocation - /Length: 437136/Entries: 5948/Client Ver: >=10/RPC
       ID: 41726453/User: AUser/Form: CFG:ServiceLevelAgreement

Вернется только число, так как \1 ссылается только на первую интересующую подгруппу: ([0-9]+)

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

Использование параметра максзадержка

Параметр 'максзадержка' в элементах данных журналов позволяет игнорировать более старые строки с целью получения наиболее новых строк проанализированных в течении 'максзадержка' секунд.

Параметр 'maxdelay' > 0, может привести к игнорированию важных записей в файлах журналов и пропуску оповещений. Используйте этот параметр осторожно и на свой страх и риск, только по необходимости.

По умолчанию элементы данных мониторинга журналов забирают все новые строки появляющиеся в файлах журналов. Однако, имеются приложения, которые в некоторых ситуациях начинают записывать огромное количество сообщений в свои файлы журналов. Например, если база данных или DNS сервер недоступны, то такие приложения могут флудить файлы журналов тысячами практически идентичных сообщений об ошибке до тех пор пока не восстановится нормальный режим работы. По умолчанию, все эти сообщения добросовестно анализируются и совпадающие строки оправляются на сервер, как настроено в элементах данных log и logrt.

Встроенная защита от перегрузов состоит из настраиваемого параметра 'макс. кол-во строк' (защищающий сервер от получения слишком большого количества совпадающих строк в журнале) и ограничения в 10*'макс. кол-во строк' (защищает CPU и I/O хоста от перегрузки агентам одной проверкой). Тем не менее имеется 2 проблемы со встроенным механизмом защиты. Первая, на сервер будет отправлено большое количество потенциально не так информативных сообщений, которые займут место в базе данных. Вторая, по причине ограниченного количества строк анализируемых в секунду агент может отставать на часы от самых новых записей в журнале. Вполне вероятно, что вы захотите как можно быстрее быть информированным о текущей ситуации в файлах журналов вместо ковыряния часами старых записей.

Решение этих двух проблем является использование параметра 'максзадержка'. Если параметр 'максзадержка' > 0, во время каждой проверки измеряются количество обработанных байт, количество оставшихся байт и время обработки. Отталкиваясь от этих значений, агент вычисляет оценочную задержку - как много секунд может потребоваться, чтобы проанализировать все оставшиеся записи в файле журнала.

Если задержка не превышает 'максзадержка', тогда агент поступает с анализом файла журнала как обычно.

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

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

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

14287:20160602:174344.206 item:"logrt["/home/zabbix32/test[0-9].log",ERROR,,1000,,,120.0]"
       logfile:"/home/zabbix32/test1.log" skipping 679858 bytes
       (from byte 75653115 to byte 76332973) to meet maxdelay

Количество "to byte" является оценочным, потому что после "прыжка" агент скорректирует позицию в файл к началу строки в журнале, которая может быть в файле чуть дальше или раньше.

В зависимости от того как скорость роста соотносится к скорости анализа файла журнала, вы можете не увидеть "прыжков", а можете увидеть редкие или частые "прыжки", большие или маленькие "прыжки", или даже маленькие "прыжки" каждую проверку. Колебания загрузки системы и сетевые задержки также влияют на вычисления задержки и, следовательно, "прыжки" вперед чтобы не отставать от параметра "максзадержка".

Не рекомендуется указывать 'максзадержка' < 'интервал обновления' (это может привести к частым маленьким "прыжкам").

Заметки по обработке ротации 'copytruncate' файлов журналов

Элемент данных logrt с опцией copytruncate подразумевает, что разные файлы журналов имеют разные записи (по крайней мере штампы времени в них отличаются), поэтому MD5 суммы начальных блоков (до первых 512 байт) будут отличаться. Два файла с одинаковыми MD5 суммами начальных блоков означают, что один из них оригинал, а второй - копия.

Элемент данных logrt с опцией copytruncate делает попытку корректной обработки копий файлов журналов без дубликатов сообщений. Тем не менее, такие варианты как создание нескольких копий файлов журналов с одинаковыми штампами времени, ротация файлов журналов чаще чем интервал обновления logrt[] элемента данных, частый перезапуск агента не рекомендуются. Агент пытается справиться со всеми этими ситуациями, но хорошие результаты не гарантируются при всех обстоятельствах.

Примечания к постоянным файлам у log*[] элементов данных

Нагрузка на I/O

Постоянный файл элементов данных обновляется после успешной отправки каждой партии данных (содержащей данные по элементам данных) на сервер. Например, по умолчанию 'BufferSize' равен 100. Если элемент данных журнала нашел 70 совпадающих записей и затем будет отправлять первые 50 записей одним пакетом, постоянный файл будет обновлен, когда останется отправить 20 записей (может быть с некоторой задержкой, когда накопится больше данных) вторым пакетом, и тогда постоянный файл будет снова обновлен.

Действия, если произошла ошибка связи между агентом и сервером

Каждая совпадающая строка с элементов данных log[] и logrt[] и результат проверки каждого элемента данных log.count[] и logrt.count[] требует свободный слот в выделением 50% области буфера отправки в агенте. Элементы буфера периодически отправляются серверу (или прокси) и слоты буфера становятся снова пустыми.

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

Во время длительных нарушений связи все слоты журналов становятся занятыми и выполняются следующие действия:

  • Проверки элементов данных log[] и logrt[] остановятся. Когда связь восстановится и появятся свободные слоты, проверки вернутся к предыдущей позиции. Совпадающие строки не будут потеряны, они просто будут отправлены позже.
  • Проверки log.count[] и logrt.count[] остановятся, если maxdelay = 0 (по умолчанию). Поведение похоже на элементы данных log[] и logrt[], описанное выше. Обратите внимание, что потеря связи может повлиять на результаты log.count[] и logrt.count[]: например, одна проверка насчитает 100 совпадающих строк в файле журнала, но по причине отсутствия свободных слотом в буфере проверка будет остановлена. Когда связь восстановится агент насчитает те же 100 совпадающих строк, а также 70 новых совпадающих строк. После чего агент отправит количество = 170, так как они найдены за одну проверку.
  • Проверки log.count[] и logrt.count[] при макс. задержка > 0: если не было "прыжка" во время проверки, тогда поведение аналогично описанному выше. Если всё же был "прыжок" через строки файла журнала, тогда позиция после "прыжка" сохранится и вычисленный результат будет отброшен. Таким образом, агент пытается не отставать от увеличивающегося файла журнала, даже в случае проблем со связью.
Назначение постоянных файлов

Когда Zabbix агент запускается, он получает список активных проверок от Zabbix сервера или прокси. Для log*[] метрик агент получает размер обработанного журнала и время модификации для поиска где следует начать мониторинг файла журнала. В зависимости от реального размера файла журнала и времени модификации, полученных от файловой системы, агент решает либо продолжить мониторинг файла журнала с обработанного размера журнала или начать анализ файла журнала с самого его начала.

Работающий агент обслуживает большой набор атрибутов для отслеживания между проверками всех файлов журналов под наблюдением. Этот состояние в памяти теряется при остановке агента.

Новый опциональный параметр ** постоянное_хранилище** указывает директорию для хранения этого состояния в файле по log[], log.count[], logrt[] или logrt.count[] элементам данных. Состояние элемента данных журнала восстанавливается из постоянного файла после перезапуска Zabbix агента.

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

Работа агента с постоянным файлом

При запуске Zabbix агент ничего не знает о постоянных файлах. Только после получения списка активных проверок от Zabbix сервера (прокси) агент видит, что некоторые элементы данных журналов необходимо поддерживать при помощи постоянных файлов в указанных директориях.

В процессе работы агента постоянные файлы открыты для записи (с использованием fopen(имя_файла, "w")) и перезаписываются последними данными. Шанс потери данных постоянного файла, если перезапись и разделение зеркала файловой системы совпадут, очень мал, но специальная обработка такого варианта нет. Запись в постоянный файл НЕ следует принудительной синхронизации с носителями информации (fsync() не выполняется).

Перезапись последними данными выполняется после успешного сообщения о совпадении записи файла журнала или о метаданных (обработанный размер журнала и время модификации) на Zabbix сервер. Это может происходить так часто, как каждый элемент данных проверяет, изменился ли файл журнала.

При остановке агента не требуется никаких специальных действий.

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

Удаление выполняется с задержкой в 24 часа, так как файлы журналов в НЕПОДДЕРЖИВАЕМОМ состоянии не включены в список активных проверок, но могут стать ПОДДЕРЖИВАЕМЫМИ позже и, тогда, их постоянные файлы будут полезны.

Если агент остановлен до истечения 24 часов, тогда устаревшие файлы не будут удалены, так как Zabbix агент более не получает их расположения со стороны Zabbix сервера.

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

Именование и расположение постоянных файлов

Zabbix агент различает активные проверки по их ключам. Например, logrt[/home/zabbix/test.log] и logrt[/home/zabbix/test.log,] разные элементы данных. Изменение logrt[/home/zabbix/test.log,,,10] элемент данных в веб-интерфейсе на logrt[/home/zabbix/test.log,,,20] приведет к удалению logrt[/home/zabbix/test.log,,,10] элемента данных из списка активных проверок агента и созданию logrt[/home/zabbix/test.log,,,20] элемента данных (некоторые атрибуты переносятся сквозь изменения в веб-интерфейсе / сервера, но не на стороне агента).

Имя файла состоит из MD5 суммы ключа элемента данных с длиной ключа, добавляемой для уменьшения возможных пересечений. Например, состояние logrt[/home/zabbix50/test.log,,,,,,,,/home/zabbix50/agent_private] элемента данных будет храниться в постоянном файле c963ade4008054813bbc0a650bb8e09266.

Несколько элементов данных могут использовать одно и то же значение постоянного_хранилища.

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

Если директорию постоянного_хранилища не удается создать или она не существует, или права доступа Zabbix агента не позволяют создавать/записывать/читать/удалять файлы, тогда элемент данных журнала становится НЕПОДДЕРЖИВАЕМЫМ.

Если права доступа к файлам постоянного хранилища отозваны во время работы агента или возникают другие ошибки (например, заполнился диск), тогда ошибки вносятся в файл журнала агента, но элемент данных не становится НЕПОДДЕРЖИВАЕМЫМ.