System logs что это

Удобный мониторинг 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-сообщения. Важно в интерфейсах указать те 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 может принимать следующие значения:

есть у 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».

Недостатки 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 часто выносят в отдельную файловую систему на отдельном разделе.

Некоторые специальные файлы журналов

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

Для данной таблицы действуют следующие обозначения: 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.

Источник