Установка и настройка syslog сервера. Лучший бесплатный сервер Syslog Автоматическое крепление к карте

• Tutorial

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

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

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

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

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

/usr/local/bin/zabbix_syslog_lkp_host.pl

#!/usr/bin/perl use 5.010; use strict; use warnings; use JSON::RPC::Legacy::Client; use Data::Dumper; use Config::General; use CHI; use List::MoreUtils qw (any); use English "-no_match_vars"; use Readonly; use MIME::Base64 qw(encode_base64); use IO::Socket::INET; our $VERSION = 2.0; Readonly my $CACHE_TIMEOUT => 600; Readonly my $CACHE_DIR => "/tmp/zabbix_syslog_cache"; my $conf = Config::General->new("/usr/local/etc/zabbix_syslog.cfg"); my %Config = $conf->getall; #Authenticate yourself my $client = JSON::RPC::Legacy::Client->new(); my $url = $Config{"url"} || die "URL is missing in zabbix_syslog.cfg\n"; my $user = $Config{"user"} || die "API user is missing in zabbix_syslog.cfg\n"; my $password = $Config{"password"} || die "API user password is missing in zabbix_syslog.cfg\n"; my $server = $Config{"server"} || die "server hostname is missing in zabbix_syslog.cfg\n"; my $debug = $Config{"debug"}; my ($authID, $response, $json); my $id = 0; my $message = shift @ARGV || die "Syslog message required as an argument\n"; #Grab syslog message from rsyslog #get ip from message my $ip; #IP regex patter part my $ipv4_octet = q/(?:25|2|??)/; if ($message =~ / \[ ((?:$ipv4_octet[.]){3}${ipv4_octet}) \]/msx) { $ip = $1; } else { die "No IP in square brackets found in "$message", cannot continue\n"; } my $cache = CHI->new(driver => "File", root_dir => $CACHE_DIR,); my $hostname = $cache->get($ip); if (!defined $hostname) { $authID = login(); my @hosts_found; my $hostid; foreach my $host (hostinterface_get()) { $hostid = $host->{"hostid"}; if (any { /$hostid/msx } @hosts_found) { next; } #check if $hostid already is in array then skip(next) else { push @hosts_found, $hostid; } ###########now get hostname if (get_zbx_trapper_syslogid_by_hostid($hostid)) { my $result = host_get($hostid); #return hostname if possible if ($result->{"host"}) { if ($result->{"proxy_hostid"} == 0) #check if host monitored directly or via proxy { #lease $server as is } else { #assume that rsyslogd and zabbix_proxy are on the same server $server = "localhost"; } $hostname = $result->{"host"}; } } } logout(); $cache->set($ip, $hostname, $CACHE_TIMEOUT); } zabbix_send($server, $hostname, "syslog", $message); #______SUBS sub login { $json = { jsonrpc => "2.0", method => "user.login", params => { user => $user, password => $password }, id => $id++, }; $response = $client->call($url, $json); # Check if response was successful die "Authentication failed\n" unless $response->content->{"result"}; if ($debug > 0) { print Dumper $response->content->{"result"}; } return $response->content->{"result"}; } sub logout { $json = { jsonrpc => "2.0", method => "user.logout", params => {}, id => $id++, auth => $authID, }; $response = $client->call($url, $json); # Check if response was successful warn "Logout failed\n" unless $response->content->{"result"}; return; } sub hostinterface_get { $json = { jsonrpc => "2.0", method => "hostinterface.get", params => { output => [ "ip", "hostid" ], filter => { ip => $ip, }, # limit => 1, }, id => $id++, auth => $authID, }; $response = $client->call($url, $json); if ($debug > 0) { print Dumper $response; } # Check if response was successful (not empty array in result) if (!@{ $response->content->{"result"} }) { logout(); die "hostinterface.get failed\n"; } return @{ $response->content->{"result"} } } sub get_zbx_trapper_syslogid_by_hostid { my $hostids = shift; $json = { jsonrpc => "2.0", method => "item.get", params => { output => ["itemid"], hostids => $hostids, search => { "key_" => "syslog", type => 2, #type => 2 is zabbix_trapper status => 0, }, limit => 1, }, id => $id++, auth => $authID, }; $response = $client->call($url, $json); if ($debug > 0) { print Dumper $response; } # Check if response was successful if (!@{ $response->content->{"result"} }) { logout(); die "item.get failed\n"; } #return itemid of syslog key (trapper type) return ${ $response->content->{"result"} }->{itemid}; } sub host_get { my $hostids = shift; $json = { jsonrpc => "2.0", method => "host.get", params => { hostids => [$hostids], output => [ "host", "proxy_hostid", "status" ], filter => { status => 0, }, # only use hosts enabled limit => 1, }, id => $id++, auth => $authID, }; $response = $client->call($url, $json); if ($debug > 0) { print Dumper $response; } # Check if response was successful if (!$response->content->{"result"}) { logout(); die "host.get failed\n"; } return ${ $response->content->{"result"} }; #return result } sub zabbix_send { my $zabbixserver = shift; my $hostname = shift; my $item = shift; my $data = shift; Readonly my $SOCK_TIMEOUT => 10; Readonly my $SOCK_RECV_LENGTH => 1024; my $result; my $request = sprintf "\n%s\n%s\n%s\n\n", encode_base64($hostname), encode_base64($item), encode_base64($data); my $sock = IO::Socket::INET->new(PeerAddr => $zabbixserver, PeerPort => "10051", Proto => "tcp", Timeout => $SOCK_TIMEOUT); die "Could not create socket: $ERRNO\n" unless $sock; $sock->send($request); my @handles = IO::Select->new($sock)->can_read($SOCK_TIMEOUT); if ($debug > 0) { print "item - $item, data - $data\n"; } if (scalar(@handles) > 0) { $sock->recv($result, $SOCK_RECV_LENGTH); if ($debug > 0) { print "answer from zabbix server $zabbixserver: $result\n"; } } else { if ($debug > 0) { print "no answer from zabbix server\n"; } } $sock->close(); return; }

