Обновить
0
0

Пользователь

Отправить сообщение
Это не всегда удобно для администрирования. В том плане что для того чтобы вытащить эту информацию и повесить на нее какой-то триггер — необходимо подключаться к базе данных, а я, в общем случае, полагаю что пускать систему мониторинга внутрь приложения, тем более в базу, идея не очень хорошая. В том случае если вывод лога ведется в штатную систему журналирования (syslog, eventlog) — данный триггер проще сделать и обслуживать.
Это зависит от того, насколько грамотно прописан модуль который отвечает за этот процесс…
Кроме того существует волшебная опция debug, включение которой должно выводить больше информации, вот ее-то и можно выкладывать в файл.

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

Кроме того, наверное данные вы тоже предпочитаете таскать из файлов, а не из базы данных, ведь парсинг строки куда удобнее…
Архитектурно мониторинговая система вынесена за пределы сети где находятся ESXi (да, я знаю что это решается с помощью nagios прокси, но зачем нам лишняя точка отказа). Кроме того у нас используется пассивная система проверок, т.е. сам по себе Nagios проверок не делает, только обрабатывает и хранит данные мониторинга, а SNMP у нас больше нигде используется.
И по SNMP например затруднительно получить лог с RAID контроллера, а это иногда важно.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность