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

Zabbix умет анализировать любой лог файл, сохранять его в свою базу, рассылать алерты по каким-то событиям. Я решил использовать эту возможность для анализа лог файла утилиты acpupsd для отправки оповещений об отключении электричества. Решается данная задача стандартным функционалом заббикса, описанного в документации.

Введение

Ранее я рассказывал об использовании утилиты управления упсами марки apc — apcupsd. Я показал, как установить apcupsd на hyper-v и xenserver для корректного завершения работы при отключении электричества. Рекомендую ознакомиться, если вас интересует этот вопрос. Его не всегда получается быстро и удобно решить. На помощь приходит apcupsd.

Указанные конфигурации у меня успешно работают, проверено годами. Я решил настроить отправку оповещений на почту через zabbix при пропадании электричества. Да и просто хочется хранить информацию об инцидентах в одном месте. Почтовые сообщения не всегда будут доставлены, нужно следить, чтобы на резервное питание были подключены все устройства, которые обеспечивают связь с интернетом. Частенько бывает, что при выключении электричества у провайдера так же выключается оборудование и связи нет. Либо ваш свитч, к которому подключен сервер, выключится и сообщение не будет доставлено.

Заранее позаботьтесь об этих вещах. Пишу об этом, потому что сам недавно на одном объекте все запитал от упсов, но забыл про свитч. В итоге об отключении электричества я узнал уже после того, как его вернули назад и сервера автоматически поднялись. Если у вас еще не настроен сервер мониторинга, рекомендую мою подробную статью с видео об установке и настройке zabbix на centos 9 или установка zabbix 3.4 на debian 9.

Настройка мониторинга логов

Для того, чтобы мониторить лог файл, на сервере должен быть установлен zabbix agent, а сам сервер добавлен в панель мониторинга. Я буду следить за логом программы apcupsd, который располагается по пути /var/log/apcupsd.events. Идем в веб интерфейс заббикса и добавляем новый итем к интересующему нас хосту. Если у вас таких будет несколько, то создавайте сразу шаблон. В моем случае у меня один сервер, поэтому я буду добавлять новый элемент сразу на него.

Создаем новый итем со следующими параметрами:

Name	Имя нового итема. Можете указать любое название.
Type	Тип элемента. Обязательно выбираем Zabbix agent (active). По-умолчанию будет другой тип стоять.
Key	Ключ данных, log — тип, в квадратных скобках путь до лог файла.
Type of information	Указываем тип информации, поступающей в итем.

Остальные параметры оставляете на свое усмотрение. Рекомендую время обновления итема ставить поменьше, чтобы оперативно получить информацию об инциденте. У меня стоит 30 секунд.

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

Но это только пол дела. Мы стали собирать логи, теперь нам нужно настроить отправку оповещения при пропадании электричества.

Создание триггера на событие из лога

Мы будем слать оповещение не только в момент отключения электричества, но и тогда, когда оно снова появится. Так что в триггере будут два условия:

1. Условие активации события.
2. И условие его прекращения.

Открываем вкладку с триггерами хоста и добавляем туда новый триггер со следующими параметрами:

Name	Имя триггера. Может быть любым.
Problem expression	=1
Recovery expression	=1

Рассказываю подробнее, что тут написано. xm-xen02 — имя сервера. Power failure. — строка в лог файле, которая появляется при отключении электричества. Когда оно возвращается, появляется запись Power is back. В общем виде лог выглядит примерно следующим образом:

Становится понятно, почему я взял именно эти строки. На этом все. После сохранения триггера он начнет работать и следить за итемом, который собирает строки из лога. Как только появятся строки, попадающие под условие, вы получите оповещение.

Заключение

Отладить работу оповещения об отключении электричества достаточно трудно, так как дергать по этому поводу шнур с питанием не хочется. Я пошел другим путем. Во время отладки использовал общий лог файл /var/log/messages и останавливал службу chronyd. Во время остановки, она пишет информацию об этом в лог файл, а при запуске так же сообщает, что запустилась. Я просто настроил итем и триггер на нужные строки и убедился, что все работает как надо. После этого уже сделал по аналогии итемы и триггеры для apcupsd. Рекомендую поступить похожим образом и потестировать функционал.

Zabbix — Мониторинг логов

Zabbix — Мониторинг логов

Задача

Требуется мониторить логи Centos 7 /var/log/messages на предмет записи «Out of memory: Kill process»

Подготовка сервера, который мы будем мониторить

Добавляем файл /var/log/messages в группу zabbix и назначить на него права доступа 640

Проверяем настройки zabbix agent.

Настройка мониторинга в Zabbix

Настройки — Узлы сети — выбираем наш сервер, на котором мы будем мониторить логи.

Добавляем новую группу элементов данных:
Переходим во вкладку «Группы элементов данных», нажимаем «Создать группу элементов данных», я назвал ее log.