Копируем скрипт на сервер по пути /usr/local/bin/zabbix_syslog_lkp_host.pl, также создаем конфигурационный файл
/usr/local/etc/zabbix_syslog.cfg с параметрами подключения к Заббиксу через API. Конфиг будет выглядеть примерно вот так:
url = http://zabbix.local/zabbix/api_jsonrpc.php user = api_user password = password server = zabbix.local debug=0
Скрипт использует несколько модулей Perl из CPAN, чтобы установить их выполните команды:
PERL_MM_USE_DEFAULT=1 perl -MCPAN -e "install Readonly" PERL_MM_USE_DEFAULT=1 perl -MCPAN -e "install CHI" PERL_MM_USE_DEFAULT=1 perl -MCPAN -e "install JSON::RPC::Legacy::Client" PERL_MM_USE_DEFAULT=1 perl -MCPAN -e "install Config::General"
Также настраиваем права на эти наши новые файлы:
chmod +x /usr/local/bin/zabbix_syslog_lkp_host.pl chown zabbix:zabbix /usr/local/etc/zabbix_syslog.cfg chmod 700 /usr/local/etc/zabbix_syslog.cfg
Все готово для отправки сообщений в Заббикс, осталось только перезагрузить rsyslog:
service rsyslog restart

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

Триггеры

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

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

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


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

Template_Syslog

2.0 2015-03-13T14:27:56Z Templates ({Template_Syslog:syslog.str(.alert)}=1)and({Template_Syslog:syslog.nodata(900)}=0) Alert message received 0 4 0 ({Template_Syslog:syslog.str(.crit)}=1)and({Template_Syslog:syslog.nodata(900)}=0) Critical message received 0 3 0 ({Template_Syslog:syslog.str(.emerg)}=1)and({Template_Syslog:syslog.nodata(900)}=0) Emergency message received 0 5 0 ({Template_Syslog:syslog.str(.err)}=1)and({Template_Syslog:syslog.nodata(900)}=0) Error received 0 2 0 ({Template_Syslog:syslog.str(.warning)}=1)and({Template_Syslog:syslog.nodata(900)}=0) Warning received 0 1 0

Конечно, не обязательно отлавливать все сообщения warning, error, critical и так далее. Это просто обобщенный вариант, который помогает не упустить что-то нештатное. Используя функции триггеров iregxp(), regxp(), str() , всегда можно фиксировать в логах более специфические события.

