Time to celebrate! Unser Netways Monitor


Unser Shop Team und viele rauchende Köpfe haben sich vor einiger Zeit zusammengeschlossen und den Netways Monitor geschaffen. Heuer feiert er seinen ersten Geburtstag und aus diesem Anlass wollen wir einen erfolgreichen Rückblick geben aber auch einen vielversprechenden Ausblick!

Unser Netways Monitor ist:

  • ein zuverlässiger Wächter für den Serverraum oder Rechenzentrum
  • bis zu vier Anschlüssen für Sensoren zur Überwachung von Luftfeuchtigkeit und Temperatur eingerichtet
  • SNMP-fähig und kann in Ihre Monitoringumgebung, bestenfalls Icinga 2 eingebunden werden.
  • mit einem benutzerfreundlichen Webinterface ausgestattet
  • E-Mail Alarmierung mit TLS- Verschlüsselung

Hinter den Netways Kulissen arbeiten unsere Experten für die Zukunft momentan mit Hochdruck daran, neue Features einzubauen! Unter anderem wird es bald einen Sensor mit potentialfreien Kontakt geben, der den Netways Monitor noch attraktiver macht.
Mit vielen Ideen und unglaublich viel und noch viel mehr werden wir euch in Kürze die Neuerungen des Netways Monitors präsentieren. Seit also gespannt, und schaut doch schon mal im Shop vorbei.

Silke Panayiotou
Silke Panayiotou
Account Manager

Silke ist seit März 2018 wieder zurück bei NETWAYS und unterstützt nun das Sales Team. Hier ist sie für alle Belange des Online Stores verantwortlich und treibt den Ein- und Verkauf der Monitoring Hardware und die Weiterentwicklung des Shops mit ihrem bekannten Tatendrang gehörig voran. Da sie privat den Zweitjob Mama hat und sich um ihre kleine Tochter kümmert, ist sie nur vormittags im Haus.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 2: Features

This entry is part 2 of 14 in the series Icinga 2 Monitoring automatisiert mit Puppet

Heute steht der Blog um des Icinga Puppet-Modul ganz im Zeichen der Icinga-2-Features. Features lassen sich entweder über die main class aktivieren und via Hiera parametrisieren oder dediziert mittels einer eigenen Klasse deklarieren.

include ::mysql::server
include ::icinga2
mysql::db { 'icinga':
  user     => 'icinga',
  password => 'secret',
  host     => 'localhost',
  grant    => ['SELECT', 'INSERT', 'UPDATE', 'DELETE', 'DROP', 'CREATE VIEW', 'CREATE', 'INDEX', 'EXECUTE', 'ALTER'],
  before   => Class['::icinga2']
}

Da die Klasse icinga2 auch über einen Parameter features verfügt über den die angegeben Features aktiviert werden, kann auch dieser Parameter nach Hiera ausgelagert werden. Nachfolgend wird für die MySQL-IDO-Anbindung das Passwort gesetzt und veranlasst, dass erstmalig das DB-Schema importiert wird. Alle anderen Parameter für das Feature idomysql, sowie alle für mainlog und checker sind die entsprechenden Default-Werte.

---
icinga2::features:
  - checker
  - notification
  - mainlog
  - idomysql
icinga2::feature::idomysql::password: secret
icinga2::feature::idomysql::import_schema: true

Das selbe erreicht man ebenfalls unter Verwendung der direkten Deklaration:

class { '::icinga2::feature::idomysql':
  password      => 'secret',
  import_schema => true,
}

Etwas anders verhält es sich, wenn man die Feature checker, notification oder mainlog explizit deklarieren möchte. Da diese die standardmäßig aktivierten Features sind, muss das entsprechende Feature vorher deaktiviert werden bzw. nur die anderen im Parameter features angegeben werden:

class { '::icinga2':
  features => [ 'checker', 'notification' ],
}
class { '::icinga2::feature::mainlog':
  severity => 'notice',
}

Der Weg über die Konfiguration über Hiera ist da doch wirklich eleganter. Die Deklaration ist übersichtlich

include ::icinga2

und auch in Hiera ist nicht viel zu hinterlegen:

---
icinga2::feature::manilog::severity: notice
Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Besser spät als nie …

