====== Icinga2 jako przykład NMS ======
===== Network Monitoring System =====
NMS (//Network Monitoring System//, [[https://en.wikipedia.org/wiki/Network_monitoring|[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 [[https://www.icinga.com/products/icinga-2/|[1]]], [[https://en.wikipedia.org/wiki/Icinga|[2]]].
===== Serwer, frontend, agent, … =====
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.
===== Instalacja Icinga2 =====
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: |
{{ :zsk:icinga2-topo.png?nolink |}}
++++
==== Serwer ====
Ć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 [[https://www.icinga.com/docs/icinga2/latest/doc/06-distributed-monitoring/|[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
Do diagnozowania problemów można włączyć rozszerzony o komunikaty diagnostyczne log:
icinga2 feature enable debuglog
systemctl restart icinga2
tail -f /var/log/icinga2/debug.log
==== Frontend ====
Icinga2 ma (typowy dla takich aplikacji) frontend webowy pod nazwą [[https://www.icinga.com/products/icinga-web-2/|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.
===== Monitoring hostów i usług =====
//(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:
- ''/etc/icinga2/constants.conf'' - zwróć uwagę na NodeName i ZoneName
- ''/etc/icinga2/conf.d/hosts.conf'' - lista monitorowanych węzłów (hostów)
- ''/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.
- ''/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 [[https://www.icinga.com/docs/icinga2/latest/doc/10-icinga-template-library/|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 - [[https://www.icinga.com/docs/icinga2/latest/doc/10-icinga-template-library/#plugin-contrib-command-nwc_health|[1]]] | [[https://labs.consol.de/nagios/check_nwc_health/index.html|[2]]]
==== Monitoring hostów ====
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ę
==== Monitoring snmp ====
Systemy NMS pozwalają na badanie stanu z wykorzystaniem [[zsk:snmp|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 [[https://www.icinga.com/docs/icinga2/latest/doc/10-icinga-template-library/#plugin-check-command-snmp|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.
==== Monitoring usług sieciowych - przykład DNS i DHCP ====
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
==== Monitoring usług sieciowych z czasem odpowiedzi - przykład HTTP ====
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 za pośrednictwem agentów ====
=== SNMP ===
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
=== Kolejna icinga2 ===
//(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/"
}
==== [Ekstra] Monitoring za pośrednictwem agentów – NSClient++ ====
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
===== Powiadomienia =====
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.