Автоматическое крепление к карте

Можно потратить день-другой и выстрадать добавление URL-ссылок для каждого узла сети на его syslog элемент данных руками:

Но скорее руки отсохнут кликать по мышке, либо умом тронешься. Лучше вновь обратимся к Zabbix API за помощью в автоматизации сего рутинного дела:
Для этого накидаем скрипт, который будет
1) Брать все элементы карты сети
2) Для всех элементов типа узел сети проверять, нет ли у него элемента данных с key=syslog
3) Если есть, добавлять к списку существующих URL ссылку на просмотр этого элемента данных (если URL на Syslog уже есть, то ничего не делать)
Когда скрипт будет готов, мы развернем его только на Zabbix-server"е:

/usr/local/bin/zabbix_syslog_create_urls.pl

#!/usr/bin/perl #fixed URL for ZBX 2.4 use 5.010; use strict; use warnings; use JSON::RPC::Legacy::Client; use Data::Dumper; use Config::General; our $VERSION = 1.1; my $conf = Config::General->new("/usr/local/etc/zabbix_syslog.cfg"); my %Config = $conf->getall; #Authenticate yourself my $client = JSON::RPC::Legacy::Client->new(); my $url = $Config{"url"} || die "URL is missing in zabbix_syslog.cfg\n"; my $user = $Config{"user"} || die "API user is missing in zabbix_syslog.cfg\n"; my $password = $Config{"password"} || die "API user password is missing in zabbix_syslog.cfg\n"; my $server = $Config{"server"} || die "server hostname is missing in zabbix_syslog.cfg\n"; my $debug = $Config{"debug"}; my ($authID, $response, $json); my $id = 0; $authID = login(); my $syslog_url_base = "history.php?action=showvalues"; my @selements; foreach my $map (@{ map_get_extended() }) { my $mapid=$map->{sysmapid}; #next unless ($mapid == 120 or $mapid == 116); #debug #put all mapelements into array @selements (so you can update map later!) @selements = @{ $map->{selements} }; foreach my $selement (@selements) { my $syslog_button_exists = 0; if ($debug > 0) { print "Object ID: " . $selement->{selementid} . " Type: " . $selement->{elementtype} . " Elementid " . $selement->{elementid} . " \n"; } # elementtype=0 hosts if ($selement->{elementtype} == 0) { my $hostid = $selement->{elementid}; my $itemid = get_syslogid_by_hostid($hostid); if ($itemid) { #and add urls: my $syslog_exists = 0; foreach my $syslog_url (@{ $selement->{urls} }) { $syslog_exists = 0; if ($syslog_url->{name} =~ "Syslog") { $syslog_exists = 1; $syslog_url->{"name"} = "Syslog"; $syslog_url->{"url"} = $syslog_url_base . "&itemids[" . $itemid . "]=" . $itemid; } } if ($syslog_exists == 0) { #syslog item doesn"t exist... add it push @{ $selement->{urls} }, { "name" => "Syslog", "url" => $syslog_url_base . "&itemids[" . $itemid . "]=" . $itemid }; } } } } map_update($mapid,\@selements); } logout(); #______SUBS sub get_syslogid_by_hostid { my $hostids = shift; $json = { jsonrpc => "2.0", method => "item.get", params => { output => ["itemid"], hostids => $hostids, search => { "key_" => "syslog" }, limit => 1, }, id => $id++, auth => $authID, }; $response = $client->call($url, $json); # Check if response was successful if (!$response->content->{"result"}) { logout(); die "item.get failed\n"; } #return itemid of syslog key (trapper type) return ${ $response->content->{"result"} }->{itemid}; } sub login { $json = { jsonrpc => "2.0", method => "user.login", params => { user => $user, password => $password }, id => $id++, }; $response = $client->call($url, $json); # Check if response was successful die "Authentication failed\n" unless $response->content->{"result"}; if ($debug > 0) { print Dumper $response->content->{"result"}; } return $response->content->{"result"}; } sub map_get { #retrieve all maps $json = { jsonrpc => "2.0", method => "map.get", params => { output => ["sysmapid"] }, id => $id++, auth => "$authID", }; $response = $client->call($url, $json); # Check if response was successful if (!$response->content->{"result"}) { logout(); die "map.get failed\n"; } if ($debug > 1) { print Dumper $response->content->{result}; } return $response->content->{result}; } sub logout { $json = { jsonrpc => "2.0", method => "user.logout", params => {}, id => $id++, auth => $authID, }; $response = $client->call($url, $json); # Check if response was successful warn "Logout failed\n" unless $response->content->{"result"}; return; } sub map_get_extended { $json = { jsonrpc => "2.0", method => "map.get", params => { selectSelements => "extend", #sysmapids => $map, }, id => $id++, auth => $authID, }; $response = $client->call($url, $json); # Check if response was successful if (!$response->content->{"result"}) { logout(); die "map.get failed\n"; } if ($debug > 1) { print Dumper $response->content->{"result"}; } return $response->content->{"result"}; } sub map_update { my $mapid = shift; my $selements_ref = shift; $json = { jsonrpc => "2.0", method => "map.update", params => { selements => [@{$selements_ref}], sysmapid => $mapid, }, id => $id++, auth => $authID, }; if ($debug > 0) { print "About to map.update this\n:"; print Dumper $json; } $response = $client->call($url, $json); if ($debug > 0) { print Dumper $response; } # Check if response was successful if (!$response->content->{"result"}) { logout(); die "map.update failed\n"; } return; } Добавить метки

