• 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 может принимать следующие значения:

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 упадет сообщение высокой важности, мы будем получать сообщение вида:


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

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() , всегда можно фиксировать в логах более специфические события.

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

Затронем еще один важный момент, который упрощает работу с syslog-сообщениями - контекстный переход с карты сети.

Можно потратить день-другой и выстрадать добавление 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; } Добавить метки

Хранить логи устройство может в своей оперативной памяти либо на Fleash и понятно, что много тут не сохранишь, а оперативная память при перезагрузке ещё и затирается.
Особенно это касается аварийных случаев, когда на устройство заглянуть возможности нет или нет времени, и оно в панике ребутается с потерей всех логов.

Альтернативным хорошим способом логирования есть логирование на внешний сервер, который называется Syslog server .
Существует ПО Syslog server от разных производителей, мы же рассмотрим самого известного с версией: Kiwi Syslog Server 9.4.1 .

Установка Kiwi Syslog Server

В установке ничего особо сложного нет - просто запускаем Kiwi_Syslog_Server_9.4.1.Eval.setup.exe , всё делаем стандартно и со всем соглашаемся.
Единственное, нужно запомнить админскую учётку для Web Access.
Установка потребует перезагрузки. Также сразу после установки нужно поставить лицензию.

Проверка/Настройка

Статус сервиса можно проверить здесь:
Administrative tools > Services > Siwi Syslog server
Понятно, что у него должно быть состояние Started .

Статус сервера можно проверить запустив Kiwi Syslog Server Console .
Отсюда можно проверить следующее:

• File > Send test message
• Manage > Show syslogd service state

Настройка устройства cisco

Настройка отображения текущего времени
service timestamps log datetime localtime
!
! Включение логирования
logging on
!
!
! Отключения логов на консоль
logging console critical
logging monitor debugging
!
! Настройка логирования в буфер
logging buffered informational
logging buffered 16386
logging rate-limit 100 except 4
!
! Настройка сообщений на сервер syslog
logging 192.168.1.10
logging trap debugging

Для того чтобы посмотреть что упало в буфер:
router#show logging

Включение отображения monitor logging:
terminal monitor

В результате сообщения должны начать валиться в syslog server:

Web access

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

Тут работа интуитивно понятна, и комментировать пожалуй нечего

Kiwi Syslog Server и tftpd32.exe

После установки syslog server может перестать запускаться tftpd32.exe, из-за конфликта портов.
Это связано с тем, что tftpd32.exe по умолчанию также прослушивает и syslog: это можно выключить в его настройках(settings).

/ Last Updated: June 6, 2019

Syslog and by extension syslog servers are, to put it quite simply, nothing but programs and protocols which aggregate and transfer diagnostic and monitoring data. Their power comes from the wide range of data that can be collected and, furthermore, the ways in which this data can be analyzed and levied for the sake of network maintenance, system monitoring, and dozens of other diagnostic and troubleshooting purposes!

Generally the Syslog protocol is supported by a wide variety of devices and thus it"s easy for devices and applications to fire off log information to the Syslog server, which stores the information for further analysis.

Most notably, Syslog servers are often capable of triggering alerts or sending notifications which enables an admin in the field to receive time-critical information, or to simply gets a heads up of something that may need attention soon – thanks to a built-in severity metric, it"s easier to know when something can wait and when it can"t.

SNMP ties heavily into Syslog server functionality and can be used in tandem to poll all the wonderfully wide variety of information that admins are used to snatching up via SNMP but, when taken a step further via Syslogging server software, they can take that data and do a lot more with it – graphical interfaces which aggregate SNMP data, for example, can massively speed up the assessment of almost any number of critical systems or failure points.

Using these same metrics many Syslog servers can also have automated scripts or events that will trigger and can potentially streamline the process of recovering from, or preventing, downtime or outages.

Some Syslog servers require client-based software to manage but many also offer web-based solutions, which can ease management both remotely or from different systems on a network environment. Most servers are also quite good at data management and will handle some level of archival functionality for saving older logs or records that may not actively be needed at present.

Syslog does have a few drawbacks – it"s not particularly standardized, meaning that sloppy implementation can cause troubles for Syslog servers, and it also lacks any kind of authentication.

In a trusted network environment this isn"t really an issue, but especially nefarious malware or untrusted networks can sow seeds of trouble.

Here"s the Best FREE Syslog Server Software & Tools of 2019:

Below is a list of software that performs these functions and more, as well as the compatible operating systems and, quite importantly, whether it supports some form of alert (alarms, pop-ups, etc.) and/or notifications (email, txt, etc.)

1. Kiwi Syslog Server – FREE VERSION

Kiwi"s Syslog Server boasts ease of installation and setup on top of its other range of desirable features. Reports can be generated both in easy-to-read HTML or in plain text if necessary for parsing with other software.

Log archival and storage are automatic and rigorous with a focus on compatibility in cases where even regulatory needs must be carefully met – even those as stringent as HIPAA. Kiwi utilizes a web-based console for extremely ease of access and swift availability that requires no client installation or configuration.

