Всем привет. Вот начал пока что поверхностно разбираться с темой мониторинга логов железяк. У кого то это организовано или может есть какие наработки. Буду рад любой информации. Пока что сам еще не настраивал ничего....собираю инфо.
-
-
Уже обсуждалась несколько раз эта тема. В общем случае есть два момента:
1) Zabbix "подбирать" логи из файла с помощью специальных элементов данных log[], при этом этот элемент может сразу фильтровать данные, а может писать все подряд, а можно сделать несколько элементов данных "подбирающих" один и тот же файл.
Дальше все как обычно по идеалогии Zabbix - триггры где с помощью функций типа regexp ищутся какие то подстроки.
Самая частая проблема заключается в том что сформулировать условие проблемы обычно проще чем условие очистки проблемы, т.е. возвращения в состояние ОК.
2) Идеология триггеров Zabbix применительно к логам оборудования это не совсем то что обычно ожидает сетевой администратор. Вот я в другом треде писал:
Смысл думаю понятен, тебе нужно знать какое событие "ждать" в логе, но в реальности этих событий десятки, если не сотни, тысяч, и большинство событий (строк в логе) обретают смысл только в взаимосвязи с другими событиями.
Я считаю что нужна система работы с логами - удобный вьюер. Триггеры это хорошо, если есть какие то часто повторяющаяся проблема которую мы может детектить по логам, то делаем триггер. А для повседневного использования ничего лучше глаз придумать не получится.
В свое время подобное расширение писали для zabbix, хотя это не совсем расширение. Фича в том что стандартный log[] пишет в базу только строки, но при этом в таблице history_log есть куда других полезных полей, которые сделали для сбора событий Windows - eventlog[], тот же severity который можно использовать для "раскраски" журнала при просмотре. Так вот это "расширение" суть перловый скрипт который "сидит" на файле и отсылает новые строки через zabbix_sender API, в этом случае мы можем передать кроме самого сообщения еще и дополнительные параметры.
А вот просмотра нет. Если ключ для этого элемента данных будет начинаться с 'eventlog[' то при просмотре "последних данных" Zabbix-Frontend покажет расширенную табличку лога с расцветками. Только заточенно это все под идентификаторы (severity) Windows, что бы использовать стандартные syslog(3) важности нужно патчить frontend и добавлять дополнительные severity id и расцветку для них.
Я таким же способов реализовал сбор SNMP Traps c NMS спутникового хаба. NMS шлет трапы, в которых есть идентификатор элемента (это может быть какой то компонент хаба или VSAT - клиентский терминал), важность, код события, имя подсистемы и само сообщение. Я разбираю трапы и через zabbix_sender API отсылаю данные, при этом если событие отностится к VSAT, то отсылаем мы данные на этот "zabbix-host-vsat", вместо того что бы тупо сливать все в один элемент данных.
В этой моей задаче нужно еще дописать вьюер, точнее мне нужен элемент комплексного экрана для просмотра "последних N сообщений", ибо лазить ради просмотра в последние данные мягко говоря неудобно. Планирую этим заняться после миграции на 2.2.x, скорее всего осенью где то.
И последнее, касательно просмотра логов именно сетевого оборудования. В этом случае вьюер должен уметь "квитировать" сообщения - при просмотре мы должны иметь возможность пометить строки и нажать кнопку "скрыть", т.е. мы посмотрели, больше нам их показывать не нужно. Без этого функционала просматривать регулярно логи будет неудобно. Этот функционал нужен для анализа логов магистрального оборудования. А для варианта "тысячи чердачных длинков домашнего ISP" лучше подойдет вариант такой же как я сделал для VSAT.
Comment