LConf_LogoJa, es ist schon fast zu spät für einen Blogpost vor dem wohlverdienten Wochenende, aber Icinga 1.9 als Core Release Manager steht an, sowie auch Icinga2 vorankommen muss. Aber es gibt da noch ein Tool, was sich aktiv in der Entwicklung befindet – LConf.
Nicht zu verwechseln mit LConf für Icinga Web, dem schönen Web Interface mit komfortablen Features wie Drag&Drop. LConf ist ja eigentlich für einen grossen Kunden entwickelt worden, und erfreut sich seither wachsender Beliebtheit (was wohl auch daran liegt, dass man damit schöne Icinga Distributed Setups bauen kann, aber dazu später mehr).
Es gibt nun schon eine Weile das Release 1.3.0rc und neben den schon angesprochenen Performance Verbesserungen (und Templates in die Vererbung miteinbeziehen zu können) gibts noch einige Veränderungen, Fixes und Features die seither eingeflossen sind:

  • der Export der Konfiguration aus dem LDAP Baum kann nun (optional) durch Child Prozesse parallelisiert und damit beschleunigt werden. Der Defaultwert sind 2 Prozesse um den Monitoringserver nicht allzusehr zu stressen. Soll heissen, wenn man 24 Cores zur Verfügung hat, und LConf Export 12 Childs erlaubt, lässt sich ein 13000 Service Export auch mal ums 2,5fache verringern. Das ist also insbesondere in grossen Umgebungen interessant, und bringt neben der verminderten Anzahl an LDAP Abfragen im Vergleich zu 1.2 einen erheblichen Geschwindigkeitsvorteil.
  • beim Export lassen sich benutzerdefinierte Scripts ausführen. Dies wird zB dazu verwendet, um für jeden Host/Service eine Custom Variable mit der LDAP DN zu setzen, um dann später vom Service im Icinga Monitoring direkt in die LConf Baum Konfiguration zu springen. Diese Idee kann man aber noch weiterspinnen und eigene Custom Variablen und andere Attribute exportieren. Sinn macht das insbesondere für verteilte Umgebungen, wo man beispielsweise anhand von Servicenamensmustern dann Standortmuster erkennt und diese als Customvariable abspeichert. Neben der Scripts die die Slave Konfiguration beinflussen, gibt es jetzt auch eine mid-master.pl die lediglich die Master Konfiguration manipuliert (zB dort alle Checks als passiv setzt, o.ä.)
  • LConfSlaveSync als Checkresultsammler kann nun übrigens auch direkt das Icinga Checkresult Spooldir schreiben, um blockiert somit nicht die External Command Pipe. Die Option directIO ist auch in Zukunft so gesetzt.
  • Custom Variablen können nun verwendet werden, um dynamische Objektnamen zu generieren. Also beispielsweise wird die Service Custom Variable “_PORT 1337” aus “http_$_SERVICEPORT$” den sprechenden Namen “http_1337” erzeugen. Was man da dank Vererbung im LDAP Baum dann alles anstellen kann….
  • der gewisse Mehrwert, den Software haben muss – Pakete die einfaches Installieren/Upgraden erlauben. Dementsprechend haben wir in schon in Kundenprojekten Pakete für LConf gebaut (und tun das auch (auf Anfrage) für all unsere Addons), und gleichzeitig auch notwendige Änderungen an der LConf Struktur vorgenommen. So sind etwa alle Scripts in bin/ installiert, während die Perl Module in lib/ ihren Platz finden, var/ und tmp/ dienen dem Export als Ablage und in etc/ findet sich die Konfiguration wieder. Die meisten Optionen sind nun via configure Parameter einstellbar – ich halte das ähnlich wie bei meinen Icinga RPMs – wenns mich nervt, bau ichs passend Upstream richtig. Das heisst also nun folgerichtig – auch LConf Pakete sind in Vorbereitung (auch LConf für Icinga Web ist entsprechend angepasst worden). 
  • Alle bisherigen Änderungen sind in doc/UPGRADING dokumentiert. Das betrifft auch Änderungen im Vergleich zur 1.3.0 RC.  alle Tester bitte vor der Installation konsultieren. Achja, wir unterwerfen uns gitflow, weswegen der brandaktuelle Entwicklungszweig auch immer im GIT Branch next (als Snapshot) zu finden ist 🙂

Die alles umfassende Frage – wann kommts denn nun? Nun, bald. Ob Juni realistisch ist, wage ich mal zu bezweifeln, aber die Hoffnung stirbt ja bekanntlich zuletzt. Feedback und Tester sind natürtlich jederzeit willkommen, um den Entwicklungsprozess zu beschleunigen! 😉
Für all jene die bis jetzt durchgehalten haben, noch ein kleines Anschauungsbeispiel wie man LConf in verteilten Umgebungen ebenso implementieren kann.
Folgendes Beispiel erkennt anhand des Musters “denu” dass die deutsche Location “Nuernberg” als Customvariable zu setzen ist, sofern der Hostname darauf passt. Um später auch die Services danach zu filtern, wird diese Customvariable direkt im Anschluss auch an diese vererbt. Das Script wird als mid.pl im Order custom/ abgelegt (kann via configure –with-export-script-dir angepasst werden).

sub CustomMid {
    my $changes = {
        'denu' => {
            '_LOCATION' => 'Nuernberg'
        }
    };
    my $CLIENTS = shift;
    foreach my $client (keys %{$CLIENTS}) {
        foreach my $hostChange (keys %{$changes}) {
            if ($CLIENTS->{$client}->{cn} =~ /$hostChange/) {
                foreach my $cv (keys %{$changes->{$hostChange}}) {
                    $CLIENTS->{$client}->{lconfhostcustomvar}->{$cv} = $changes->{$hostChange}->{$cv};
                }
            }
        }
        foreach my $cv (keys %{$CLIENTS->{$client}->{lconfhostcustomvar}}) {
            foreach my $service (keys %{$CLIENTS->{$client}->{SERVICES}}) {
                $CLIENTS->{$client}->{SERVICES}->{$service}->{lconfservicecustomvar}->{$cv} = $CLIENTS->{$client}->{lconfhostcustomvar}->{$cv};
            }
        }
    }
}

Diese Custom Variable könnte man nun als Auswahlkriterium sehen, dass auf dem Icinga Slave in Nürnberg all diese Host und Service Checks durchgeführt werden sollen (natürlich könnte man das auch via LCONF->EXPORT->MODIFY lösen, aber dieser Ansatz hier erlaubt freiere Baumstrukturen, die ich lieber mag 😉 ). Hier gibts lediglich ein Problem – LConfSlaveExport kann die Konfiguration nicht anhand von Attributsmustern für die Slaves aufsplitten. Also haben wir uns etwas neues überlegt – LConfSlaveExportRules übernimmt an dieser Stelle.
Folgende Konfiguration in etc/config.pm stellt sicher, dass alle Services mit dem Muster Nürnberg nur an den Slave Satelliten “satelite1.icinga” exportiert werden. Neben den obligatorischen Einstellungen ‘rules’ und ‘targets’ kann man mittels ‘settings’ auch beinflussen, ob Parents und/oder Dependencies auf diesem Slave zum Tragen kommen sollen. Die Erfahrung hat gezeigt, dass zerschnittene Slavekonfiguration nicht für derartige Dinge taugt, und die Logik nur am Monitoring Master sinnvoll einzusetzen ist.

$cfg->{slaveexportrules} = {
   'rules' => {
       'service-rule1' => {
           'object' => 'lconfservice',
           'attribute' => 'lconfservicecustomvar',
           'pattern' => 'Nuernberg'
       },
},
   'targets' => {
       'satelite1.icinga' => {
           'targetDir' => '/etc/icinga/lconf',
           'rulemap' => 'service-rule1'
       },
   },
   'settings' => {
       'slaveexportparents' => 0,
       'slaveexportdependencies' => 0,
   },
};

Der Aufruf in LConfDeploy.sh könnte dann etwa so aussehen (anstatt der Verteilung durch LConfSlaveExport)

(cd $LCONFBINPATH ; $SUDOCOMMAND /usr/bin/LConfSlaveExportRules.pl -v )

Achja, die Custom Variablen kann man in Icinga Web übrigens auch für erweiterte Filter und ebenso Berechtigungen verwenden. Aber dazu ein andermal mehr.
Wie man LConf insbesondere in komplexen verteilten Umgebungen sinnvoll einsetzt, darüber wissen unsere Spezialisten im Consulting bestens Bescheid. Aber auch Schulungen mit dem optimalen Wissenstransfer sind hier nicht zu verachten, denn viele Dinge die LConf kann, zeigt und lernt man am besten persönlich 🙂

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

MySQL New Features – Pluggable Authentication

Neben den bereits angesprochenen Features Semisynchronous-Replication und Background I/O-Threads bietet MySQL ab der Version 5.5.7 eine weitere Möglichkeit des Core-Systems mit eigenen Erweiterungen zu ergänzen. Wurde die Benutzerauthentifizierung bisher ausschließlich durch Evaluierung der user-Tabelle durchgeführt, ist das Authentifizierungsverfahren nun in einer eigenen Pluginschnittstelle entkoppelt.
Die Authentifizierung erfolgt unverändert durch Prüfung des angegebenen Benutzers jedoch kann zur Validierung des Kennworts eine alternative Schnittstelle verwendet werden. Das zu verwendende Verfahren zur Prüfung der Passwörter kann im User-Create Statement angegeben und so für verschiedene Benutzer innerhalb eines Systems unterschiedlich sein.
Ein Beispiel:

