Прием и обработка логов по протоколу Syslog
Идея
Принимать логи от различных устройств и серверов по протоколу Syslog.
Сохранять историю логов в метриках, привязанных к узлам, которые прислали данные. Иметь возможность просматривать логи одновременно с другими данными.
Обрабатывать логи: 1. парсить в логах значения полей и сохранять численные метрики на их основе. 2. реагировать на появление сообщений или определенных строк в сообщениях (триггеры)
Реализация
Состоит из двух частей: - организация приема и распределения логов по хостам - обработка логов
Для приема логов используется воркер, работающий в режиме "сервера", то есть пассивно ожидающий данных на сетевом порту UDP:514.
Прием и распределение логов
Сначала нужно настроить узел и метрику, в которые будут попадать все логи.
Для организации приема данных в режиме сервера существует специальных тип метрик Server worker.
С пакетамм glber-server-* поставляются некоторые воркеры, в том числе утилита glb_server_worker для приема данных по протоколу Syslog.
Утилита принимает параметр - ip адрес и номер порта, на котором она будет слушать поток данных.
glb_syslog_worker --listen=0.0.0.0:514
Безопаснее использовать утилиту на непривилегированных портах ( > 1024 ). Если требуется, как в примере выше, запустить на стандартном Syslog порту 514, то нужно выставить флаг привилегированных прав утилите:
chmod +s glb_syslog_worker
Настройте элемент данных с типом Server worker и укажите утилиту glb_syslog_worker в качестве воркера для такого элемента данных.
Чтобы поток логов данных распределять по хостам, нужно использовать правила препроцессинга, которые перераспределяют логи в зависимости от информации в логах.
Воркер glb_syslog_worker преобразует приходяще логи в JSON формат. Поддерживаются и RFC5425 и RFC3164.
Как правило, в данных есть поля, идентифицирующие хост - имя хоста или его ip адрес.
Воркер glb_syslog_worker добавляет поле "client", содержащее ip адрес с которого пришла строка с логом.
Для нахождения узла - приемника логов в конфигруции можно использовать правила поиска узла по его IP адресу, в таком случае ищется узел с IP адресом назначенным на любой из его интерфейсов в конфигурации мониторинга, либо можно сопоставлять узлы по имени, тогда поиск делается по имени хоста.
Для получения значений полей нужно использовать зависимые элементы данных с типом обработки JSON path и значением $.
Пример настройки препроцессинга эелемнта данных для перенаправления логов:
Возмонжо использование обоих правил одно - за другими, если нужно, чтобы работали оба типа поиска. Подробно про поиск узла по данным и перенаправление данных указано в Использование препроцессинга для распределения метрик
Обработка логов
Формат RFC5424 предпочтителен, так как формат подразумевает использование произвольных key-value значений, что дает очень большую гибкость и возможность получить в препроцессинге узла данные из таких пар в отдельные метрики
Обработку логов следует настраивать в шаблонах узлов, на которые логи перераспределяются.
Таким образом можно настроить специфичную обработку в зависимости от типа узла. Парсинг и обработка должны быть настроены в зависимых от основной лог-метрики метриках.
Для работы триггеров можно использовать полученные из логов цифровые значения или функции поиска строковой информации.
Маркировка логов по результатам триггеринга
В случае, если данные типа Log привели к созданию новой проблемы или, наоборот, к удалению существующей проблемы, то такие строки при просмотре истории маркируются в цвет Severity триггера, когда проблема была создана, или в зеленый цвет, когда проблема была разрешена, также в шкале времени отображается ссылка на событие:
