База знаний
Войти

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

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

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

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

  • Агент, работающий на узле сети;
  • Настроенный элемент данных для мониторинга журнала. Максимальный размер наблюдаемого файла журнала зависит от поддержки больших файлов.

Настройка

Необходимо убедиться, что в файле конфигурации Агента:

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

Далее задать параметры элемента данных для мониторинга журнала (рисунок 4).

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

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

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

Примечания:

  • Сервер и Агент следят за размером наблюдаемого журнала и временем последней модификации (для logrt) при помощи двух счетчиков, кроме того:
  • Агент также использует номера inode (на UNIX/GNU/Linux), индексы файлов (на Microsoft Windows) и MD5 суммы первых 512 байтов файла журнала для улучшения выбора в случае, когда файлы журнала усекаются и ротируются.
  • На ОС UNIX/GNU/Linux предполагается, что файловые системы, где хранятся файлы журналов, сообщают номера inode-ов, которые могут быть использованы для отслеживания файлов.
  • На ОС Microsoft Windows Агент определяет тип файловой системы, на которой находятся файлы журналов, и использует:
  • на файловых системах NTFS – 64-битные файловые индексы;
  • на файловых системах ReFS (только с Microsoft Windows Server 2012) – 128-битные ID файлов;
  • на файловых системах, в которых файловые индексы меняются (т.е. FAT32, exFAT), используется запасной алгоритм для получения разумного подхода в неопределенных условиях, когда ротация файла журнала приводит в результате к множеству файлов журналов с одинаковым временем изменения.
  • Номера inode, индексы файлов и суммы MD5 собираются Агентом. Они не передаются Серверу и теряются в случае остановки Агента.
  • Не стоит менять время последней модификации файлов журналов утилитой touch, не копировать файл журнала с последующим восстановлением его имени (это изменит идентификатор inode-файла). В обоих случаях файл будет рассматриваться как другой и будет проанализирован с самого начала, что может привести к дубликатам оповещений.
  • Если имеется несколько совпадающих файлов журналов для элемента данных logrt[], и Агент следит за наиболее новым из них, и этот более новый файл журнала удаляется, то будет записано сообщение с предупреждением: There are no files matching '<шаблон регулярного выражения> in '<директория>. Агент игнорирует файлы журналов со временем модификации меньшим, чем последнее время модификации, полученное Агентом во время проверки элемента данных logrt[].
  • Агент начинает читать файл журнала с той позиции, на которой он остановился последний раз.
  • Количество уже проанализированных байтов (счетчик размера) и время последней модификации (счетчик времени) сохраняются в БД и отправляются Агенту, чтобы убедиться, что Агент начнет читать файл журнала с этой позиции в случаях, когда Агент только что был запущен или Агент получил элементы данных, которые были ранее деактивированы или не поддерживались. Если Агент получает ненулевой счетчик размера от Сервера, но элементу данных logrt[] или logrt.count[] не удается найти соответствующие файлы, то счетчик размера сбрасывается в 0, чтобы начать анализ с самого начала, если файлы появятся позже.
  • Всякий раз, когда файл журнала становится меньше, чем известное Агенту значение счетчика размера, счетчик обнуляется, и Агент начинает читать файл журнала с самого начала, принимая во внимание счетчик времени.
  • Если в директории есть несколько соответствующих файлов журналов с одинаковым временем последней модификации, Агент пытается корректно проанализировать все файлы журналов с одинаковым временем модификации и избежать пропуска данных или повторного анализа тех же данных, хотя этого и нельзя гарантировать во всех возможных ситуациях. Агент ни предполагает какую-либо определенную схему ротации файлов журналов, ни определяет ее. Когда есть несколько файлов журналов с одинаковым временем последнего изменения, Агент будет обрабатывать их лексикографически в порядке убывания. Таким образом, для некоторых схем ротации файлы журналов будут проанализированы в их оригинальном порядке. Для других же схем ротации журналов первоначальный порядок файла журнала не будет соблюдаться, что может привести к получению найденных по шаблону строк файла журнала в измененном порядке (проблема не возникает, если файлы журнала имеют разное время последней модификации).
  • Агент обрабатывает новые записи файла журнала один раз за Период обновления секунд.
  • Агент отправляет не более чем "макс. кол-во строк" записей из файла журнала за секунду. Это ограничение предотвращает перегрузку сети и ресурсов процессора и переопределяет значение по умолчанию, предусмотренное параметром MaxLinesPerSecond в файле конфигурации Агента.
  • Для поиска необходимой строки Подсистема обработает в 10 раз больше строк, чем указано в параметре MaxLinesPerSecond. Таким образом, например, если элемент данных log[] или logrt[] имеет "Интервал обновления" в 1 секунду, то по умолчанию Агент за одну проверку проанализирует не более чем 200 строк файла журнала и отправит Серверу не более 20 совпавших записей. Увеличением параметра MaxLinesPerSecond в файле конфигурации Агента или указанием параметра "макс. кол-во строк" в ключе элемента данных лимит можно увеличить вплоть до 10000 проанализированных записей в журнале и 1000 совпадающих записей для отправки Серверу за одну проверку. Если для параметра "Интервал обновления" указано значение 2 секунды, лимиты для одной проверки могут быть установлены вдвое больше, чем для "Интервал обновления" в 1 секунду.
  • Кроме того, значения log и log.count всегда ограничены 50% размера буфера отправки у Агента, даже если в буфере нет значений, не связанных с данными из файлов журналов. Таким образом, чтобы значения "макс. кол-во строк" были отправлены за одно подключение (а не за несколько подключений), параметр Агента BufferSize должен быть равен по крайней мере "макс. кол-во строк", умноженному на 2. Агент может отсылать данные во время сбора данных из журналов и таким образом освобождать буфер, в то время как Агент-2 остановит сбор данных из журналов до тех пор, пока данные не будут отосланы и буфер освобожден, что выполняется асинхронно.
  • При отсутствии элементов данных журналов весь размер буфера используется для значений, не связанных с данными из журналов. Когда появляются значения от файлов журналов, они при необходимости заменяют более старые данные, не связанные с файлами журналов, до максимально предусмотренного уровня 50%.
  • Если в файле журнала строка длиннее 256 КБ, то только первые 256 КБ сопоставляются с регулярным выражением, остальная часть игнорируется. Но если Агент был остановлен в процессе обработки длинной строки, внутреннее состояние Агента теряется и после перезапуска Агента длинная строчка может быть проанализирована заново и иначе.
  • Специальное примечание для разделителей пути \: если формат_файла представлен как "file.log", то там не должно быть директории "file", поскольку невозможно однозначно определить, экранируется ли это символ . или же точка является первым символом в имени файла.
  • Регулярные выражения для logrt поддерживаются только в именах файлов, совпадение регулярного выражения с директорией не поддерживается.
  • На платформах UNIX элементы данных logrt[] становятся неподдерживаемыми в случае, если директория, где должен был бы находиться файл журнала, не существует.
  • В Microsoft Windows, если директория не существует, то элемент данных не переводится в состояние "НЕ ПОДДЕРЖИВАЕТСЯ" (например, если в ключе элемента данных директория указана с ошибкой).
  • Отсутствие файла журнала для элемента данных logrt[] не переводит его в состояние "НЕ ПОДДЕРЖИВАЕТСЯ". Ошибки чтения файлов журналов для элемента данных logrt[] записываются в журнал Агента как предупреждения, но не переводят элемент данных в состояние "НЕ ПОДДЕРЖИВАЕТСЯ".
  • Журнал Агента может быть очень полезен для поиска причин, почему элементы данных log[] или logrt[] становятся неподдерживаемыми. Подсистема может мониторить свой файл журнала Агента, за исключением случая, когда он в режиме DebugLevel=4 или DebugLevel=5.
  • Поиск знака вопроса при помощи регулярного выражения, например: \?, может давать ложные срабатывания, если текстовый файл содержит символы NUL, поскольку они заменяются Подсистемой на ?, чтобы продолжать обрабатывать строку до символа перевода строки.

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

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

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

