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

Обзор

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

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

Чтобы отслеживать файл журнала, у вас должно быть:

• запущен агент Zabbix на узле сети
• настроен элемент данных для мониторинга журнала

Конфигурация

Проверьте параметры агента

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

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

Настройка элемента данных

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

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

Для элементов данных мониторинга логов укажите:

Важные примечания

• Сервер и агент ведут учет размера отслеживаемого журнала и времени последнего изменения (для logrt) в двух счетчиках. Кроме того:
  • Агент также внутренне использует номера inode (в UNIX/GNU/Linux), индексы файлов (в Microsoft Windows) и MD5-суммы первых 512 байт файла журнала для улучшения решений, когда файлы журналов усекаются и ротируются.
  • В системах UNIX/GNU/Linux предполагается, что файловые системы, где хранятся файлы журналов, сообщают номера inode, которые можно использовать для отслеживания файлов.
  • В Microsoft Windows Zabbix agent определяет тип файловой системы, на которой находятся файлы журналов, и использует:
    • Для файловых систем NTFS 64-битные индексы файлов.
    • Для файловых систем ReFS (только начиная с Microsoft Windows Server 2012) 128-битные идентификаторы файлов.
    • Для файловых систем, где индексы файлов изменяются (например, FAT32, exFAT), используется запасной алгоритм, чтобы принимать разумное решение в неопределенных условиях, когда ротация файла журнала приводит к нескольким файлам журнала с одинаковым временем последнего изменения.
  • Номера inode, индексы файлов и MD5-суммы внутренне собираются Zabbix agent. Они не передаются на Zabbix server и теряются при остановке Zabbix agent.
  • Не изменяйте время последнего изменения файла журнала (например, с помощью touch) и не заменяйте отслеживаемый файл журнала путем копирования файла обратно под его исходным именем (это создает новый inode). В любом из этих случаев Zabbix может считать файл другим файлом и перечитать его с начала, что может привести к дублирующимся оповещениям.
  • Если для элемента данных logrt[] существует несколько совпадающих файлов и Zabbix agent отслеживает самый последний из них, а этот самый последний файл журнала удаляется, в журнале записывается предупреждение "there are no files matching "<regexp mask>" in "<directory>". Zabbix agent игнорирует файлы журналов со временем изменения меньше, чем самое позднее время изменения, увиденное агентом для проверяемого элемента данных logrt[].
• Агент начинает чтение файла журнала с того места, на котором остановился в прошлый раз.
• Количество уже проанализированных байт (счетчик размера) и время последнего изменения (счетчик времени) хранятся в базе данных Zabbix и передаются агенту, чтобы гарантировать, что агент начнет чтение файла журнала с этого места в случаях, когда агент только что запущен или получил элементы данных, которые ранее были отключены или не поддерживались. Однако если агент получил от сервера ненулевой счетчик размера, но элемент данных logrt[] или logrt.count[] не может найти совпадающие файлы, счетчик размера сбрасывается в 0, чтобы анализировать с начала, если файлы появятся позже.
• Каждый раз, когда файл журнала становится меньше, чем известный агенту счетчик размера журнала, счетчик сбрасывается в ноль, и агент начинает чтение файла журнала с начала, учитывая счетчик времени.
• Если в каталоге есть несколько совпадающих файлов с одинаковым временем последнего изменения, агент пытается корректно проанализировать все файлы журнала с одинаковым временем изменения и избежать пропуска данных или повторного анализа одних и тех же данных, хотя это не может быть гарантировано во всех ситуациях. Агент не предполагает какой-либо конкретной схемы ротации файлов журнала и не определяет ее. При наличии нескольких файлов журнала с одинаковым временем последнего изменения агент будет обрабатывать их в лексикографически убывающем порядке. Таким образом, для некоторых схем ротации файлы журнала будут анализироваться и сообщаться в их исходном порядке. Для других схем ротации исходный порядок файлов журнала не будет соблюдаться, что может привести к сообщению записей совпавших файлов журнала в измененном порядке (проблема не возникает, если файлы журнала имеют разное время последнего изменения).
• Zabbix agent обрабатывает новые записи файла журнала один раз в Update interval секунд.
• Zabbix agent не отправляет более maxlines строк файла журнала в секунду. Это ограничение предотвращает перегрузку сетевых и CPU-ресурсов и переопределяет значение по умолчанию, заданное параметром MaxLinesPerSecond в файле конфигурации агента.
• Чтобы найти требуемую строку, Zabbix будет обрабатывать в 10 раз больше новых строк, чем задано в MaxLinesPerSecond. Таким образом, например, если элемент данных log[] или logrt[] имеет Update interval 1 секунду, по умолчанию агент будет анализировать не более 200 записей файла журнала и отправлять не более 20 совпавших записей на Zabbix server за одну проверку. При увеличении MaxLinesPerSecond в файле конфигурации агента или задании параметра maxlines в ключе элемента данных лимит можно увеличить до 10000 проанализированных записей файла журнала и 1000 совпавших записей, отправляемых на Zabbix server за одну проверку. Если Update interval установлен в 2 секунды, лимиты для одной проверки будут в 2 раза выше, чем при Update interval 1 секунда.
• Кроме того, значения log и log.count всегда ограничены 50% размера буфера отправки агента, даже если в нем нет других значений, не относящихся к журналам. Поэтому для отправки значений maxlines за одно соединение (а не за несколько) параметр BufferSize агента должен быть не меньше maxlines x 2. Zabbix agent может загружать данные во время сбора журнала и тем самым освобождать буфер, тогда как Zabbix agent 2 остановит сбор журнала до тех пор, пока данные не будут загружены и буфер не освободится; это выполняется асинхронно.
• При отсутствии элементов данных журнала весь размер буфера агента используется для значений, не относящихся к журналам. Когда поступают значения журнала, они при необходимости заменяют более старые значения, не относящиеся к журналам, вплоть до установленного лимита 50%.
• Для записей файла журнала длиной более 256kB только первые 256kB сопоставляются с регулярным выражением, а остальная часть записи игнорируется. Однако если Zabbix agent остановлен во время обработки длинной записи, внутреннее состояние агента теряется, и длинная запись может быть проанализирована снова и иначе после повторного запуска агента.
• Особое примечание для разделителей пути "\": если file_format имеет значение "file\.log", то каталога "file" быть не должно, поскольку невозможно однозначно определить, экранирована ли "." или является первым символом имени файла.
• Регулярные выражения для logrt поддерживаются только в имени файла, сопоставление регулярного выражения для каталога не поддерживается.
• На платформах UNIX элемент данных logrt[] становится NOTSUPPORTED, если каталог, в котором ожидается наличие файлов журнала, не существует.
• В Microsoft Windows, если каталог не существует, элемент данных не станет NOTSUPPORTED (например, если каталог указан с ошибкой в ключе элемента данных).
• Отсутствие файлов журнала для элемента данных logrt[] не делает его NOTSUPPORTED. Ошибки чтения файлов журнала для элемента данных logrt[] записываются как предупреждения в файл журнала Zabbix agent, но не делают элемент данных NOTSUPPORTED.
• Файл журнала Zabbix agent может помочь выяснить, почему элемент данных log[] или logrt[] стал NOTSUPPORTED. Zabbix может отслеживать файл журнала своего агента, кроме случаев, когда установлено DebugLevel=4 или DebugLevel=5.
• Поиск знака вопроса с помощью регулярного выражения, например \?, может приводить к ложноположительным результатам, если текстовый файл содержит символы NUL, поскольку они заменяются на "?" Zabbix для продолжения обработки строки до символа новой строки.

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

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

