Benutzer fragen oft nach neuen Variablen in Host-, Service- und Kontaktdefinitionen. Dazu gehören Variablen für die SNMP-Community, MAC-Adressen, AIM-Benutzernamen, Skype-Nummern und Straßennamen. Die Liste ist endlos. Das Problem, was wir darin sehen ist, dass Icinga weniger generisch und mehr infrastrukturspezifisch wird. Icinga war dazu gedacht, flexibel zu sein, was bedeutet, dass die Dinge in einer generischen Art und Weise geplant waren. Host-Definitionen in Icinga zum Beispiel haben eine generische "address"-Variable, die alles von einer IP-Adresse bis zu menschlich-lesbaren Wegbeschreibungen enthalten kann - was immer für die Umgebung des Benutzers angemessen ist.
Trotzdem muss es eine Methode für Administratoren geben, in ihrer Icinga-Konfiguration Informationen zu ihren Infrastrukturkomponenten zu speichern, ohne anderen einen Satz von speziellen Variablen aufzubürden. Icinga versucht dieses Problem zu lösen, indem es Benutzern erlaubt, maßgeschneiderte Variablen in ihren Objektdefinitionen anzugeben. Maßgeschneiderte Variablen erlauben es Benutzern, zusätzliche Eigenschaften in ihren Host-, Service- und Kontaktdefinitionen anzugeben und ihre Werte in Benachrichtigungen, Eventhandlern sowie Host- und Service-Prüfungen zu benutzen.
Es gibt ein paar wichtige Dinge, die Sie bei maßgeschneiderten Variablen beachten sollten:
maßgeschneiderte Variablennamen müssen mit einem Unterstrich (_) beginnen, um einen Namenskonflikt mit Standardvariablen zu verhindern
maßgeschneiderten Variablennamen werden vor der Benutzung in Großbuchstaben umgewandelt
maßgeschneiderten Variablen werden von Objektvorlagen wie normale Variablen geerbt
Scripts können sich mit Makros und Umgebungsvariablen auf die Werte von maßgeschneiderten Variablen beziehen
Wichtig | |
---|---|
Maßgeschneiderte Variablen werden erst zur Laufzeit ersetzt, weder bei der Überprüfungsphase (icinga -v
icinga.cfg) noch während des Icinga-Startprozesses, so dass das Platzieren in Host-Namen, Service-Beschreibungen oder
verschiedenen anderen Stellen der Objektdefinition während der Überprüfung zu einer Fehlermeldung ähnlich " |
Hier ein Beispiel, wie maßgeschneiderte Variablen in verschiedenen Arten von Objektdefinitionen definiert werden können:
define host{ host_name linuxserver _mac_address 00:06:5B:A6:AD:AA ; <-- Custom MAC_ADDRESS variable _rack_number R32 ; <-- Custom RACK_NUMBER variable ... } define service{ host_name linuxserver description Memory Usage _SNMP_community public ; <-- Custom SNMP_COMMUNITY variable _TechContact Jane Doe ; <-- Custom TECHCONTACT variable .... } define contact{ contact_name john _AIM_username john16 ; <-- Custom AIM_USERNAME variable _YahooID john32 ; <-- Custom YAHOOID variable ... }
Maßgeschneiderte Variablen können über Makros oder Umgebungsvariablen in Scripts und Programmen eingesetzt werden, die Icinga für Prüfungen, Benachrichtigungen usw. ausführt.
Um Namenskonflikte zwischen maßgeschneiderten Variablen aus verschiedenen Objektarten zu verhindern, stellt Icinga "_HOST", "_SERVICE" oder "_CONTACT" an den Anfang von maßgeschneiderten Host-, Service- oder Kontaktvariablennamen in Makros und Umgebungsvariablen. Die folgende Tabelle zeigt die entsprechenden Namen für maßgeschneiderte Variablen, die im obigen Beispiel definiert wurden.
Objekttyp |
Variablenname |
Makroname |
Umgebungsvariable |
Host |
MAC_ADDRESS |
$_HOSTMAC_ADDRESS$ |
ICINGA__HOSTMAC_ADDRESS |
Host |
RACK_NUMBER |
$_HOSTRACK_NUMBER$ |
ICINGA__HOSTRACK_NUMBER |
Service |
SNMP_COMMUNITY |
$_SERVICESNMP_COMMUNITY$ |
ICINGA__SERVICESNMP_COMMUNITY |
Service |
TECHCONTACT |
$_SERVICETECHCONTACT$ |
ICINGA__SERVICETECHCONTACT |
Contact |
AIM_USERNAME |
$_CONTACTAIM_USERNAME$ |
ICINGA__CONTACTAIM_USERNAME |
Contact |
YAHOOID |
$_CONTACTYAHOOID$ |
ICINGA__CONTACTYAHOOID |
Maßgeschneiderte Objektvariablen werden genau wie Standard-Host-, Service- oder Kontaktvariablen vererbt.
© 1999-2009 Ethan Galstad, 2009-2017 Icinga Development Team, https://www.icinga.com