Опции - Логирование

ZoneMinder имеет мощную систему логирования. Понимание того, как настроить логирование, поможет вам лучше отслеживать проблемы. Настройки логирования доступны через Параметры->Логирование. Давайте пройдемся по примеру. Но сначала вот базовая структура того, как работает логирование:

Каждый компонент ZoneMinder может генерировать различные типы логов. Обычно ERR относится к ошибке, которую следует проверить (в некоторых случаях они являются преходящими во время запуска/остановки, в этом случае они обычно безвредны). INF - это информационные журналы, WAR - это предупреждающие журналы, которые могут иметь потенциальную возможность вызвать проблемы, в то время как DBG - это журналы отладки, которые полезны, когда вам нужно исправить проблему
Вы можете решить, где записываются эти журналы. Обычно ZoneMinder записывает журналы в несколько источников: * Системный журнал * База данных * отдельные файлы, относящиеся к каждому компоненту внутри папки для ведения журнала, которая была конфигурирована

Рассмотрим, например, что вы пытаетесь понять, почему ваш «zmc 11» (т.е. Монитор 11) не работает. Очевидно, вам нужно включить журналы отладки, если вы не можете разобраться, что происходит с журналами событий по умолчанию. Но вы бы не хотели записывать журналы отладки в базу данных. Возможно, вы также не хотите, чтобы они засоряли ваш системный журнал и хотели бы записывать журналы отладки только в файл журнала отладки этого компонента (/var/log/zm/zmc_m11.log например). Вот где полезно настроить свою систему логирования.

Пример логирования

В примере выше я настроил свою систему логирования следующим образом:

Я хочу только регистрировать сообщения уровня INFO в Сислог
Я хочу, чтобы журналы отладки записывались только в файл компонента.
Когда речь заходит о моем WEBLOG (то, что я вижу в окне ZM Log) и логе базы данных, я хочу только FATAL-логи (возможно, вам стоит установить это на WAR или INF)
Я не хочу сохранять лог-файлы FFMPEG (это была новая функция). FFMPEG генерирует собственный лог-лог, который вы должны включать только в том случае, если вы пытаетесь разобраться с проблемами воспроизведения видео
Я включил LOG_DEBUG (если вы этого не сделаете, логи DEBUG записываться не будут)
LOG_DEBUG_TARGET полезен, если вы не хотите включать журналы DEBUG для каждого компонента. В этом случае меня интересует только отладка сервера событий ZM и монитора 11. Ничто другое не будет иметь журналов отладки включенными.
Я предпочитаю оставлять LOG_DEBUG_FILE пустым. Это создает аккуратно разделенные файлы в моей папке логов с именами компонентов

Другие параметры логирования оставляются по умолчанию, как показано ниже:

Более подробное объяснение различных вариантов логов

LOG_LEVEL_SYSLOG - ZoneMinder теперь более интегрирован между компонентами и позволяет вам указать место назначения для вывода лога и отдельные уровни для каждого. Этот параметр позволяет контролировать уровень вывода лога в системный журнал. Бинарники ZoneMinder всегда записывали в системный журнал, но теперь также включают скрипты и веб-логи. Чтобы сохранить предыдущее поведение, вы должны убедиться, что это значение установлено на Info или Warning. Этот параметр контролирует максимальный уровень записи лога, поэтому Info включает предупреждения и ошибки и т. д. Чтобы полностью отключить, установите этот параметр в None. Вам следует проявлять осторожность при установке этого параметра в Debug, так как это может серьезно повлиять на производительность системы. Если вы хотите отладить, вам также потребуется установить уровень и компонент ниже

LOG_LEVEL_FILE - Логгирование в ZoneMinder теперь более интегрировано между компонентами и позволяет вам указать место назначения для вывода логов и отдельные уровни для каждого. Этот параметр позволяет контролировать уровень вывода логов, которые идут в отдельные файлы журналов, написанные конкретными компонентами. Это то, как работала запись логов ранее, хотя и полезно для отслеживания проблем в конкретных компонентах, это также приводило к большому количеству разрозненных файлов журналов. Чтобы сохранить это поведение, убедитесь, что это значение установлено на Info или Warning. Этот параметр контролирует максимальный уровень записи логов, поэтому Info включает в себя предупреждения и ошибки и т. д. Чтобы полностью отключить, установите этот параметр в None. Вам следует соблюдать осторожность при установке этого параметра в Debug, так как это может серьезно повлиять на производительность системы, хотя вывод файла имеет меньшее влияние, чем другие параметры. Если вы хотите отладить, вам также потребуется установить уровень и компонент ниже