Добавляем новый элемент данных:
Переходим во вкладку «Элементов данных», нажимаем «Создать элемент данных»

Добавляем новый триггер:
Переходим во вкладку «Триггеры», нажимаем «Создать триггер»

Триггер срабатывает при наличии строки Kill в пересылаемых данных и отключается через 30 секунд отсутствия новых данных.

UPD 03.04.2019

Бывают случаи, когда в элементах данный узла сети висит сообщение

И из-за этого элемент данных не активен, следовательно логи не приходят на почту

Это случается из-за следующих моментов:

• SeLinux блокирует zabbix-agent
• права доступа на файл /var/log/messages принадлежат пользователю root

Что бы добавить zabbix-agent в исключение для SeLinux, устанавливаем утилиту policycoreutils

И выполняем команду

После этого надо перезапустить zabbix-agent

Что бы открыть доступ для zabbix-agent на чтение файла /var/log/messages, изменим права доступа

Удобный мониторинг Syslog сообщений c сетевых железок в Zabbix

Неотъемлемой частью сетевого мониторинга является сбор логов с контролируемых серверов и прочих железок. Ведь сколько бы мы ни создали отдельных элементов данных и триггеров к ним, в какой-то момент возникнет ситуация, что что-то важное мы упустили из виду и не контролируем. Итог: «У нас ничего не работает», а система мониторинга говорит, что все хорошо.

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

Как это сделать на серверах или компьютерах, где установлен заббикс-агент, многие знают — есть встроенные элементы данных log[], logrt[].

Но как быть, когда нужно собирать логи с сетевого оборудования, на которое никак не водрузить Zabbix-agent’а? Вообще-то можно, конечно, настроить syslog-сервер на том же ПК, на которой есть заббикс-агент, а дальше при помощи log[] переносить эти данные в заббикс. Вот только элементы данных и триггеры по нему будут прикреплены к узлу сети с заббикс-агентом, что интуитивно малопонятно. А можно ли прикрепить эти данные непосредственно к сетевому устройству? Можно.

Для этого нам понадобится zabbix_sender, Zabbix API и rsyslog на машине с заббикс-сервером или заббикс-прокси. В качестве бонуса также получим быстрый контекстный переход в журнал syslog-сообщений с карты сети.
Как будет выглядеть результат? Ну, примерно вот так:
Контекстный вызов:

How to

Большими мазками архитектура решения выглядит вот так:

1. Все логи с сетевых устройств падают на сервер с Zabbix сервером или прокси, на котором по совместительству расположен rsyslog.
2. rsyslog запускаем скрипт, который определяет (3) с какого узла сети в Заббиксе пришло сообщение
4. Сообщение уходит в заббикс через утилиту zabbix_sender
Ну что, начнем «прорубать» путь сообщению от сетевой железки до заббикс

На сетевом оборудовании

Тут все просто. Укажите в качестве адресата для syslog-сообщений машину с Zabbix-сервером или Zabbix-proxy. Настройте оборудование на отсылку сообщений любых severity и facility.

На каком-нибудь D-Link’e это может выглядеть примерно вот так:

А скажем на Cisco роутере вот так:

Настроили? Идем дальше.

В веб-интерфейсе Заббикса

Начнем с самого простого и понятного. В Zabbix’e создадим шаблон Template_Syslog и добавим в нем один единственный элемент данных:

Заполним поля следующим образом:

Поле	Значение	Примечание
Имя	Syslog
Тип	Zabbix траппер
Ключ	syslog	Важно, чтобы было именно такое имя (для дальнейшей корректной работы Zabbix API)
Тип информации	Журнал(лог)
Формат времени в журнале(логе)	yyyyxMMxddxhhxmmxssxxxxxx	Маска для правильного определения даты по формату в RFC5424

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

Syslog-сервер

Настроим syslog-сервер на хосте с Zabbix-сервером. В нашем случае это распостраненный rsyslog, который идет во многих дистрибутивах Linux. Если у вас syslog-ng, то там все можно сделать практически так же.

В самом простом случае syslog-сервер раскладывает полученные сообщения по файлам в зависимости от facility и severity сообщений. Однако, есть и другие возможности. Например, в rsyslog существует возможность запуска произвольного скрипта для каждого сообщения. Этой функцией мы и воспользуемся.
Второй вопрос, который нужно решить — идентификация оборудования, чтобы определить, в лог какого узла добавлять сообщение в Заббиксе. Его мы решим, добавив в строчку с самим сообщением ip-адрес источника в квадратных скобах.

Для всего этого создадим конфиг-файл /etc/rsyslog.d/zabbix_rsyslog.conf

Мы только что создали настройку для rsyslog, которая будет все сообщения полученные не с локального хоста форматировать определенным образом и запускать наш скрипт /usr/local/bin/zabbix_syslog_lkp_host.pl с syslog-сообщением в качестве аргумента.

Заодно в разделе #exclude unwanted messages мы можем отбрасывать засоряющие логин сообщения, если они заранее известны. Пара сообщений оставлена тут в качестве примера.