Элементы данных типа log позволяют извлекать нужные значения из совпавших строк. Это реализуется с помощью дополнительного параметра output в элементах данных log и logrt.

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

Например,

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

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

А благодаря возможности извлекать и возвращать число это значение можно использовать для определения триггеров.

Использование параметра maxdelay

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

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

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

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

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

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

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

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

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" является приблизительным, потому что после "прыжка" агент корректирует позицию в файле до начала строки журнала, которая может оказаться дальше в файле или раньше.

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

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

Примечания по обработке ротации лог-файлов с copytruncate

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

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

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

Назначение постоянных файлов

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

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

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

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

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

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

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

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

Специальные действия при завершении работы агента не выполняются.

После получения списка активных проверок агент помечает устаревшие постоянные файлы для удаления. Постоянный файл становится устаревшим, если:

• соответствующий элемент журнала больше не отслеживается;
  • элемент журнала перенастраивается с другим расположением persistent_dir, чем раньше.

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

Если агент остановлен до истечения 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.

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

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

Если каталог persistent_dir не может быть создан или не существует, либо права доступа для агента Zabbix не позволяют создавать/записывать/читать/удалять файлы, элемент данных log становится NOTSUPPORTED.

Если права доступа к файлам постоянного хранилища удаляются во время работы агента или возникают другие ошибки (например, заполнен диск), ошибки записываются в файл журнала агента, но элемент журнала не переходит в состояние NOTSUPPORTED.

Нагрузка на 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 новых совпадающих строк. Теперь агент отправляет count = 170, как если бы они были найдены в одной проверке.
• Проверки log.count[] и logrt.count[] с maxdelay > 0: если во время проверки не было "jump", поведение аналогично описанному выше. Если произошел "jump" через строки файла журнала, то позиция после "jump" сохраняется, а подсчитанный результат отбрасывается. Таким образом, агент старается не отставать от растущего файла журнала даже в случае сбоя связи.

Обработка ошибок компиляции и выполнения регулярных выражений

Если регулярное выражение, используемое в элементе данных log[], logrt[], log.count[] или logrt.count[], не может быть скомпилировано библиотекой PCRE или PCRE2, то элемент данных переходит в состояние NOTSUPPORTED с сообщением об ошибке.
Чтобы продолжить мониторинг элемента данных журнала, необходимо исправить регулярное выражение.

Если регулярное выражение успешно компилируется, но дает сбой во время выполнения (для одной или всех записей журнала), то элемент данных журнала остается поддерживаемым, и мониторинг продолжается.
Ошибка выполнения записывается в файл журнала агента Zabbix (без записи из файла журнала).

Частота записи ограничена одной ошибкой выполнения на одну проверку, чтобы агент Zabbix мог мониторить собственный файл журнала.
Например, если анализируются 10 записей и 3 записи завершаются ошибкой выполнения regexp, в журнале агента будет создана одна запись.

Исключение: если MaxLinesPerSecond=1 и интервал обновления равен 1 (за одну проверку разрешено анализировать только 1 запись), то ошибки выполнения regexp не записываются.

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