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

Обзор

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

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

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

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

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

Настройка

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

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

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

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

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

Тип Здесь выберите Zabbix агент (активный).
Ключ Укажите:
log[/путь/к/файлу/имя_файла,<регулярное выражение>,<кодировка>,<макс. кол-во строк>,<режим>,<вывод>]
или
logrt[/путь/к/файлу/регулярное_выражение_описывающее_шаблон_имени_файла,<регулярное выражение>,<кодировка>,<макс. кол-во строк>,<режим>,<вывод>]
Zabbix агент фильтрует записи из файла журнала по регулярному выражению, если оно указано.
Убедитесь, что у файла имеются права на чтение для пользователя 'zabbix', в противном случае состояние элемента данных будет 'unsupported'.
Для получения более подробных сведений смотрите информацию о log и logrt в разделе поддерживаемых ключей элементов данных.
Тип информации Здесь выберите Журнал (лог).
Интервал обновления (в сек) Этот параметр задает как часто 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) двумя счетчиками. Дополнительно, начиная с Zabbix 2.2.4:
    • Также агент использует номера 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', не копируйте файл журнала с последующим восстановлением его имени (это изменит идентификатор иноды файла). В обоих случаях файл будет рассматриваться как другой и будет проанализирован с самого начала, что может привести к дубликатам оповещений.
    • Если есть несколько совпадающих файлов журналов для элемента данных logrt[] и Zabbix агент следит за наиболее новым из них и этот более новый файл журнал удаляется, предупрежающиее сообщение будет записано '"there are no files matching "<regexp mask>" in "<directory>"'. Zabbix агент игнорирует файлы журналы с временем изменения меньше чем последнее время модификации полученное агентом во время проверки элемента данных logrt[].
    • Zabbix 2.2.10 исправляет ZBX-9290 проблему (внезапное перечитывание всего файла журнала с самого начала).
  • Агент начинает читать файл журнала с той позиции, на которой он остановился последний раз.
  • Количество байт уже проанализированное (счётчик размера) и время последней модификации (счетчик времени) хранятся в базе данных Zabbix и отправляются агенту, для уверенности, что агент начнет читать файл журнала с этой позиции в случаях, когда агент только что был запущен или агент получил элементы данных, которые были ранее деаактивированы или не поддерживались.
  • Всякий раз, когда файл журнала становится меньше, чем значение счетчика размера известное агенту, счетчик обнуляется и агент начинает читать файл журнала с самого начала, принимая во внимание счетчик времени.
  • Для элементов данных logrt, если есть несколько файлов журналов, с одинаковым последним временем модификации файла в соответствующей папке:
   * До Zabbix **2.2.4** агент будет читать лексикографически самый наименьший.
          * С Zabbix **2.2.4**:
            * Агент пытается корректно проанализировать все файлы журналы с одинаковым временем модификации и избежать пропущенных данных или проанализировать данные дважны, несмотря на это невозможно охватить все возможные ситуации.
            * Агент не предполагает какую либо определенную схему ротации файлов журналов, либо определяет ее. Когда есть несколько фалов журналов с одинаковым последним временем изменения, агент будет обрабатывать их лексикографически в порядке убывания. Таким образом, для некоторых схем ротации файлы журналы будут проанализированы в их оригинальном порядке. Для других же схем ротации журналов первоначальный порядок файла журнала не будет соблюдаться, что может привести к получению найденных по шаблону строк файла журнала в измененном порядке (проблема не случится, если файлы журнала имеют разное время последнего изменения).
       * Zabbix агент обрабатывает новые записи файла журнала один раз за //Период обновления// секунд.
       * Zabbix агент отправляет не более чем **макс. кол-во строк** записей из файла журнала за секунду. Это ограничение предотвращает перегрузку сети и ресурсов процессора и переопределяет значение по умолчанию предусмотренное параметром **MaxLinesPerSecond** в [[:ru:manual:appendix:config:zabbix_agentd|файле конфигурации агента]].
       * Для поиска необходимой строки Zabbix обрабатывает в 4 раза больше строк, чем указано в параметре MaxLinesPerSecond. Таким образом, например, если элемент данных ''log[]'' или ''logrt[]'' имеет //Интервал обновления// 1 секунда, по умолчанию агент будет анализировать не более чем 400 строк файла журнала и будет отправлять не более чем 100 совпавших записей Zabbix серверу за одну проверку. Увеличением параметра **MaxLinesPerSecond** в файле конфигурации агента или указанием параметра **макс. кол-во строк** в ключе элемента данных, лимит можно увеличить вплоть до 4000 проанализированных записей в журнале и 1000 совпадающих записей для отправки Zabbix серверу за одну проверку. Если //Интервал обновления// указан значением в 2 секунды, лимиты для одной проверки могут быть увеличены в два раза больше, чем для //Интервала обновления// в 1 секунду.
       * Кроме того, данные из файлов журналов всегда ограничены 50% размера буфера отправки у агента, даже если в буфере нет значений не связанных с данными из файлов журналов. Таким образом, значения **макс. кол-во строк** будут отправлены за одно соединение (а не в нескольких соединений), параметр [[:ru:manual:appendix:config:zabbix_agentd|BufferSize]] агента должен быть по крайней мере равен макс. кол-во строк x 2. 
       * При отсутствии данных для элементов данных журналов весь размер буфера используется для значений не связанных с данными из журналов. Когда появляются значения от файлов журналов они заменяют устаревшие данные не связанные с файлами журналов, если требуется, до максимального уровня 50%.
       * Для записей в файле журнала длиннее 256КБ, только первые 256КБ сопоставляются с регулярным выражением, остальная часть игнорируется. Однако, если Zabbix агент был остановлен в процессе обработки длинной строчки, внутреннее состояние агента теряется и длинная строчка может быть проанализирована иначе после запуск агента. Это ограничение появилось начиная с Zabbix **2.2.3**.
       * Специальное примечание для разделителей пути "\": если формат файла представлен как "file\.log", тогда там не должно быть папки "file", поскольку невозможно однозначно определить, экранируется ли это символ "." или это первый символ в имени файла.
       * Регулярные выражения для **logrt** поддерживаются только в именах файлов, совпадение регулярного выражения с папкой не поддерживается.
       * В UNIX элементы данных ''logrt[]'' становится НЕПОДДЕРЖИВАЕМЫМ, в случае если папка не существует где файл журнала должен был бы находиться.
       * В Microsoft Windows, если папка не существует элемент данных не переводится в состояние НЕПОДДЕРЖИВАЕТСЯ (например, если в ключе элемента данных папка указана с ошибкой). Обратите внимание, что до Zabbix 2.2.3 элемент данных переходил в состояние НЕПОДДЕРЖИВАЕТСЯ.
       * Отсутствие файла журнала для элемента данных ''logrt[]'' не переводит его в состояние НЕПОДДЕРЖИВАЕТСЯ (до Zabbix 2.2.3 такое поведение было причиной состояния НЕПОДДЕРЖИВАЕТСЯ).
       * Ошибки чтения файлов журналов для элемента данных ''logrt[]'' записываются в журнал агента как предупреждения, но не переводят элемент данных в состояние НЕПОДДЕРЖИВАЕТСЯ (до Zabbix 2.2.3 такое поведение было причиной состояния НЕПОДДЕРЖИВАЕТСЯ).
       * Журнал Zabbix агента может быть очень полезен для поиска причин почему элементы данных ''log[]'' или ''logrt[]'' становятся НЕПОДДЕРЖИВАЕМЫМИ. Zabbix может мониторить свой файл журнала, за исключением случая когда он в режиме DebugLevel=4.

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

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

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

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

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

log[/path/to/the/file,"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

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

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