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

Обзор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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