LOG_LEVEL_WEBLOG - Логгирование в ZoneMinder теперь более интегрировано между компонентами и позволяет вам указать место назначения для вывода лога и отдельные уровни для каждого. Эта опция позволяет контролировать уровень вывода логов из веб-интерфейса, которые отправляются в журнал ошибок httpd. Обратите внимание, что только веб-логи от PHP и JavaScript файлов включены, и поэтому эта опция действительно полезна только для изучения конкретных проблем с этими компонентами. Эта опция контролирует максимальный уровень записи логов, поэтому Информация включает Предупреждения и Ошибки и т. д. Чтобы полностью отключить, установите эту опцию в None. Вам следует проявлять осторожность при установке этой опции в Debug, так как это может серьезно повлиять на производительность системы. Если вы хотите отладить, вам также потребуется установить уровень и компонент ниже

LOG_LEVEL_DATABASE - ZoneMinder теперь более интегрирован между компонентами и позволяет вам указать место назначения для вывода лог-вывода и индивидуальные уровни для каждого. Эта опция позволяет контролировать уровень вывода лог-вывода, записываемого в базу данных. Это новая опция, которая может сделать просмотр лог-вывода проще и более интуитивно понятной, а также облегчает получение общего представления о том, как работает система. Если у вас большая или очень загруженная система, возможно, что использование этой опции может замедлить вашу систему, если таблица станет очень большой. Убедитесь, что вы используете опцию LIMIT_DATABASE_LOG, чтобы держать таблицу под контролем. Эта опция контролирует максимальный уровень логгирования, который будет записан, поэтому Info включает в себя предупреждения и ошибки и т. д. Чтобы полностью отключить, установите эту опцию в None. Вам следует проявлять осторожность при установке этой опции в Debug, так как это может серьезно повлиять на производительность системы. Если вы хотите отладить, вам также потребуется установить уровень и компонент ниже

LOG_DATABASE_LIMIT - Если вы используете логирование базы данных, то возможно быстро накопить большое количество записей в таблице Логи. Этот параметр позволяет указать, сколько из этих записей следует сохранить. Если вы установите этот параметр в число больше нуля, то это число будет использоваться для определения максимального количества строк, меньше или равное нулю указывает на отсутствие ограничений и не рекомендуется. Вы также можете установить это значение в значения времени, такие как „<n> день“, что ограничит записи логов теми, которые были созданы позже этого времени. Вы можете указать „час“, „день“, „неделя“, „месяц“ и „год“, обратите внимание, что значения должны быть единственными (в конце нет „s“). Таблица Логи периодически очищается, поэтому возможно, что в течение короткого времени будет присутствовать больше записей, чем ожидалось.

LOG_DEBUG» - ZoneMinder components usually support debug logging available to help with diagnosing problems. Binary components have several levels of debug whereas more other components have only one. Normally this is disabled to minimise performance penalties and avoid filling logs too quickly. This option lets you switch on other options that allow you to configure additional debug information to be output. Components will pick up this instruction when they are restarted.

LOG_DEBUG_TARGET - Доступны три уровня отладки. Оставление этого поля пустым означает, что все компоненты будут использовать дополнительную отладку (не рекомендуется). Установка этого параметра в „_<компонент>“, например, „_zmc“, ограничивает дополнительную отладку только этому компоненту. Установка этого параметра в „_<компонент>_<идентификатор>“, например, „_zmc_m1“, ограничивает дополнительную отладку только этому экземпляру компонента. Это обычно то, что вы, вероятно, хотите сделать. Чтобы отлаживать скрипты, используйте их имена без расширения .pl, например, „_zmvideo“ и для отладки проблем с веб-интерфейсом используйте „_web“. Вы можете указать несколько целей, разделив их символами „|“.

LOG_DEBUG_LEVEL - Доступно 9 уровней отладки, где более высокие числа означают более глубокую отладку, а уровень 0 означает отсутствие отладки. Однако не все уровни используются всеми компонентами. Также если есть отладка на высоком уровне, обычно это означает, что она будет выводиться в таком объеме, что это может помешать нормальной работе. По этой причине вы должны устанавливать уровень осторожно и осмотрительно, пока не будет присутствовать желаемый уровень отладки. Скрипты и веб-интерфейс имеют только один уровень, поэтому это опция включения/выключения для них.

