Удобный мониторинг 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 классифицируются при помощи атрибута 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 упадет сообщение высокой важности, мы будем получать сообщение вида:
И кстати, наш шаблон с триггерами по критичности аварий уже готов:
Конечно, не обязательно отлавливать все сообщения warning, error, critical и так далее. Это просто обобщенный вариант, который помогает не упустить что-то нештатное. Используя функции триггеров iregxp(), regxp(), str(), всегда можно фиксировать в логах более специфические события.
Автоматическое крепление к карте
Затронем еще один важный момент, который упрощает работу с syslog-сообщениями — контекстный переход с карты сети.
Можно потратить день-другой и выстрадать добавление URL-ссылок для каждого узла сети на его syslog элемент данных руками:
Но скорее руки отсохнут кликать по мышке, либо умом тронешься. Лучше вновь обратимся к Zabbix API за помощью в автоматизации сего рутинного дела:
Для этого накидаем скрипт, который будет
1) Брать все элементы карты сети
2) Для всех элементов типа узел сети проверять, нет ли у него элемента данных с key=syslog
3) Если есть, добавлять к списку существующих URL ссылку на просмотр этого элемента данных (если URL на Syslog уже есть, то ничего не делать)
Когда скрипт будет готов, мы развернем его только на Zabbix-server’е:
И сразу добавим скрипт в cron (лучше всего под пользователем zabbix) на машине с Zabbix Server, одного раза в сутки может оказаться вполне достаточно.
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Большинство сетевых устройств, таких как маршрутизаторы и коммутаторы, могут отправлять сообщения системного журнала. Кроме того, серверы *nix также могут генерировать данные системного журнала, как и большинство брандмауэров, некоторые принтеры и даже веб-серверы, такие как Apache. Серверы на базе Windows изначально не поддерживают Syslog, но большое количество сторонних инструментов позволяет легко собирать данные журнала событий Windows или IIS и пересылать их на сервер Syslog.
Syslog серверы
Syslog сообщения
Сообщения системного журнала обычно содержат информацию, помогающую определить основную информацию о том, где, когда и почему был отправлен лог: IP-адрес, отметка времени и фактическое сообщение.
Системный журнал использует концепцию, называемое “facility”, чтобы идентифицировать источник сообщения на любом компьютере. Например, facility “0” будет сообщением ядра, а facility «11» будет сообщением FTP. Это восходит своими корнями к syslog’а UNIX. В большинстве сетевых устройств Cisco используются коды объектов «Local6» или «Local7».
| 0 | Emergency | Система не работоспособна |
|---|---|---|
| 1 | Alert | Система требует немедленного вмешательства |
| 2 | Critical | Состояние системы критическое |
| 3 | Error | Сообщения об ошибках |
| 4 | Warning | Предупреждения о возможных проблемах |
| 5 | Notice | Сообщения о нормальных, но важных событиях |
| 6 | Informational | Информационные сообщения |
| 7 | Debug | Отладочные сообщения |
Недостатки syslog
У протокола syslog есть несколько недостатков.
Наконец, есть некоторые проблемы безопасности. В сообщениях syslog’а нет аутентификации, поэтому один компьютер может выдать себя за другой компьютер и отправить ложные события журнала. Он также подвержен повторным атакам.
Несмотря на это, многие администраторы считают, что syslog является ценным инструментом, и что его недостатки относительно незначительны.
Онлайн курс по Linux
Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps
Система Syslog и журналы логов в Linux
В процессе своей работы система отслеживает и сохраняет в специальные файлы некоторые события, которые она считает важными или просто нужными для использования в целях исправления и отладки ошибок, сбойных конфигураций и т. д. Файлы, в которых хранятся эти события называются файлами журналов или файлами регистрации. Нередко файлы регистрации занимают слишком много дискового пространства, что может свидетельствовать как о неисправности системы, ошибках конфигураций, так и о просто неправильной настройке демонов регистрации событий, которые отслеживают и собирают всё подряд. Таким образом работа с системой регистрации событий — важная составляющая в работе любого системного администратора, от которой всецело зависит качество обслуживания систем и как следствие — их надёжность и долговечность.
Как устроена система регистрации событий?
Опытные системные администраторы знают, что просматривать и анализировать журналы (файлы) регистраций необходимо регулярно и с особой тщательностью. Информация, содержащаяся в журналах очень часто помогает быстро решить возникающие неполадки или выявить скрытые проблемы в конфигурации системы. Для отслеживания событий системой, проверки журналов, учёта, хранения, архивирования и удаления информации из этих журналов должен быть разработан и утверждён специальный регламент для организации, эксплуатирующей и/или обслуживающей системы, серверы и сети.
Основным инструментом регистрации событий в UNIX и Linu до сих пор остаётся демон syslogd системы Syslog. Но следует иметь в виду также и то, что на протяжении длительного времени из-за многообразия всевозможных ответвлений UNIX и версий Linux множество программных пакетов, служебных скриптов, сетевых демонов используют свои собственные журналы, порой отличающимся экзотическим форматом.
В общем случае системой Syslog (и другими специализированными программами) производится перехват отслеживаемого события и регистрация его в файле регистрации. Само регистрируемое событие представляет собой строку текста, содержащую данные о дате/времени, типе, степени важности события. Также в этот набор могут быть, в зависимости от ситуации, включены и другие данные. Сама строка регистрируемого события для выделения указанных компонентов разбивается символами-разделителями: пробелы, табуляции, а также знаками пунктуации.
Журналы регистрации легко просматривать, поскольку они являются обычными текстовыми файлами. Для эффективной работы с журналами используются самые стандартные инструменты из базовой поставки любого дистрибутива — команды cat и grep. Если нужно «ворошить» очень большие и сложные по формату журналы, то можно (и даже нужно) вместо утилиты grep использовать другой, гораздо более производительный и гибкий в подобных задачах инструмент — утилиту awk. Язык обработки текста Perl также очень хорошо подходит для этого.
Типичная запись системного журнала системы Syslog обычно выглядит следующим образом:
В данном случае можно видеть, что в одном из журналов Syslog собраны события из нескольких источников: программы sbathd, pingem, pop-proxy. Также можно видеть, что события регистрируются для нескольких хостов, взаимодействующих с данной системой: backup, system, office и service.
log файлы и их расположение в Linux
Как уже отмечалось, в системах UNIX и Linux нет чётких соглашений о том, где и как должны храниться журналы регистрации. Они могут быть разбросаны хоть по всей файловой системе, поэтому для каждого администратора важно сразу разобраться, где и для каких пакетов и демонов находятся соответствующие файлы журналов. Но несмотря на отсутствие чётких формальных регламентов относительно мест хранения журналов, всё же существует традиционно сложившееся правило, что эти файлы должны находиться в каталогах /var/log, /var/log/syslog, а также в /var/adm.
Как правило, доступ для чтения файлов в указанных каталогах предоставляется только суперпользователю, однако нет ничего страшного, если для часто просматриваемых журналов, в которых также нет важной системной информации настроить более «демократический» режим доступа. Обычно к такому варианту также прибегают для удобства и экономии времени, когда нужно часто и регулярно изучать некоторые журналы, например для веб-сервера Apache, которые обычно находятся в /var/log/apache2 или /var/log/httpd.
Стоит также помнить и о том, что бывают случаи, когда (особенно на сбойных конфигурациях) общий объём файлов журналов резко увеличивается, при этом велик риск «уложить» систему. Для удобства контроля за свободным пространством на устройствах хранения, а также для надёжности каталог /var часто выносят в отдельную файловую систему на отдельном разделе.
Некоторые специальные файлы журналов
В следующей таблице приводятся сведения о некоторых журнальных файлах, информация из которых очень полезна для системного администрирования:
| Файл | Программа | Место | Частота | Системы | Назначение |
| acpid | acpid | Ф | 64к | RZ | События, связанные с системой питания |
| auth.log | sudo и прочие | S | М | U | Информация об авторизации |
| apache2/* | httpd или apache2 | Ф | Д | ZU | Журналы веб-сервера Apache |
| apt* | APT | Ф | М | U | Установщики пакетов |
| boot.log | Сценарии запуска системы | Ф | М | R | Логи сценариев запуска |
| boot.msg | Ядро | В | — | Z | Образ буфера сообщений ядра |
| cron, cron/log | cron | S | Н | RAH | Логи и сведения о работе демона cron |
| cups/* | CUPS | Ф | Н | ZRU | Сообщения, связанные с системой печати (CUPS) |
| daemon.log | Разное | S | Н | U | Сообщения средств демонов |
| debug | Разное | S | Д | U | Сообщения для отладки |
| dmesg | Ядро | В | — | RU | Образ буфера сообщений ядра |
| dpkg.log | dpkg | Ф | М | U | Установщики пакетов |
| faillog | login | Н | Н | RZU | Информация о неудачных попытках авторизации |
| apache2/* | Httpd или apache2 | Ф | Д | R | Журналы веб-сервера Apache для каталога /etc |
| kern.log | login | В | — | RZ | Все сообщения средств ядра |
| lastlog | login | В | — | RZ | Время последней регистрации в системе каждого пользователя (этот файл бинарный) |
| mail* | Программы электронной почты | S | Н | Все | Сообщения средств электронной почты |
| messages | Разное | S | Н | RZUS | Основной системный журнальный файл |
| rpmpkgs | cron.daily | В | Д | R | Список установленных RPM-пакетов |
| samba/* | smbd и прочие | Ф | Н | — | Сведения о работе сервера Samba |
| secure | sshd и прочие | S | М | R | Конфиденциальные авторизационные сообщения |
| sulog | su | Ф | — | SAH | Сведения об удачных и неудачных попыток использования команды su |
| syslog* | Разное | S | H | SUH | Основной системный журнальный файл |
| warn | wpar | S | H | Z | События уровня системных предупреждений/ошибок |
| wpars/* | wpar | Ф | — | А | Сведения о событиях загрузочных разделов |
| wtmp | login | В | M | Все | Сообщения о регистрации в системе (бинарный файл) |
| xen/* | Xen | Ф | 1m | RZU | Информация от монитора виртуальных машин Xen |
| Xorg.n.log | Xorg | Ф | Н | RS | Сообщения об ошибках сервера X Windows |
| yum.log | yum | Ф | М | R | Журнал управления пакетом |
Для данной таблицы действуют следующие обозначения: S — Syslog, В — встроенное имя, Ф — конфигурационный файл, Д — ежедневно, Н — еженедельно, М — ежемесячно, NN[km] — размер в килобайтах или мегабайтах, Z — SUSE, R — Red Hat и CentOS, S — Solaris, H — HP-UX, A — AIX. В столбце «Частота» указывается частота, с которой удаляется устаревшая информация, связанная со временем или с объёмом файла. В столбце «Программа» указывается программа, создающая файл.
Следует отметить также, что большая часть сообщений для представленных в таблице файлов направляется в систему Syslog. Уровень критичности и программа, создающая файл задаются в конфигурационном файле /etc/initlog.conf. — так работает система Syslog. Файл faillog является двоичным, и поэтому может быть прочтён утилитой failog.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.