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

Обзор

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

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

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

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

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

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

1. Соответствующий элемент данных журнала больше не отслеживается.
2. Элемент данных журнала перенастроен с другим расположением persistent_dir, отличным от прежнего.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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