Kiwi"s software even handles Syslog and SNMP, including from Linux and UNIX hosts, and performs real-time alerting and notification based on this data with a vast, and customizable, range of metrics that can be checked against.

Win XP 32/64, Win 2003 32/64, Windows Vista 32/64, Win7 32/64, Windows 2008 R2 32/64, Windows 8, Windows Server 2012 & 2012 R2; has both alert and notification ability.

2. PRTG (Free Version)

PRTG has some Syslog ability then added via a sensor to the PRTG monitoring suite.

Primarily focuses on SNMP and Syslog protocol data and has a good amount of analysis ability due to the built-in capability PRTG already has for general monitoring and management.

OS Compatibility and alert/notification ability: Any Windows 64-bit environment with Windows Server 2012 R2 specifically recommended; good notification and alerts, but all varies a bit as sensor must be added and configured by hand

3. SNMPSoft Sys-log Watcher

Installed as a dedicated syslog server for all manner of network devices with a native support for a good range of notification options – SNMPSoft"s program also boasts a particular ability to parse and handle non-standard Syslog, something that can cause some other software to falter!

Of particular note, there"s also a Syslog Watcher VendorPack available, which is a huge reference of syslog messages for proprietary equipment that helps in swift troubleshooting by defining non-standard syslog messages automatically.

OS Compatibility and alert/notification ability: Windows XP through Windows 10; robust notifications and solid alerts as well

4. Splunk Light

Not an ideal solution as even the Splunk forum will suggest using several Splunk servers for a proper setup, but still doable! Utilizing Splunk to index and manage log files is more strongly recommended, as syslog data will be lost with each Splunk restart by default.

None the less, it does offer syslog functionality and, with a little work getting several Splunks working together, can be a solid solution.

OS Compatibility and alert/notification ability: Splunk runs on Windows 64-bit versions as well as Linux and Mac OSX, syslog functionality varies; no real alerting or notification functionality for syslog

5. The Dude

The Dude, despite it"s odd name, is an interesting and free option for general network management – it comes with a built-in syslog server which can be enabled with ease as well as provides functionality for remote logging via RouterOS.

Log events can be filtered, sorted to different logs, or discarded based on customizable thresholds.

OS Compatibility and alert/notification ability: Most versions of Windows, recommended Windows 2000 or newer, also runs on Linux or MacOS using Wine/Darwine; email based notification with some on-screen alert or log-based alert options, too

6. TFTPD32

7. Syslog Server (Abandoned)

A fairly simple and barebones Syslog server that also doubles as an analyzer. It can be adjusted to only log and monitor events at certain threshold values and also can trigger email-based notifications, as well as sort the way in which events are displayed.

OS Compatibility and alert/notification ability: Service on Windows server prior to 2008, application functionality on most Windows versions; can trigger e-mail notifications based on thresholds

8. Icinga Open-Source Monitoring

Visual Syslog Server is a very straightforward and light-weight Syslog option that focuses on a real-time approach.

It does have some ability to handle and rotate logs automatically, to avoid bloat, and can also trigger scripts or programs based on thresholds that can be set.

OS Compatibility and alert/notification ability:

• Windows XP,
• Vista,
• as well as Windows Server 2003, 2008, 2012;

It can handle notifications via email and also some alerting and automated triggering of actions!

10. 3cDaemon

Based on the BSD-unix style functionality of syslogd, this particular offering is going to appeal to only a select crowd! None the less, it can handle logging based on priority, filter/restriction messages by IP, has real-time viewing of the log, and even can dump log information to plain ASCII.

OS Compatibility and alert/notification ability: Application level server run on most older Windows, newer OS versions may be iffy at best as the software is quite old; no real alerting or notification functionality

OS Compatibility and alert/notification ability:

11. Datagram

This software focuses on an enterprise level of functionality and is geared towards larger environments – it can gather and store a wide range of Syslog information and store it on a central database with a wide range of filters and alarms available.

OS Compatibility and alert/notification ability:

Windows 2000 and forwards; has alarm functionality but not much for notifications

Conclusion

Syslog tracking via a powerful Syslog server can save any network administrator an obscene amount of time and effort.

Every bit of data, whether SNMP or Syslog, that can be requested, aggregated, and analyzed is another potential piece of a puzzle that can trigger alerts or notifications and quickly bring human attention to the problem as soon as possible, or even fire off predefined scripts or programs to alleviate, or at least slow down, oncoming issues.

The flexibility of these programs are a superb way for admins to leverage monitoring to their advantage with the goal of maximum uptime and stability.

Much of this information can be seen on any one system or device, but even a small network with a few dozen devices would be totally unreasonable to monitor one by one – having it centralized, automated, and closely monitored is invaluable!

James Cox is the Editor at ITT Systems and has a Long History in the IT and Network Engineering Field. He Boasts a long list of Credentials ranging from CompTIA Certifications up to Cisco and VMWare points on his Resume.

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

Самый распространенный способ получения системных сообщений, предоставляемый сетевыми устройствами, - это использование протокола под названием 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.