Die totale Ueberwachung wuenscht im reellen Leben niemand aber in der Cloud um so mehr. Ein vollautomatisches Monitoring fuer seine virtuellen Maschinen waere schon schick. Es wurden dazu auch Unmengen von Tools gebaut und Projekte geschaffen. Ganze Firmen haben ihr Geschaeftsmodell darauf ausgerichtet. Schlussendlich, bei all der ganzen Toolfrage, landet man erstaunlicherweise wieder bei Nagios.
Als erstes gibts da ein paar Ideen:
Die Idee ist also, wir verwalten unsere Maschinen mit Puppet und haben Nagios als Basiselement fuer ein Monitoring und konfigurieren optimalerweise zu jedem definierten Service auch den Monitor (und zum Beispiel auch die Firewallregeln aus einem Firewall-Modul). Weitere Zutaten fuer die Suppe waeren Grundparameter zum Monitoring (also Erreichbarkeit, CPU, Memory, Diskspace) und grundlaufende Prozesse wie sshd, cron, ntpd usw. Fuer letzteres waere so ein Autodiscovery nicht schlecht. Schauen wir mal, was man daraus machen kann.
Unser Puppet Module zerfaellt in mehrere Teile.
Teil 1 und 3 sind relativ einfach. Wir benutzen Puppet einfach als Filestore, der die verschiedenen Dateien wie HTML-Dateien, Bilder und statische Konfigurationsdateien vorhaelt und auf den definierten Host kopiert. Dazu werden notwendige Programmpakete installiert und die Services ueberwacht und ggf. gestartet, fertig.
In Teil 2 brauchen wir die Interaktion, die Puppet ueber exportierte Resourcen bereitstellt. Das bedeutet, dass die einzelnen Nodes bestimmte Resourcen anderen Hosts zur Verfuegung stehen. Typischerweise ist dies der Puppetmaster-Host, der diese Informationen in der PuppetDB speichert. Die PuppetDB ist zwingend erforderlich, kann aber natuerlich auch woanders laufen:
/etc/puppet/puppet.conf:
storeconfigs = true
storeconfigs_backend = puppetdb
/etc/puppet/puppetdb.conf
[main]
server = wingui.dsl.eumel.local
port = 8081
Zur Installation der PuppetDB und dem Puppetmaster sei auf die einschlaegige Dokumentation verwiesen. Im Puppet sind schon diverse Resourcen enthalten, zum Beispiel
# puppet resource package
package { 'ConsoleKit':
ensure => '0.4.5-6.2.2',
}
package { 'SuSEfirewall2':
ensure => '3.6.282-1.1.1',
}
package { 'aaa_base':
ensure => '12.1-533.1',
}
package { 'aaa_base-extras':
ensure => '12.1-533.1',
}
...
<
Hier ist dann auch klar, wenn in der package-Definition eines Rezepts "latest" drinsteht, dass Puppet einfach die Nummern vergleicht und immer das Paket mit der groessten Nummer installieren wird. Aber Resourcen und Resourcentypen kann man beliebig erweitern, um sie zum Beipspiel als "fact" in einem Rezept weiterverwenden zu koennen. Fuer Nagios ist eine Erweiertung aber gar nicht notwendig, da das schlauerweise in Puppet mit eingebaut worden ist. Naginator ist ein Provider fuer Puppet, der Host- und Service-Defintionen bereitstellt. Die Resourcen kann man sich zum Beispiel mit
# puppet resource nagios_host
nagios_host { 'kifaru.eumelnet.de':
ensure => 'present',
address => '62.141.42.223',
alias => 'kifaru',
target => '/etc/nagios/nagios_host.cfg',
use => 'cloud-host',
}
nagios_host { 'www.eumel.de':
ensure => 'present',
address => '62.141.43.200',
alias => 'uucp',
target => '/etc/nagios/nagios_host.cfg',
use => 'cloud-host',
}
ansehen. In der Node-Defintion saehe das so aus, um zum Beispiel einen Host zum Monitoren als exportierte Resource hinzuzufuegen:
@@nagios_host {'www.eumel.de':
use => 'cloud-host',
address => '62.141.43.200',
host_name => 'www.eumel.de',
alias => 'www.eumel.de',
}
Im Module werden alle exportierten Resourcen einer Sorte zusammengefuegt und letztlich in ein Stueck Nagios-Konfigurations-Datei reingeschrieben:
# collect resources and populate /etc/nagios/nagios_*'cfg
Nagios_host <<||>> {
target => "/etc/$target/nagios_host.cfg",
notify => Service['nagios']
}
Also immer und immer wieder, falls sich eine Resource aendert. Somit ist die Konfigurationsdatei nicht mehr wichtig sondern vielmehr die Definition zum Erstellen derselben im Puppet.
Weiter oben beschrieb ich aber auch, dass Resourcen beliebig erweitert werden koennen fuer Facts. Facts kann man sich anschauen zum Beispiel mit:
# facter -p ipaddress
62.141.42.223
Die Erweiterung findet statt in dem selbst definierten Fact nagios_ext_services
# facter -p nagios_ext_services
define service {
use cloud-service
host_name kifaru.eumelnet.de
service_description Proc amavisd
check_command check_nrpe_1arg!check_amavisd
}
define service {
use cloud-service
host_name kifaru.eumelnet.de
service_description Proc anvil
check_command check_nrpe_1arg!check_anvil
}
...
Die Nagios-Checks werden generiert aus der Datei "/etc/nagios/nagios_ext_services.cfg", die durch das Programm "/usr/local/bin/collect_checks.pl" auf dem Node erstellt werden.
Eine Defintion fuer den Nagios-Server sieht im Manifest ungefaehr so aus:
class {'nagios::server':
engine => 'icinga',
http_users => {
admin => { 'password' => '$apr1$x6DQznUt$hh05hGiXnBzfi4m0iKlty1' },
},
twilio_account => 'Adw3d01c3757bbdwdww74d0adwdw48a88e',
twilio_identifier => '5fa5d3f4ff248b7c8e4dsds2d5d8',
twilio_from => '%2B18482425771',
twilio_to => '%2B4917212345670',
}
Twilio ist ein SMS-/Voice-Call-Dienst, der ueber eine API-Schnittstelle verfuegt, also hervorragend geeignet fuer unsere Nagios-Notifizierung.
Tja, und letztlich, unser Nagios ist gar kein Nagios sondern Icinga. Dieses und andere Ueberraschungen gibt es im Nagios-Puppet-Module auf https://github.com/eumel8/nagios