CREATE USER 'netwaysuser'@'netwayshost' IDENTIFIED WITH net_openldap_plugin;

Das oben geschilderte Beispiel wird bei Anmeldung des Benutzers netwaysusers versuchen, dessen Kennwort mit Hilfe des Plugins net_openldap_plugin zu verifizieren.
Um ein Plugin zu verwenden muss dieses zuvor in der Datenbankkonfiguration (my.cnf) bekanntgemacht gemacht werden oder dynamische geladen werden.
Beispiel eines statischen my.cnf-Eintrags:

[mysqld]
plugin-load=net_openldap_plugin=net_openldap_plugin.so

Beispiel der dynamischen Aktivierung zur Laufzeit:

INSTALL PLUGIN net_openldap_plugin SONAME 'net_openldap_plugin.so';

Mit dem Befehl show plugins, kann die erfolgreiche Ladung anschließend gleich validiert werden. Wichtig ist hier noch die Prüfung der Variable plugin_dir um sicherzustellen, dass das angegebene Modul aus diesem Pfad auch geladen werden kann. Aktuell werden mit Plugins mitgeliefert, welche beispielsweise die Verifizierung auf Basis einer Unixkennung ermöglichen. Plugin laden und einfach “… IDENTIFIED BY auth_socket;” an das CREATE USER – Statement anfügen, fertig . Weitere Plugins werden mit Sicherheit folgen.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.

MySQL New Features – Background I/O Threads

Vor knapp zwei Wochen hatte ich die MySQL New Features Serie mit dem Thema Semisynchronous Replication gestartet. Als eines der Features, welches auch ohne tief gehendes Verständnis der Datenbankarchitektur in vielen Umgebungen Verwendung finden kann, bereits eine echte Bereicherung.
Gerade unter der Haube im Bereich der Storage-Engines und vor allem InnoDB ist viel passiert. In den letzten Jahren musste sich MySQL immer wieder den Vorwurf gefallen lassen, aktuelle Hardware nicht ausreichend auszulasten und gerade im SMP-Bereich hinter alternativen Datenbank zurückzufallen. Einem besonderen Kritikpunkt hat sich SUN/Oracle ebenfalls in der Version 5.5 angenommen.
Gemeint sind hier die so genannten Background I/O Threads, welche für die Verarbeitung von Prefetches und dem Schreiben von Dirty Pages verantwortlich sind. Für das Prefetching kennt MySQL grundsätzlich zwei Entscheidungsregeln. Einmal das Vorablesen von Blöcken bei Identifizierung eines sequentiellen Lesevorgangs oder der überdurchschnittlicher Leserate in bestimmten Speicherblöcken und somit vorsorglicher Leseverarbeitung der beteiligten Blöcke. In den bisherigen MySQL-Versionen gab es hierfür genau einen Thread, der aktuelle Serverhardware und vorallem Speichersubsysteme nicht wirklich vollständig auslasten konnte. Hierfür gibt es seit Version 5.5 nun den Parameter innodb_read_io_threads, der eine dynamische Konfiguration der Read-Threads und somit optimierte Auslastung des Plattensubsystems ermöglicht.
In die andere Richtung, nämlich dem Schreiben von veränderten Datenblöcken aus dem Buffer-Cache auf die Disk ist ebenfalls die Möglichkeit zum Feintuning, hier innodb_write_io_threads entstanden. Bei modernen RAID-Controllern wird das Tuning der read_io_threads vermutlich den größeren Erfolg versprechen, da Schreibvorgänge häufig schon im Cache der Controller acknowledged und somit als abgeschlossen markiert werden.
Beide Parameter bedürfen im Praxisbetrieb genauer Beobachtung und können bei Überstrapazierung auch zu steigendem I/O-Waits auf den Disks führen. Wie immer bei Tuning gilt auch hier der Grundsatz nicht alle Schrauben gleichzeitig zu drehen, sondern verschiedene Kombinationen über die Zeit zu nutzen und die gewonnenen Ergebnisse zu dokumentieren und vergleichen.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.

MySQL New Features – Semisynchronous Replication