LOG_DEBUG_FILE - Этот параметр позволяет указать другое место назначения для вывода отладочной информации. Все компоненты имеют по умолчанию файл журнала, который обычно находится в /tmp или /var/log, и именно туда будет записываться отладка, если это значение пустое. Добавление пути здесь временно перенаправит отладку и другие сообщения журнала в этот файл. Этот параметр является простым именем файла, и если вы отлаживаете несколько компонентов, они все попытаются записать в один и тот же файл с нежелательными последствиями. Приложение символа „+“ к имени файла приведет к созданию файла с расширением „.<pid>“, содержащим ваш процесс ID. Таким образом, отладка из каждого запуска компонента будет храниться отдельно. Это рекомендуется, так как это также предотвратит последующую перезапись того же журнала. Убедитесь, что разрешения установлены таким образом, чтобы разрешить запись в файл и каталог, указанные здесь.

LOG_CHECK_PERIOD - Когда ZoneMinder записывает события в базу данных, она может ретроспективно анализировать количество предупреждений и ошибок, чтобы рассчитать общее состояние здоровья системы. Этот параметр позволяет вам указать, какой период исторических событий используется для этого расчета. Это значение выражается в секундах и игнорируется, если LOG_LEVEL_DATABASE установлено в None.

LOG_ALERT_WAR_COUNT - Когда ZoneMinder записывает события в базу данных, она может ретроспективно анализировать количество предупреждений и ошибок, которые произошли, чтобы рассчитать общее состояние здоровья системы. Этот параметр позволяет вам указать, сколько предупреждений должно было произойти в течение определенного периода времени, чтобы сгенерировать общее состояние системы тревоги. Значение 0 означает, что предупреждения не учитываются. Это значение игнорируется, если LOG_LEVEL_DATABASE установлено в None.

LOG_ALERT_ERR_COUNT - Когда ZoneMinder записывает события в базу данных, он может ретроспективно анализировать количество предупреждений и ошибок, которые произошли, чтобы рассчитать общее состояние здоровья системы. Этот параметр позволяет вам указать, сколько ошибок должно было произойти в течение определенного периода времени, чтобы вызвать общий системный сигнал тревоги. Значение 0 означает, что ошибки не учитываются. Это значение игнорируется, если LOG_LEVEL_DATABASE установлено в None.

LOG_ALERT_FAT_COUNT - Когда ZoneMinder записывает события в базу данных, она может ретроспективно анализировать количество предупреждений и ошибок, которые произошли, чтобы рассчитать общее состояние здоровья системы. Этот параметр позволяет вам указать, сколько смертельных ошибок (включая паники) должно было произойти в течение определенного периода времени, чтобы вызвать общее состояние тревоги системы. Значение 0 означает, что смертельные ошибки не учитываются. Это значение игнорируется, если LOG_LEVEL_DATABASE установлено в None.

LOG_ALARM_WAR_COUNT - Когда ZoneMinder записывает события в базу данных, она может ретроспективно анализировать количество предупреждений и ошибок, которые произошли, чтобы рассчитать общее состояние здоровья системы. Этот параметр позволяет вам указать, сколько предупреждений должно было произойти в течение определенного периода времени, чтобы вызвать общее состояние тревоги системы. Значение 0 означает, что предупреждения не учитываются. Это значение игнорируется, если LOG_LEVEL_DATABASE установлено в None.

LOG_ALARM_ERR_COUNT - Когда ZoneMinder записывает события в базу данных, она может ретроспективно анализировать количество предупреждений и ошибок, которые произошли, чтобы рассчитать общее состояние здоровья системы. Этот параметр позволяет вам указать, сколько ошибок должно было произойти в течение определенного периода времени, чтобы вызвать общее состояние тревоги системы. Значение 0 означает, что ошибки не учитываются. Это значение игнорируется, если LOG_LEVEL_DATABASE установлено в None.

LOG_ALARM_FAT_COUNT - Когда ZoneMinder записывает события в базу данных, она может ретроспективно анализировать количество предупреждений и ошибок, которые произошли, чтобы рассчитать общее состояние здоровья системы. Этот параметр позволяет вам указать, сколько смертельных ошибок (включая паники) должно было произойти в течение определенного периода времени, чтобы вызвать общее состояние тревоги системы. Значение ноль означает, что смертельные ошибки не учитываются. Это значение игнорируется, если LOG_LEVEL_DATABASE установлено в None.

RECORD_EVENT_STATS - Эта версия ZoneMinder записывает подробную информацию о событиях в таблице Статистика. Это может помочь в профилировании оптимальных настроек для Зон, хотя это сложно в настоящее время. Однако в будущих выпусках это будет сделано проще и интуитивно понятно, особенно с большим количеством событий. По умолчанию вариант „да“ позволяет собирать эту информацию сейчас в ожидании этого, но если вы обеспокоены производительностью, вы можете отключить это, в результате чего не будет сохраняться информация о статистике.