Думаю, что в жизни каждого сисадмина бывают моменты, когда в его любимой сети начинают происходить необъяснимые вещи. Особенно неприятно, если это происходит с некоторой периодичностью и установить причину каждый раз не удается. Конечно, можно сослаться на магнитные бури, погоду на Марсе и т.д. (нужное подчеркнуть), но все мы с вами прекрасно понимаем, что космос здесь не причем.

Мы не будем себя утруждать перебором всех возможных вариантов, лучше подумаем о том, как можно предупредить, отследить и быстро установить причину возникновения того или иного сбоя. Все сетевые железки (и не только), которые хотя бы частично наделены мозгами, в процессе своей работы генерируют логи происходящих событий. Чаще всего эти логи записываются локально в память железки и уважвющий себя сисадмин их никогда не читает. А зря 🙂 Ибо там и кроется вся истина происходящих событий.

Конечно, если твоя сеть состоит из одного коммутатора или роутера, то отслеживать логи будет не трудно и городить огород здесь не стоит. Другое дело, когда сеть состоит из большого количества разнородных устройств. Что предложите? Тратить по полдня на анализ логов в нашем случае не вариант.

Как ты уже догодался, нам нужно каким-то образом отслеживать все происходящие события централизованно. Возникает вопрос как и чем это делать? Мониторинг сети? Одно такое решение под названием PRTG Network Monitoring мы недавно рассматривали. Однако, не все и не всегда можно отследить с помощью PRTG.
Умные дяди давным давно придумали специальный стандарт для передачи логов - Syslog. Кто особо заинтересовался подробостями этого протокола - велкам в википедию , а остальным мы в краце расскажем что к чему и как это настроить в любимой сети.
Весь принцип работы сводится к тому, что программа syslog, установленная на какой-нибудь сервер, принимает входящие сообщения от сетевых железок. Принятые сообщения записываются в один файл или БД, чтобы ты всегда смог посмотреть какие события и на каком оборудовании происходили в заданый промежуток времени.

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

Хороший вариант - установить linux, там syslog в базовом варианте уже встроен изначально, останется только подшаманить с настройкой хранения событий в БД и веб-мордой для удобного просмотра. Но что делать, если нет времени плясать с бубном или нет достаточных знаний в *nix системах? Оказывается, даже из такой ситуации есть выход! Называется он SyslogAppliance . На сайте разработчиков можно скачать уже готовую к применению виртуальную машину vmware с настроенным syslog сервером.Я обнаружил только два ньюанса при развертывании виртуальной машины SyslogAppliance. А именно: виртуалка настроена на получение автоматического IP по DHCP, часовой пояс выставлен хрен знает какой. Если у вас есть DHCP-сервер, то впринципе можно привязать там MAC-адрес syslog сервера и больше не забивать голову всякой ерундой. Но имхо для сервера это не кашерно. Лучше выставить настройки IP-адресации вручную. Делается это следующим образом. Логинимся в syslog сервер по консоли, затем с помощью редактора vim открываем файл сетевых настроек. Команда будет выглядеть так:
vim /etc/network/interfaces