Bereits seit dem 15. Dezember gibt es die aktuelle GA Release von MySQL in der Version 5.5. Obwohl ein großer Nutzerkreis der Datenbank, nach Installation und Anlage von Benutzern, häufig keine größere Aufmerksamkeit zukommen lässt, lohnt es sich durchaus einen genaueren Blick auf die neuen Features zu werfen. In den nächsten Woche werde ich die aus meiner Sicht wichtigsten Themen zusammenfassen und Euch zum Wochenende damit beglücken.
Starten möchte ich die Serie mit einer kleinen Einführung in die Semisynchronous Replication. Dieses von vielen lang erwartete Feature löst den bisher nicht vorhandenen Transaktionskontext über verteilte Replikationsumgebungen nun endlich auf. Aber was heisst das nun genau?
In einer normalen (synchronen) Replikationsumgebung schreibt die Master-DB alle Änderungen in lokale Binlogs und schert sich nicht über die weitere Bearbeitung durch einen oder mehrer Slaves. Diese Entkopplung zwischen Spooling der Änderungsdaten und spätere Einarbeitung in den Slaves bietet zwar einen Performancevorteil, kann bei Ausfall des Masters im weiteren Verlauf jedoch den Verlust von Daten zur Folge haben.
Wenn in einer Datenbankumgebung transaktionsorientiert gearbeitet wird, also mit autocommit=0 oder Initierung durch den Befehl start transaction, hat dies zur Folge, dass erst nach dem nächsten Commit die Daten für alle anderen Benutzer sichtbar geschrieben werden. Voraussetzung hierfür ist der Einsatz von InnoDB, welche seit Version 5.5 auch Standard-Engine, und die  ACID-Kriterien erfüllt. Sobald der Benutzer den Commit abgesetzt hat, werden die Daten geschrieben und für das lokale System ist die Integrität hergestellt. Was aber wenn ein angeschlossener DB-Slave die Daten noch nicht eingearbeitet hat und es nun zu einem Ausfall des Masters kommt? Genau hier setzt die Semisynchronous Replication an. Bei Aktivierung, welcher für Master und Slave erforderlich ist, bekommt der Benutzer erst dann einen Status “committed” wenn die Transaktion auf mindestens einem Slave eingearbeitet ist. So kann auch in verteilten Umgebungen die Integrität auf mindestens einem weiteren Knoten sichergestellt werden. Bei Ausfall aller Slaves springt die Datenbank nach einem gewissen Timeout in die normale (synchrone) Replikation zurück und stellt so trotzdem die Verfügbarkeit sicher. Sobald wieder ein Slave verfügbar ist, wird natürlich wieder die Semisynchronous Replication verwendet. Über einige neue Servervariablen kann der Admin auch die entsprechenden Transaktionen im System sichtbar machen. So gibt die Variable Rpl_semi_sync_master_no_tx beispielsweise Auskunft über noch offene Transaktionen, welche noch nicht auf einem Slave committed wurden.
Für alle, denen eine replikationsübergreifende Transaktionssicherheit wichtig ist, ist dieses Feature ein Muss.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.

Nagios 3 New Features – Serie

In den vergangenen Wochen haben wir immer wieder einige Neuerungen von Nagios 3 vorgestellt und sind in kurz Beispielen darauf eingegangen. Nachfolgend haben wir nochmals die vergangenen Posts zusammengestellt um einen Überblick über die aus unserer Sicht wichtigsten Features zu geben.

Selbstverständlich gab es darüber hinaus noch eine Vielzahl an Änderungen und Erweiterungen. Eine vollständige Liste findet ihr auf nagios.org. Gerne stehen wir natürlich für weitere Fragen zu Nagios zur Verfügung. Entweder via Kommentar oder vielen anderen Möglichkeiten welche unserer Site zu entnehmen sind.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.

Nagios 3 New Features – Custom Object Variables

Bei Nagios wurde immer wieder die Möglichkeit vermisst, eigene Informationen an Objekte wie Host und Services zu binden und so zusätzliche Angaben wie SNMP-Community oder ICQ-Number zu speichern. Auch Standortangaben wie Rackplatz und ggf. Serverraum sind immer wieder von Bedeutung.
Mit Nagios 3 haben Administratoren genau diese Möglichkeit indem Sie den entsprechenden Variablen bei Host-, Service und Contakt-Definition ein “_” voranstellen.
So könnte eine Hostdefinition dann aussehen:

define host{
   host_name	netways_server
   _dc_name	RZ1; Angabe des Rechenzentrums
   _dc_rackr	R104;	 Angabe des Racks
   }

Die entsprechenden Variablen werden über Templates bei Bedarf auch vererbt und können mit Hilfe von Macros in anderen Scripts verwendet werden. Eine detaillierte Auskunft gibts in der offiziellen Doku.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.