RECORD_DIAG_IMAGES - Помимо записи статистики событий, вы также можете записывать промежуточные диагностические изображения, которые отображают результаты различных проверок и обработки, происходящих при попытке определить, произошло ли событие тревоги. Для каждого кадра и зоны для каждого события тревоги или предупреждения генерируется несколько таких изображений, поэтому это может оказать значительное влияние на производительность. Включайте эту настройку только для целей отладки или анализа и не забывайте снова отключить ее, когда она больше не требуется.

RECORD_DIAG_IMAGES_FIFO - Добавляет опции fifo для диагностических изображений для значительно менее инвазивного режима диагностики. Диагностические изображения записываются только тогда, когда есть клиент (например, веб-браузер), который слушает их. Если нет активного клиента, подключенного, FIFO-изображения пропускаются. Обратите внимание, что эта функция также требует, чтобы RECORD_DIAG_IMAGES был включен. Примечание: Ваш монитор должен быть в каком-то режиме записи (modect/mocord/etc.)

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

После включения RECORD_DIAG_IMAGES и нового RECORD_DIAG_IMAGES_FIFO в настройках журнала вы можете затем использовать 3 новых удаленных URL-адреса потока:

Дельта-изображения в виде потока MJPEG (отлично видно, где оно видит движение!): https://portal/zm/cgi-bin/nph-zms?mode=jpeg&bitrate=2&buffer=0&source=fifo&format=delta&monitor=1&maxfps=5&<auth> (измените монитор, портал на свои значения. <auth> может быть &user=user&pass=pass или &auth=authval или &token=access_token)
Изображения, используемые в качестве эталона, в виде потока MJPEG: https://portal/zm/cgi-bin/nph-zms?mode=jpeg&bitrate=2&buffer=0&source=fifo&format=reference&monitor=1&maxfps=5&<auth> (измените монитор, портал на свои значения. <auth> может быть &user=user&pass=pass или &auth=authval или &token=access_token)
текст json сырой поток: https://portal/zm/cgi-bin/nph-zms?&buffer=0&source=fifo&format=raw&monitor=1&<auth> (измените монитор, портал на свои значения, <auth> может быть &user=user&pass=pass или &auth=authval или &token=access_token)

Это будет выводить текстовый поток в браузере, как:

{"zone":5,"type":"ALRM","pixels":778661,"avg_diff":50}
{"zone":5,"type":"FILT","pixels":762704}
{"zone":5,"type":"RBLB","pixels":728102,"blobs":5}
{"zone":5,"type":"FBLB","pixels":728021,"blobs":2}
{"zone":6,"type":"ALRM","pixels":130844,"avg_diff":44}
{"zone":6,"type":"FILT","pixels":128608}

Сейчас есть четыре типа событий: Будильник (ALRM), Фильтр (FILT), Необработанный Блок (RBLB) и Фильтрованный Блок (FBLB), которые соответствуют этим стадиям анализа. Он покажет количество пикселей, обнаруженных (вместе со средним различием пикселя по пороговому значению) и количество блоков на каждой стадии.

Например, вот поток изображения дельта-карты с одного из моих мониторов, отображаемый в режиме реального времени:

https://myserver/cgi-bin/nph-zms?mode=jpeg&bitrate=2&buffer=0&source=fifo&format=delta&monitor=8&maxfps=5&user=admin&pass=mypass

DUMP_CORES - Когда возникает неисправимая ошибка в процессе ZoneMinder, традиционно она захватывается и детали записываются в журналы для помощи в удаленном анализе. Однако в некоторых случаях диагностировать ошибку проще, если создать файл дампа памяти процесса (core file), который представляет собой дамп памяти процесса в момент возникновения ошибки. Этот файл можно проанализировать в отладчике, и он может содержать больше или более подробную информацию, чем та, что доступна из журналов. Этот параметр рекомендуется только для продвинутых пользователей, в противном случае оставьте его по умолчанию. Обратите внимание, что использование этого параметра для создания файлов дампа памяти приведет к тому, что в журналах процессов не будет записи о том, что процесс умер, они просто остановятся, однако журнал zmdc все равно будет содержать запись. Также обратите внимание, что вам, возможно, придется явно разрешить создание файлов дампа памяти на вашей системе с помощью команды „ulimit -c“ или другими средствами, иначе файл не будет создан независимо от значения этого параметра.