Здесь нам надо заменить строку:
iface eth0 inet auto
и все что под ней на:
iface eth0 inet static
address твой_IP_адрес
netmask маска_подсети
gateway шлюз_по_умолчанию

Для перехода в режим редактирования сначала нажимаем i, затем правим всё как указано выше, затем жмем Esc. Для выода с сохранением нажимаем Shift+z два раза.
Далее нужно вписать DNS. Для этого набираем
vim /etc/resolv.conf
указываем адрес нашего DNS-сервера. Сохраняемся, выходим. Перезагружаемся командой reboot . Если у syslog сервера есть доступ в интернет, то можно выполнить пару команд обновления системы. Сначала набираем apt-get update , затем apt-get upgrade .

Последнее что нужно сделать, это поменять часовой пояс и выставить правильную дату и время. Первое делается командой
dpkg-reconfigure tzdata
а второе командой
date -set=»мм/дд/гггг чч:мм:сс»
После этих манипуляций можно перезагрузить syslog сервер и попробовать зайти на web-интерфейс по адресу http://ip-адрес-сервера/logs
Нас попросят ввести логин/пароль, затем будет показана текущая ситуация по собранным событиям:

Все события разбиваются по источнику, типу сообщения (notice, warning, error, alarm и т.п.), описание, в котором указано что именно произошло. Мы можем отфильтровать таблицу по интересующим нас критериям, для этого просто кликните мышью по нужной надписи. Если надо видеть какие сообщения валятся на syslog сервер в режиме реального времени, то в правой части экрана над шапкой таблицы есть ниспадающий список с вариантами автообновления страницы с разными интервалами времени. Ко всему прочему можно поизучать статистические данные, которые здесь представлены в виде диаграмм. Есть несколько типов графиков.

Для решения Вашей проблемы специалисты технической поддержки AXIA могут запросить детальный журнал активности системы. Для этого необходимо использовать Syslog сервер и настроить соответствующим образом оборудование. Ниже будет описано как это сделать. Изменяйте настройки только, если это необходимо для решения проблемы, в противном случае Syslog настройки должны быть оставлены в значениях по умолчанию.

Специалистами Telos был создан простой, не требующий установки Syslog Server. Программа является приложением.NET для Windows 7, но возможен запуск на WinXP при условии наличия установленного клиента.NET v3.5 или более поздней версии. Клиент.NET может быть загружен и установлен бесплатно с веб-сайта Microsoft

После этого необходимо выбрать уровень событий, подлежащих регистрации в отчетах из списка Syslog severity level filter

• Emergency : регистрирует события, связанные с полной неработоспособностью системы.
• Alert : регистрирует события, требующие немедленного внимания для сохранения работоспособности.
• Critical : регистрирует события о критических системных ошибках.
• Warning : регистрирует события, которые могут привести к нестабильности системы.
• Notice : система работает нормально, но в отчетах регистрируются сообщения о необычных событиях.
• Informational : регистрируются все информационные сообщения. Эта информация включает все рутинные события.
• Debug : регистрируются вся системная деятельность

Аналогичным образом настраивается и другое оборудование AXIA. Для консолей в пункте меню Log Setup , для Engine в меню Diagnostics .

После совершения изменений в настройках щелкните кнопку Apply для их сохранения:

Теперь осталось только нажать кнопку START для начала работы сервера:

Все готово для регистрации системной активности.

События, регистрирующие процесс перезагрузки AXIA Analog xNode на уровне Debug выглядят так:

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

• по уровню - выбрать необходимые с помощью списка слева
• по контексту - ввести текст для поиска и нажать кнопку Filter

Для сохранения сообщений в файл необходимо настроить его параметры в меню Options на вкладке LOG :

По указанному пути будет создан файл с названием вида SysLog_ГГГГ-MM-DD.log (ГГГГ-MM-DD - текущая дата), в котором будет сохраняться полученная в течении дня информация:

17:45:28.877: Nov 30 01:30:00 Node-100-2 login: root login on `ttyp0" 17:45:36.525: Nov 30 01:30:08 Node-100-2 syslogd: System log daemon exiting. 17:45:56.891: Nov 30 00:00:09 Node-100-2 lwrd: eth0 flags 0x1003 (link down) 17:45:56.895: Nov 30 00:00:09 Node-100-2 lwrd: eth1 flags 0x1003 (link down) 17:45:56.899: Nov 30 00:00:10 Node-100-2 lwrd: eth0 flags 0x11043 (link up) 17:45:57.325: Nov 30 00:00:11 Node-100-2 lwrd: Registered: SRC 1@Node-100-2._rtsp._tcp.local. 17:45:57.328: Nov 30 00:00:11 Node-100-2 lwrd: Registered: sip:[email protected] SRC 1@Node-100-2._sipuri._udp.local. 17:45:58.437: Nov 30 00:00:12 Node-100-2 lwrd: connected @13 127.0.0.1:57611 17:45:58.440: Nov 30 00:00:12 Node-100-2 gpior: gpior-lwrd connected 17:45:58.444: Nov 30 00:00:12 Node-100-2 gpior: iface change 172.22.15.6 17:45:58.447: Nov 30 00:00:12 Node-100-2 gpior: gpiomc ANY:2060 joined 239.192.255.4 on 172.22.15.6 17:46:01.328: Nov 30 00:00:15 Node-100-2 lwrd: config save 88ms 17:46:02.556: Nov 30 00:00:16 Node-100-2 lwrd: connected @16 127.0.0.1:57612 17:46:03.627: Nov 30 00:00:17 Node-100-2 xsyncd: lwsync up on 172.22.15.6 17:46:04.656: Nov 30 00:00:18 Node-100-2 xsyncd: lwsync master time out 17:46:05.656: Nov 30 00:00:19 Node-100-2 xsyncd: master: AC030F06 .6 p3 00:50:C2:79:16:B3 we are

Кроме вышеописанного syslog server существует множество других аналогичных программ для регистрации сообщений о системной активности. Они могут обладать разными возможностями, интерфейсами и стоимостью.
Как вариант программы с расширенными настройками можно рассмотреть бесплатное ПО (архив с дистрибутивом v1.6.3 2015-11-20)

Эта программа уже требует инсталляции, но позволяет настраивать параметры log файла, просматривать log файлы с диска, формировать извещения и выполнять действия в зависимости от содержания лога, работать по протоколам UDP и TCP, поддерживает кодировку UTF8.

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

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

Термин syslog используется для описания стандарта. Он также используется для описания протокола, разработанного для этого стандарта. Протокол syslog был разработан для систем UNIX ещё в 80-е гг. прошлого века, но был впервые документирован сообществом IETF под названием RFC 3164 только в 2001 г. Syslog использует порт UDP 514 для отправки сообщений с уведомлением о событиях по сетям IP на средства сбора сообщений о событиях, как показано на рисунке.

Syslog поддерживают многие сетевые устройства, включая маршрутизаторы, коммутаторы, серверы приложений, межсетевые экраны и др. Протокол syslog позволяет сетевым устройствам отправлять системные сообщения по сети на серверы syslog. Для этой цели можно развернуть специальную выделенную (out-of-band, OOB) сеть.

Существуют различные пакеты ПО сервера Syslog для Windows и UNIX. Многие из них бесплатны.

Служба журналирования syslog предоставляет три основные возможности:

• сбор информации в журнал для мониторинга и отладки;

• выбор типа информации, сбор которой будет осуществляться;

• определение получателей собранных сообщений syslog.

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

Кроме того, сообщения syslog могут отправляться во внутренний буфер. Сообщения, отправленные во внутренний буфер, можно просматривать только через интерфейс командной строки устройства.

Наконец, сетевой администратор может указать, какие типы системных сообщений будут отправляться в различные места назначения. Например, можно настроить устройство, чтобы все системные сообщения отправлялись на внешний сервер syslog. Однако сообщения уровня debug будут пересылаться во внутренний буфер и будут доступны только администратору через интерфейс командной строки.

Как показано на рисунке, в число популярных назначений для сообщений syslog входят следующие:

• буфер ведения журналов (ОЗУ в маршрутизаторе или коммутаторе);
• линия консоли;
• линия терминала;
• сервер syslog.

Можно удалённо наблюдать за системными сообщениями путём просмотра журналов на сервере Syslog или путём доступа к устройству по протоколам Telnet, SSH или через порт консоли.

Устройства Cisco создают сообщения syslog при определённых сетевых событиях. Во всех сообщениях syslog указывается уровень важности (severity level) и объект (facility).

Чем меньше назначаемое число, тем более важным является оповещение syslog. В настройках уровня важности сообщений можно установить, куда отправлять сообщения каждого типа (например на консоль или в другие места назначения). Полный перечень уровней syslog представлен на рисунке 1.

Каждый уровень syslog имеет собственный смысл:

• Уровень предупреждения (warning) - уровень критического состояния (emergency) - это сообщения о сбоях программного обеспечения или оборудования; эти типы сообщений говорят о том, что затронута работа устройства. Назначаемый уровень syslog зависит от серьёзности проблемы.

• Уровень отладки (debugging) - сообщения этого уровня содержат выходные данные, полученные в результате выполнения различных команд debug .

• Уровень уведомления (notification) - сообщения уровня уведомления носят исключительно справочный характер, работоспособность устройств не затрагивается. На уровне предупреждения отображаются сообщения об изменении состояния интерфейса на активное или неактивное или о перезапуске системы.

Помимо указания уровня важности в сообщениях syslog также содержатся сведения об объекте. Объекты syslog (syslog facilities) - это идентификаторы сервисов, которые определяют и классифицируют данные о состоянии системы для отчетов об ошибках и событиях. Доступные варианты объектов ведения журнала зависят от конкретного сетевого устройства. Например, коммутаторы Cisco серии 2960, в которых используется Cisco IOS версии 15.0(2), и маршрутизаторы Cisco 1941, в которых используется Cisco IOS версии 15.2(4), поддерживают 24 варианта объектов, которые группируются в 12 типов объектов.

Ниже приведены некоторые из общепринятых объектов сообщений syslog, которые регистрируются на маршрутизаторах Cisco IOS:

• Протокол OSPF

• Операционная система SYS

• Протокол IPSec

• IP интерфейса (IF)

По умолчанию формат сообщений syslog в ПО Cisco IOS выглядит следующим образом:

seq no: timestamp: %facility-severity-MNEMONIC: description

Пример выходных данных об изменении состояния канала EtherChannel коммутатора Cisco на активное будет выглядеть следующим образом:

00:00:46: %LINK-3-UPDOWN: Interface Port-channel1, changed state to up

В этом примере объектом является LINK, назначен уровень серьёзности 3, в качестве КРАТКОГО КОДА выступает UPDOWN.

Наиболее распространенными сообщениями являются сообщения об изменении состояния каналов на активное и неактивное, а также сообщения, создаваемые устройством при выходе из режима настройки. Если настроено журналирование в списках контроля доступа, устройство создаёт сообщения syslog, если пакеты соответствуют заданным условиям.

Сообщения журнала могут сопровождаться метками времени. Также может назначаться адрес источника сообщений syslog. Это повышает эффективность отладки и управления в режиме реального времени.

Если введена команда режима глобальной конфигурации service timestamps log uptime , для регистрируемых событий отображается время, прошедшее с момента последней загрузки коммутатора. В более полезной версии этой команды применяется ключевое слово datetime вместо ключевого слова uptime ; в этом случае для каждого зарегистрированного события будут отображаться дата и время.

При использовании ключевого словаdatetime необходимо настроить часы сетевого устройства. Часы можно настроить одним из двух способов:

• Вручную с помощью командыclock set

• Автоматически с помощью протокола NTP

Протокол NTP позволяет синхронизировать настройки времени сетевых устройств с сервером NTP.

Чтобы разрешить синхронизацию программных часов с сервером времени NTP, используйте команду ntp server ip-address в режиме глобальной конфигурации. Пример настройки показан на рисунке. Маршрутизатор R1 настроен как клиент NTP, маршрутизатор R2 выступает в качестве доверенного сервера NTP. Сетевое устройство можно настроить в качестве сервера NTP (что позволяет другим устройствам синхронизироваться с его временем) или в качестве клиента NTP.

В оставшейся части главы предполагается, что часы настроены и что на всех устройствах настроена команда service timestamps log datetime .

Настройка Syslog

Для просмотра сообщений syslog на рабочей станции в сети должен быть установлен сервер syslog. Существуют различные бесплатные и условно-бесплатные версии syslog, а также платные корпоративные версии. На рисунке 1 ознакомительная версия службы Kiwi Syslog отображается на компьютере с ОС Windows 7.

Сервер syslog предоставляет довольно удобный в использовании интерфейс для просмотра выходных данных syslog. Сервер анализирует выходные данные и помещает сообщения в предопределённые столбцы для упрощения их интерпретации. Если для сетевого устройства, которое является источником сообщений syslog, настроены временные метки, в качестве даты и времени каждого сообщения будут отображаться выходные данные сервера Syslog, как показано на рисунке 2.

Сетевые администраторы могут легко ориентироваться в больших объемах данных, собранных на сервере Syslog. Одним из преимуществ просмотра сообщений системного журнала на сервере Syslog является возможность детализированного поиска данных. Кроме того, сетевой администратор может быстро удалить менее важные сообщения Syslog из базы данных.

По умолчанию маршрутизаторы и коммутаторы Cisco отправляют на консоль сообщения журнала для всех уровней важности. На некоторых версиях IOS по умолчанию устройство также сохраняет сообщения журнала в буфер. Для включения этих двух параметров используйте командыlogging console и logging buffered в режиме глобальной настройки соответственно.

Команда show logging отображает параметры по умолчанию службы ведения журнала, настроенные на маршрутизаторе Cisco, как показано на рисунке. Первые строки списка выходных данных содержат информацию о процессе ведения журналов. В конце списка выходных данных приведены сообщения журнала.

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

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

Настройка маршрутизатора для отправки системных сообщений на сервер syslog, где они могут храниться, фильтроваться и анализироваться, выполняется в три шага:

Шаг 1. Настройте имя узла назначения или IP-адрес сервера Syslog в режиме глобальной конфигурации:

R1(config)# logging 192.168.1.3

Шаг 2. Укажите, какие сообщения следует отправлять на сервер syslog с помощью команды logging trap level в режиме глобальной конфигурации. Например, чтобы отправлять только сообщения уровня 4 и ниже (0-4), используйте одну из следующих двух эквивалентных команд:

R1(config)# logging trap 4

R1(config)# logging trap warning

Шаг 3. При необходимости настройте интерфейс источника с помощью команды logging source-interface interface-type interface number в режиме глобальной конфигурации. Таким образом, можно настроить, чтобы пакеты syslog содержали адрес IPv4 или IPv6 конкретного интерфейса независимо от того, какой интерфейс используется для отправки пакета с маршрутизатора. Например, чтобы настроить в качестве интерфейса источника g0/0, используйте следующую команду:

R1(config)# logging source-interface g0/0

На рисунке 1 маршрутизатор R1 настроен для отправки сообщений журнала уровня 4 и ниже на сервер syslog по адресу 192.168.1.3. В качестве интерфейса источника настроен интерфейс G0/0. Интерфейс loopback создан, затем переведён в неактивное состояние, затем снова в активное. Эти действия отражены в выводе консоли.

Сервер syslog Tftpd32, изображённый на рисунке 2, настроен на компьютере с ОС Windows 7 с IP-адресом 192.168.1.3. Как можно видеть, на сервере Syslog отображаются только сообщения с уровнем важности 4 или меньше (более значимые). Сообщения с уровнем важности 5 или выше (менее значимые) отображаются в выходных данных консоли маршрутизатора, но не появляются в выходных данных сервера syslog, поскольку команда logging trap отбирает сообщения syslog, отправляемые на сервер syslog, по критерию важности.

Для просмотра любых зарегистрированных сообщений используйте команду show logging . Для буфера ведения журналов высокой ёмкости полезно использовать функцию конвейера (| ) с командой show logging . Конвейер позволяет администратору более конкретно определить сообщения, которые следует отображать.

Например, команда show logging | include changed state to up , показанная на рисунке 1, обеспечивает отображение только уведомлений об интерфейсе, сообщающих об изменении состояния интерфейса на «активен».

Команда show logging | begin June 12 22:35 , также показанная на рисунке 1, отображает содержимое буфера ведения журналов, начиная с 12-го июня.

Используйте средство проверки синтаксиса на рисунке 2 для настройки и проверки syslog на маршрутизаторе R1.