Под конец настройки rsyslog не забудьте еще раскомментировать следующие строки в файле /etc/rsyslog.conf для приема Syslog-сообщений по сети через UDP.:

И все же, что делает скрипт /usr/local/bin/zabbix_syslog_lkp_host.pl, который мы указали запускать rsyslog’у? Если вкратце, он просто через zabbix_sender шлет данное сообщение на Zabbix_server или на Zabbix_proxy, ну вот примерно по такому шаблону:

ОТРЕДАКТИРОВАНО: А на самом деле запускать стандартную утилиту zabbix_sender вовсе не обязательно. Ее функциональность можно реализовать и внутри самого скрипта, чтобы не дергать каждый раз /usr/bin/zabbix_sender и оптимизировать процесс. Спасибо за важное дополнение mcleod095!

Но откуда скрипту знать, какое будет *ИМЯУЗЛА* (т.е. к какому узлу крепить сообщение), ведь известен только IP-адрес, с которого пришло сообщение?
Для этого мы будем использовать Zabbix API, именно через него мы и сможем найти *ИМЯУЗЛА* по IP-адресу.

Копируем скрипт на сервер по пути /usr/local/bin/zabbix_syslog_lkp_host.pl, также создаем конфигурационный файл
/usr/local/etc/zabbix_syslog.cfg с параметрами подключения к Заббиксу через API. Конфиг будет выглядеть примерно вот так:

Скрипт использует несколько модулей Perl из CPAN, чтобы установить их выполните команды:

Также настраиваем права на эти наши новые файлы:

Все готово для отправки сообщений в Заббикс, осталось только перезагрузить rsyslog:

С этого момента мы уже можем увидеть сообщения в заббиксе отдельно для каждого узла сети, открывая Последние данные -> нужный узел сети -> Syslog

Триггеры

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

У каждого оборудования и у каждого производителя оборудования сообщения свои, поэтому, как искать важное сообщение, не зная, как оно выглядит? А вот следующим образом:
Все сообщения syslog классифицируются при помощи атрибута severity, который согласно RFC5424 может принимать следующие значения:

0 Emergency: system is unusable 1 Alert: action must be taken immediately 2 Critical: critical conditions 3 Error: error conditions 4 Warning: warning conditions 5 Notice: normal but significant condition 6 Informational: informational messages 7 Debug: debug-level messages

есть у severity не только численное, но и текстовое сокращенное обозначение, присутствующее в окончательном сообщении, которое передается в Zabbix через zabbix_sender.
Таким образом, мы можем искать те сообщения, которым сама железка (то есть ее производитель) присвоила достаточно высокую важность, и оповещать о них. Для этого в наш шаблон Template_Syslog добавим триггеры, для оповещения о всех событиях с severity=warning и выше:

Последнее, что осталось сделать — это настроить оповещение (действие) об этих новых syslog-сообщениях. В условиях укажем, что имя триггера содержит [SYSLOG], и что отправлять сообщение нужно через электронную почту.

В итоге, каждый раз, когда в syslog упадет сообщение высокой важности, мы будем получать сообщение вида:

И кстати, наш шаблон с триггерами по критичности аварий уже готов:

2. Хочется все таки более гибкого скрипта. Что бы при новой инсталляции не лезть в нутрь и править параметры. в своих скриптах использовал такую конструкцию

Конечно это при условии что установлен zabbix_agent и настроен, конечно здесь только имя хоста определяется, но думаю мысль понятна.

Спасибо большое за важное дополнение! Протестировал и добавил функцию zabbix_send для отсылки через socket в скрипт. В статью тоже внес эти поправки.
Теперь /usr/bin/zabbix_sender не используется.

От конфига, к сожалению, труднее отказаться, так как там прописаны логин/пароль для API, которых нет в конфиге zabbix_agent…

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

То есть скрипт работает, не работает лишь через syslog-ng.

# sestatus
The program ‘sestatus’ is currently not installed. You can install it by typing:
apt-get install policycoreutils
root@zabbix:

# cat /etc/sysconfig/selinux
cat: /etc/sysconfig/selinux: No such file or directory

Хотел еще добавить: если если подменить в скрипте

То в заббиксе на узле 192.168.250.5 начинают появляться записи test [192.168.250.5]. Выходит, скрипт отрабатывает через syslog-ng, но не может получить строку лога как аргумент, либо не может его обработать?

Я к сожалению не специалист по Perl, очень трудно понять — почему так. Начитался всякого про буферизацию, пробовал методы отключения, но безуспешно.

Добавлю свои 5 копеек. Для проверки скрипта выполнял в CLI сервера что-то вроде

Первоначально была ошибка «Could not create socket: Connection refused». Добавил в /etc/hosts запись с hostname в строку 127.0.0.1 и ::1.

Спасибо, решение работает с zabbix 3.2.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.