Использование параметра "вывод" позволяет обозначить рассматриваемую "подгруппу совпадения".

Например,

log[/путь/к/файлу,"large result buffer allocation.*Entries: ([0-9]+)",,,,\1]

позволит получить количество элементов (Entries) из следующего содержимого:

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

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

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

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

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

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

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

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

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

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

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

Обработка ротации "copytruncate" файлов журналов

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

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

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

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

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

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

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

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

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

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

При запуске Агент получает список активных проверок от Сервера или Прокси. Для log*-метрик Агент получает размер обработанного журнала и время модификации, чтобы найти место начала мониторинга файла журнала. В зависимости от реального размера файла журнала и времени модификации, полученных от файловой системы, Агент решает: либо продолжить мониторинг файла журнала с обработанного размера журнала, либо проанализировать файл журнала с самого его начала.

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

Новый опциональный параметр "постоянное_хранилище" указывает директорию для хранения этого состояния в файле по log, log.count, logrt или logrt.count-элементам данных. Состояние элемента данных журнала восстанавливается из постоянного файла после перезапуска Агента.

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

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

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

В процессе работы Агента постоянные файлы открыты на запись (с использованием fopen(имя_файла,"w")) и перезаписываются последними данными. Шанс потери данных постоянного файла, если перезапись и разделение зеркала файловой системы совпадут, очень мал, специальной обработки такого случая нет. После записи в постоянный файл не следует принудительная синхронизация с носителями информации (fsync() не вызывается).

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

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

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

  • соответствующий элемент данных журнала более не наблюдается;
  • элемент данных журнала перенастраивается на другое расположение "постоянного_хранилища", нежели ранее.

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

Если Агент остановлен до истечения 24 часов, то устаревшие файлы не будут удалены, так как Агент более не получает со стороны Сервера информацию об их расположении.

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

Именование и расположение постоянных файлов

Агент различает активные проверки по их ключам. Например, 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.

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

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

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

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