# - \#6 Мониторинг файлов журналов #### Обзор Zabbix можно использовать для централизованного мониторинга и анализа файлов журналов с/без поддержки ротации журналов. Можно использовать оповещения для предупреждения пользователей, когда файл журнала содержит конкретные строки или шаблоны строк. Для наблюдения за файлом журнала у вас должно быть: - Работающий Zabbix агент на узле сети - Настроенный элемент данных для мониторинга журнала ::: noteimportant Максимальный размер наблюдаемого файла журнала зависит от [поддержки файлов большого объема](/ru/manual/appendix/items/large_file_support). ::: #### Настройка ##### Проверка параметров агента Убедитесь, что в [файле конфигурации агента](/ru/manual/appendix/config/zabbix_agentd): - Параметр 'Hostname' совпадает с именем узла сети в веб-интерфейсе - Указаны сервера в параметре 'ServerActive' для обработки активных проверок ##### Настройка элемента данных Настройте [элемент данных](/ru/manual/config/items/item#overview) для мониторинга журнала: ![](../../../../../assets/ru/manual/config/items/itemtypes/logfile_item.png) Специально для элементов данных наблюдения за журналами вы должны указать: | | | |---|---| |*Тип*|Здесь выберите **Zabbix агент (активный)**.| |*Ключ*|Укажите:
**log**\[/путь/к/файлу/имя\_файла,<регулярное выражение>,<кодировка>,<макс. кол-во строк>,<режим>,<вывод>\]
или
**logrt**\[/путь/к/файлу/регулярное\_выражение\_описывающее\_шаблон\_имени\_файла,<регулярное выражение>,<кодировка>,<макс. кол-во строк>,<режим>,<вывод>\]
Zabbix агент фильтрует записи из файла журнала по регулярному выражению, если оно указано.
Убедитесь, что у файла имеются права на чтение для пользователя 'zabbix', в противном случае состояние элемента данных будет 'unsupported'.
Для получения более подробных сведений смотрите информацию о **log** и **logrt** в разделе [поддерживаемых ключей элементов данных](zabbix_agent#поддерживаемые_ключи_элементов_данных).| |*Тип информации*|Здесь выберите **Журнал (лог)**.| |*Интервал обновления (в сек)*|Этот параметр задает как часто 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 "" in ""'. Zabbix агент игнорирует файлы журналы с временем изменения меньше чем последнее время модификации полученное агентом во время проверки элемента данных `logrt[]`. - Zabbix **2.2.10** исправляет [ZBX-9290](https://support.zabbix.com/browse/ZBX-9290) проблему (внезапное перечитывание всего файла журнала с самого начала). - Агент начинает читать файл журнала с той позиции, на которой он остановился последний раз. - Количество байт уже проанализированное (счётчик размера) и время последней модификации (счетчик времени) хранятся в базе данных Zabbix и отправляются агенту, для уверенности, что агент начнет читать файл журнала с этой позиции в случаях, когда агент только что был запущен или агент получил элементы данных, которые были ранее деаактивированы или не поддерживались. - Всякий раз, когда файл журнала становится меньше, чем значение счетчика размера известное агенту, счетчик обнуляется и агент начинает читать файл журнала с самого начала, принимая во внимание счетчик времени. - Для элементов данных `logrt`, если есть несколько файлов журналов, с одинаковым последним временем модификации файла в соответствующей папке: ```{=html} ``` * До 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\]+)** Вместе с возможностью извлечения и получения числа, значение можно использовать в определениях триггеров.