NMS (Network Monitoring System, [1]) to nazwa określająca narzędzia do monitorowania stanu usług i maszyn w sieci w celu powiadomienia administratorów o awariach.

Dostępny jest szeroki wybór systemów NMS, przykładowa lista NMSów: https://en.wikipedia.org/wiki/Comparison_of_network_monitoring_systems

W trakcie zajęć jako przykład takiego systemu zostanie przedstawiona Icinga 2 [1], [2].

Typowe role programów w NMS to:

Serwer – program wykonujący monitoring i wysyłający powiadomienia.

Frontend – interfejs (zwykle webowy) prezentujący stan.

Agent – program na zdalnej maszynie, który sprawdza stan żądanej usługi, a z którym łączy się serwer.

Uwaga: przy instalacji icinga2 będzie trzeba stworzyć 2 bazy danych i 5 różnych list użytkowników.
W trakcie zajęć zwróć szczególną uwagę który użytkownik i hasło jest za co odpowiedzialne.

Grafika obrazująca komponenty systemu i użytkowników:

Ćwiczenia proszę wykonywać na maszynie wirtualnej 'Linux SK prog' (VLAB/VM: Linux SK prog).

(Instrukcje instalacji za https://www.icinga.com/docs/icinga2/latest/doc/02-getting-started/)

Aktualna wersja Icingi dla Debiana jest w zewnętrzem repozytorium, które należy dodać komendą:

wget -O - https://packages.icinga.com/icinga.key | apt-key add -
echo 'deb https://packages.icinga.com/debian icinga-stretch main' >/etc/apt/sources.list.d/icinga.list
apt-get update

Instalacja samego serwera odbywa się z wykorzystaniem polecenia:

apt install icinga2 monitoring-plugins

NB: Icinga moze działać w kilku rolach ('master', 'sattelite', 'client' / agent [1]). Dlatego instalacja icinga2 nie instaluje automatycznie wszystkich potrzebnych dla 'mastera' zależności.

Węzeł typu 'master' potrzebuje bazy danych:

apt install default-mysql-server icinga2-ido-mysql

Aby sprawdzić ustawienia wygenerowane przez dpkg -configure, możesz:

cat /etc/icinga2/features-available/ido-mysql.conf

Instalacja szerszego niż domyślny zbioru wtyczek do monitorowania:

apt install monitoring-plugins nagios-plugins nagios-snmp-plugins snmp smistrip

Do wykorzystania uruchomionej i skonfigurowanej bazy danych w serwerze icinga2, należy:

icinga2 feature enable ido-mysql
systemctl restart icinga2

Uwaga: jeśli używasz edytora vim, wykonaj też:

apt install vim-icinga2
vim-addon-manager -w install icinga2

icinga2 feature enable debuglog
systemctl restart icinga2
tail -f /var/log/icinga2/debug.log

Icinga2 ma (typowy dla takich aplikacji) frontend webowy pod nazwą Icinga Web 2.
Stąd instalacja frontendu sprowadza się do konfiguracji serwera HTTP (ze wsparciem dla php) i bazy danych na potrzeby webaplikacji.

Instalacja serwera HTTP i plików frontendu:

apt install apache2 icingaweb2 icingacli   

Domyślna konfiguracja serwera apache2 jest wystarczająca, możesz ją przejrzeć w:

cat /etc/apache2/conf-enabled/icingaweb2.conf

Brakuje natomiast (sprawdzanego przez frontend) ustawienia strefy czasowej w php:

echo 'date.timezone = Europe/Warsaw' >> /etc/php/7.0/apache2/php.ini

Tworzenie użytkownika i bazy danych na potrzeby frontendu:

mysql
MariaDB [(none)]> CREATE DATABASE icingaweb2;
MariaDB [(none)]> GRANT ALL ON icingaweb2.* TO icingaweb2 IDENTIFIED BY 'password';

Łączenie ze sobą Icinga Core (serwera) i Icinga Web (frontendu) odbywa się po API RESTowym. Aby skonfigurować API po stronie serwera, należy wykonać:

icinga2 api setup

A następnie zdefiniować nowego użytkownika tego API w pliku /etc/icinga2/conf.d/api-users.conf

$EDITOR /etc/icinga2/conf.d/api-users.conf
  
  object ApiUser "icingaweb2" {
    password = "pass"
    permissions = [ "status/query", "actions/*", "objects/modify/*", "objects/query/*" ]
  }

Przed skonfigurowaniem frontendu zresetuj zarówno serwer HTTP jak i serwer icinga2:

systemctl restart icinga2
systemctl reload apache2

Dalsza część konfiguracji odbywa się z poziomu webui: http://localhost/icingaweb2
Do wygenerowania tokenu użyj:

icingacli setup token create

Po skończeniu konfiguracji, dodaj nowego użytkownika do frontendu.

(za https://www.icinga.com/docs/icinga2/latest/doc/03-monitoring-basics/)

W domyślnej konfiguracji od razu po zainstalowaniu icinga2 monitoruje lokalny system.
Przejrzyj pliku konfigurujące to monitorowanie:

1. /etc/icinga2/constants.conf - zwróć uwagę na NodeName i ZoneName
2. /etc/icinga2/conf.d/hosts.conf - lista monitorowanych węzłów (hostów)
3. /etc/icinga2/conf.d/services.conf - definicja usług, które mają być monitorowane. Zwróć uwagę na apply i assign – te reguły decydują, na których węzłach zostanie uruchomiane sprawdzenie stanu.
4. /etc/icinga2/conf.d/templates.conf - definicja szablonów; zwróć uwagę na to, co jaki czas są odpytywane usługi i węzły

Sprawdź w dokumentacji jak przekonać usługę swap do ignorowania braku swapu, następnie wczytaj na nowo pliki konfiguracyjne:

systemctl reload icinga2 || journalctl --no-pager -n 50 _SYSTEMD_UNIT=icinga2.service

Zwykle sprawdzenie stanu usług / węzłów odbywa się przy pomocy wtyczek.
Icinga (jako dawny fork nagiosa) jest kompatybilna z wtyczkami do Nagiosa. Dostępne wtyczki to między innymi:

• podstawowe wtyczki - https://www.monitoring-plugins.org/
• wtyczki dla SNMP - http://nagios.manubulon.com/index_snmp.html
• dedykowana wtyczki dla sprzętu sieciowego - [1] | [2]

Dodaj do listy hostów (plik /etc/icinga2/conf.d/hosts.conf) kilka hostów, sprawdzając ich dostępność przy użyciu ICMP:

object Host "/nazwa/" {
  import "generic-host"
  address = "/adres/"
  check_command = "hostalive"
}

Uwaga: W przykładach fragmenty w ukośnikach (np. /nazwa/) należy zastąpić właściwą treścią (np. lab-sec-30)!

Dodaj przynajmniej (1) jeden komputer z sali, (2) router robiący za bramę domyślną (3) switch na salę

Systemy NMS pozwalają na badanie stanu z wykorzystaniem SNMP.

Poniżej przykładowa ręczna konfiguracja sprawdzania stanu interfejsów:

object Host "/losowySwitch/" {
  import "generic-host"
  address = "/10.0.0.254/"
  check_command = "hostalive"
  vars.oids["/if1/"] = [ "/IF-MIB::ifOperStatus.1/" , "up" ]
  vars.oids["/if2/"] = [ "/IF-MIB::ifOperStatus.2/" , "up" ]
}

apply Service for (identifier => arr in host.vars.oids) {
  import "generic-service"
  check_command = "snmp"
  display_name = identifier
  vars.snmp_oid = arr[0]
  vars.snmp_ereg = arr[1]
}

W powyższy sposób można sprawdzić stan dowolnego OIDu. Lista opcji snmp dostępna tutaj.

Do typowych zadań, takich jak monitorowanie interfejsów, istnieją gotowe wtyczki. Przykład użycia takiej wtyczki:

object Host "/losowySwitch/" {
  import "/generic-host/"
  address = "10.0.0.254"
  check_command = "hostalive"
  vars.snmp_ifs = [".*"]
}

apply Service for (ifs in host.vars.snmp_ifs ) {
  import "generic-service"
  check_command = "snmp-interface"
  display_name = "snmp-interface" + ifs
  vars.snmp_interface = ifs
}

Przetestuj obie metody – skonfiguruj monitorowanie stanu interfejsów na routerze i switchu laboratoryjnym. Dostosuj listę monitorowanych interfejsów.

Przykład monitoriwania serwera DNS:

object Host "/serwerDNS/" {
  import "generic-host"
  address = "/150.254.5.11/"
  check_command = "hostalive"
  vars.dns_queries = {
                  "/fc/"      = [ "/A/",    "/fc.cs.put.poznan.pl/" ] ,
                  "/reverse/" = [ "/PTR/" , "/103.30.254.150.in-addr.arpa/" ]
                 }
}

apply Service "CheckDnsServer" for ( id => query in host.vars.dns_queries) {
  import "generic-service"
  display_name = "DNS: " + id
  check_command = "dig"
  vars.dig_server = host.address
  vars.dig_record_type = query[0]
  vars.dig_lookup = query[1]
}

Skonfiguruj monitorowanie usług sieciowych DNS (dla innych domen) i DHCP.

• https://www.icinga.com/docs/icinga2/latest/doc/10-icinga-template-library/#dig
  
• https://www.icinga.com/docs/icinga2/latest/doc/10-icinga-template-library/#dhcp

Skonfiguruj sprawdzanie http dla wybranej strony www:
https://www.icinga.com/docs/icinga2/latest/doc/10-icinga-template-library/#plugin-check-command-http
W tym celu powinno się:

• dodać host
• dodać usługę używającą komendy http
  • jeśli potrzebujesz, określić http_address / http_vhost / http_uri
  • ustawić http_warn_time i http_critical_time (jako odpowiedni ułamek sekundy)

Monitoring z wykorzystaniem SNMP został omówiony wcześniej.
Warto tutaj podkreślić, że SNMP pełni rolę agenta: Icinga odpytuje agenta SNMP działającego na zdalnym urządzeniu, a agent SNMP odpytuje lokalny sprzęt.

W Icinga można dodatkowo przechwytywać komunikaty SNMP trap/inform (z wykorzystaniem pośredniego programu snmptt):
https://www.icinga.com/docs/icinga2/latest/doc/07-agent-based-monitoring/#passive-check-results-and-snmp-traps

(za: https://www.icinga.com/docs/icinga2/latest/doc/06-distributed-monitoring/)

Jako agenta można wykorzystać kolejną Icingę, skonfigurowaną jako klient.

Aby to zrobić, na kliencie należy wpierw zainstalować:

apt install icinga2 monitoring-plugins

A następnie skonfigurować węzeł jako klient poleceniem:

icinga2 node wizard

Uwaga: należy zgodzić się na przyjmowanie komend i konfiguracji

Dodatkowo po stronie mastera należy zaakceptować certyfikat klienta (komunikacja między serwerami jest szyfrowana):

icinga2 ca list
icinga2 ca sign /hash/

Po zaakceptowaniu certyfikatu należy jeszcze uruchomić ponownie klienta:

systemctl restart icinga2

Reszta konfiguracji wykonywana jest na głównym serwerze, gdzie trzeba wpierw zmienić plik /etc/icinga2/zones.conf dodając nowego klienta:

object Endpoint "/client/" {
  host = "/10.0.1.150/"
}

object Zone "/someClients/" {
  endpoints = [ "/client/" ]
  parent = ZoneName
}

Uwaga: Icinga sprawdza nazwy - pole common name (CN) certyfikatu klienta musi być identyczne jak nazwa endpointu.

Dalej należy dodać klienta jako kolejny węzeł:

object Host "/client/" {
  import "generic-host"
  check_command = "hostalive"
  address = "/10.0.1.150/"
  vars.client_endpoint = name
}

Przykład usługi uruchamianej na zdanym węźle:

apply Service "load" {
  import "generic-service"
  check_command = "load"
  command_endpoint = host.vars.client_endpoint
  assign where host.vars.client_endpoint == "/client/"
}

Innym przykładem agenta do monitorowania zdalnego systemu jest program NSClient++.
Zarówno NSClient++ jak i Icinga 2 działają zarówno pod Linuksem jak i Windowsem, jednak Icinga 2 dużo lepiej wspiera monitorowanie Linuksów, a NSClient++ - Windowsów.

Więcej na:

• https://www.nsclient.org/
• https://www.icinga.com/docs/icinga2/latest/doc/07-agent-based-monitoring/#nsclient

Aby odbierać powiadomienia mailowe, zainstaluj przykładowe MTA:

apt install exim4-daemon-light

W domyślnej konfiguracji maile kierowane do roota trafiają do pliku /var/mail/mail, więc możesz je wyświetlić np.:

mail -f /var/mail/mail

lub

tail -f /var/mail/mail

Maile kierowane do zwykłych użytkowników trafiają do ich katalogu domowego, do ~/Maildir można je więc wyświetlić np.:

mail -f ~/Maildir

Dodaj użytkownika student do icinga2 (serwera) w pliku /etc/icinga2/conf.d/users.conf:

object User "student" {
  import "generic-user"
  enable_notifications = true
  email = "student@localhost"
}

Nakaż wysyłanie wszystkich powiadomień użytkownikowi 'student' w pliku /etc/icinga2/conf.d/notifications.conf:

apply Notification "notify" to Service {
  import "mail-service-notification"
  users = ["student"]
  assign where true
}

apply Notification "notify" to Host {
  import "mail-host-notification"
  users = ["student"]
  assign where true
}

Sprawdź czy student dostaje te powiadomienia.
Sprawdź jak wyglądają powiadomienia z interfejsu webowego.
Jak wyłączyć kolejne maile z powiadomieniami?

Następnie skonfiguruj powiadomienia tak, by student dostawał tylko powiadomienia dotyczące wybranego hosta.

Domyślnie powiadomienia są wysyłane po 5 minutach od wykrycia awarii i są wysyłane do skutku. Można to oczywiście zmienić; więcej informacji na: https://www.icinga.com/docs/icinga2/latest/doc/03-monitoring-basics/#notification-delay

Przejrzyj pliki:

• /etc/icinga2/conf.d/templates.conf
  zobacz jak wygląda szablon powiadomienia mail-service-notification / mail-host-notification
• /etc/icinga2/conf.d/commands.conf
  zobacz jak wygląda definicja komendy mail-service-notification / mail-host-notification

Stwórz powiadomienie które poinformuje o awarii używając komendy wall:

object NotificationCommand "wall-service" {
  command = [ "wall" , "Icinga2: $service.name$ is $service.state$" ]
}

template Notification "wall-service" {
  import "mail-service-notification"
  interval = 0
  command = "wall-service"
}

apply Notification "wall" to Service {
  import "wall-service"
  users = ["icingaadmin"]
  assign where true
}

Uwaga: komunikaty wall nie są wyświetlane na domyślnym terminalu, żeby je zobaczyć uruchom np. xterm.

Konfiguracja dowolnych komend do powiadamiania o problemach jest konieczna np. do ustawienia powiadomień SMS.