Installation des ersten Windows-Client - monitoring

Installation des ersten Windows-Client
1 von 9
file:///E:/ici/windows client setup.md
Installation des ersten Windows-Client
Festlegungen
1. Der Master funktioniert und kann lokal checken.
2. Auf dem Master wurde bereits ìcinga2 node wizard` als Master ausgeführt und sein FQDN als CN
gewählt.
3. Er hat bei mir den Hostnamen und Endpoint-Nanmen debian85.local und die IP
192.168.200.6
4. Der Client heisst LAPTOP-AUQ5DGU2 .
5. Es wird eine Verbindung vom Client zur IP des Masters initiert und nicht umgekehrt.
Modifikationen auf dem Master
zones.conf
object Endpoint NodeName {
}
object Endpoint "LAPTOP-AUQ5DGU2"{
}
object Zone ZoneName {
endpoints = [ NodeName ]
}
object Zone "LAPTOP-AUQ5DGU2" {
endpoints= [ "LAPTOP-AUQ5DGU2" ]
parent= ZoneName
}
object Zone "global-templates" {
global = true
}
Folgende Befehle absetzen
root@debian85:/etc/icinga2/zones.d# mkdir /etc/icinga2/zone.d/globaltemplates
root@debian85:/etc/icinga2/zones.d# mkdir /etc/icinga2/zone.d/LAPTOPAUQ5DGU2
root@debian85:/etc/icinga2/zones.d# icinga2 pki ticket --cn 'LAPTOP-
30.12.2016 08:45
Installation des ersten Windows-Client
2 von 9
file:///E:/ici/windows client setup.md
AUQ5DGU2'
2483cf6f158c06f362b2f2a7ea29b72b25d14d17
root@debian85:/etc/icinga2/zones.d# icinga2 feature list
Disabled features: compatlog debuglog gelf graphite influxdb livestatus
opentsdb perfdata statusdata syslog
Enabled features: api checker command ido-mysql mainlog notification
Installation auf dem Windows Client
Binary von http://packages.icinga.org/windows/Icinga2-v2.6.0-x86_64.msi (http://packages.icinga.org
/windows/Icinga2-v2.6.0-x86_64.msi) herunterladen und starten, nach untenstehenden Screenshots
ausfüllen:
30.12.2016 08:45
Installation des ersten Windows-Client
3 von 9
file:///E:/ici/windows client setup.md
30.12.2016 08:45
Installation des ersten Windows-Client
4 von 9
file:///E:/ici/windows client setup.md
30.12.2016 08:45
Installation des ersten Windows-Client
5 von 9
file:///E:/ici/windows client setup.md
Anpassen auf dem Windows Client
zones.conf
Konfig Dateien liegen unter C:\ProgramData\icinga2\etc\icinga2 .
object Endpoint "debian85.local" {
### Folgende Zeile legt fest, dass der Client die Verbindung zum
Master aufbaut und nicht umgekehrt
host = "192.168.200.6"
port = "5665"
}
object Zone "master" {
endpoints = [ "debian85.local" ]
}
### NodeName ist eine Konstante aus constants.conf
object Endpoint NodeName {
}
30.12.2016 08:45
Installation des ersten Windows-Client
6 von 9
file:///E:/ici/windows client setup.md
### ZoneName ist eine Konstante aus constants.conf
object Zone ZoneName {
endpoints = [ NodeName ]
parent = "master"
}
object Zone "global-templates" {
global = true
}
Anlegen des ersten Dienstes auf dem Master, um die Top Down
Replikation zu prüfen
File /etc/icinga2/zone.d/LAPTOP-AUQ5DGU2/services.conf
### Wir nennen den Service hier loadtmp, weil load bereits existiert.
apply Service "loadtmp" {
import "generic-service"
check_command = "load"
enable_flapping = true
/* Used by the ScheduledDowntime apply rule in `downtimes.conf`. */
vars.backup_downtime = "02:00-03:00"
assign where host.name == "LAPTOP-AUQ5DGU2"
}
Zur Diagnose ausführen auf dem Master:
service icinga2 restart
icinga2 object list --type service --name loadtmp
Der Host (nicht Endpunkt !) LAPTOP-AUQ5DGU2 ist dem Master nicht bekannt. Also kann er auch keinen
Service dafür erstellen. Damit taucht weder der Host noch der Service im icingaweb2 auf.
Zur Diagnose ausführen auf dem Client:
C:\Program Files\ICINGA2\sbin>icinga2.exe object list --type service --name
loadtmp
Service wird ausgegeben. Wir haben eine erfolgreiche Replikation, aber kein erfolgreiches Monitoring.
Modifikationen, um das Monitoring zum Laufen zu bekommen.
auf dem Client conf.d\hosts.conf entfernen:
C:\ProgramData\icinga2\etc\icinga2\conf.d>ren hosts.conf hosts.conf.orig
C:\ProgramData\icinga2\etc\icinga2\conf.d>net stop icinga2
C:\ProgramData\icinga2\etc\icinga2\conf.d>net start icinga2
30.12.2016 08:45
Installation des ersten Windows-Client
7 von 9
file:///E:/ici/windows client setup.md
auf dem Master /etc/icinga2/zone.d/LAPTOP-AUQ5DGU2/services.conf
anlegen:
object Host "LAPTOP-AUQ5DGU2" {
import "generic-host"
address = "127.0.0.1"
address6 = "::1"
vars.os = "Windows"
vars.disks["disk"] = {
/* No parameters. */
}
vars.disks["disk C:"] = {
disk_win_path = "C:"
}
vars.notification["mail"] = {
groups = [ "icingaadmins" ]
}
}
Damit erreichen wir, dass das Host-Object vom Master auf den Client repliziert wird. Somit kennen nun
sowohl Master als auch Client das Host Object, und das Monitoring funktioniert. Hätten wir die hosts.conf
auf dem Client nicht entfernt, hätte dieser bei seiner Validierung des replizierten Host Objectes festgestellt:
"Hab ich schon in meiner conf.d/hosts.conf , Invalid, Dienst stoppen!!!"
Zur Diagnose ausführen auf dem Master:
service icinga2 restart
icinga2 object list --type service --name loadtmp
Dienst wird gefunden und ausgegeben.
Zur Diagnose ausführen auf dem Client:
C:\Program Files\ICINGA2\sbin>icinga2.exe object list --type service --name
loadtmp
Service wird ausgegeben. Wir haben eine erfolgreiche Replikation und ein erfolgreiches Monitoring auf
dem Master:
30.12.2016 08:45
Installation des ersten Windows-Client
8 von 9
file:///E:/ici/windows client setup.md
Weiteres Vorgehen
Wir wollen nun noch die services.conf zentral auf dem Master verwalten. Ändern wir sie hier, geht dies an
alle Zonen. Es sind dort apply rules drinn, die jeden Host erst einmal mit Basis - Services versorgen.
Zunächst entfernen wir daher die services.conf auf dem Client, er erhält sie danach vom Master repliziert
zurück:
C:\ProgramData\icinga2\etc\icinga2\conf.d>ren services.conf
services.conf.orig
C:\ProgramData\icinga2\etc\icinga2\conf.d>net stop icinga2
C:\ProgramData\icinga2\etc\icinga2\conf.d>net start icinga2
Auf dem Master verschieben wir die services.conf nun in die global-templates:
root@debian85:/etc/icinga2/conf.d# mv services.conf ../zones.d/globaltemplates/
30.12.2016 08:45
Installation des ersten Windows-Client
9 von 9
file:///E:/ici/windows client setup.md
und ändern den Service load dort ab von:
apply Service "load" {
import "generic-service"
check_command = "load"
enable_flapping = true
/* Used by the ScheduledDowntime apply rule in `downtimes.conf`. */
vars.backup_downtime = "02:00-03:00"
assign where host.name == NodeName
}
nach:
apply Service "load" {
import "generic-service"
check_command = "load"
enable_flapping = true
/* Used by the ScheduledDowntime apply rule in `downtimes.conf`. */
vars.backup_downtime = "02:00-03:00"
assign where host.name
}
Die temporäre können wir nun löschen (müssen aber nicht...):
root@debian85:/etc/icinga2/conf.d# rm ../zones.d/LAPTOP-AUQ5DGU2
/services.conf
root@debian85:/etc/icinga2/conf.d# service icinga2 restart
und prüfen, dass das Monitoring nun noch läuft. Der Service loadtmp wurde durch load ersetzt.
Nun solltest Du gelernt haben:
Objekte, die in allen Zonen existieren sollen, gehören nach zones.d/global-templates .
Objekte, die in einer speziellen Zone existieren sollen, gehören nach zones.d/[zonename] .
Objekte, die in conf.d existieren, können mit den vom Master replizierten konflikten und sind
daher soweit möglich zu vermeiden.
30.12.2016 08:45

Download Report