Even Nagios installeren en inrichten...

  • warning: fsockopen(): php_network_getaddresses: getaddrinfo failed: No address associated with hostname in /home/timterbe/domains/timterbeest.nl/public_html/sites/all/modules/weather/weather.module on line 2092.
  • warning: fsockopen(): unable to connect to weather.noaa.gov:80 (php_network_getaddresses: getaddrinfo failed: No address associated with hostname) in /home/timterbe/domains/timterbeest.nl/public_html/sites/all/modules/weather/weather.module on line 2092.
  • De download locatie met METAR gegevens is onbereikbaar.
  • strict warning: Non-static method view::load() should not be called statically in /home/timterbe/domains/timterbeest.nl/public_html/sites/all/modules/views/views.module on line 842.
  • strict warning: Declaration of views_handler_argument::init() should be compatible with views_handler::init(&$view, $options) in /home/timterbe/domains/timterbeest.nl/public_html/sites/all/modules/views/handlers/views_handler_argument.inc on line 745.
  • strict warning: Declaration of views_handler_filter::options_validate() should be compatible with views_handler::options_validate($form, &$form_state) in /home/timterbe/domains/timterbeest.nl/public_html/sites/all/modules/views/handlers/views_handler_filter.inc on line 589.
  • strict warning: Declaration of views_handler_filter::options_submit() should be compatible with views_handler::options_submit($form, &$form_state) in /home/timterbe/domains/timterbeest.nl/public_html/sites/all/modules/views/handlers/views_handler_filter.inc on line 589.
  • strict warning: Declaration of views_handler_filter_boolean_operator::value_validate() should be compatible with views_handler_filter::value_validate($form, &$form_state) in /home/timterbe/domains/timterbeest.nl/public_html/sites/all/modules/views/handlers/views_handler_filter_boolean_operator.inc on line 149.
  • strict warning: Declaration of views_plugin_row::options_validate() should be compatible with views_plugin::options_validate(&$form, &$form_state) in /home/timterbe/domains/timterbeest.nl/public_html/sites/all/modules/views/plugins/views_plugin_row.inc on line 135.
  • strict warning: Declaration of views_plugin_row::options_submit() should be compatible with views_plugin::options_submit(&$form, &$form_state) in /home/timterbe/domains/timterbeest.nl/public_html/sites/all/modules/views/plugins/views_plugin_row.inc on line 135.

Een klant wilde graag dat zijn server gemonitord wordt. Ook is het de bedoeling dat toekomstige (virtuele) servers van ons zelf makkelijk aan een monitoringserver "gehangen" kan worden, dus een goede reden om een virtuele server in te richten met Nagios. Kostte alleen iets meer tijd dan ik verwacht had...

Om te beginnen eerst iets over onze setup: wij hebben 1 dedicated server in een datacenter hangen. Hierop draaien een aantal virtuele machines (Xen).

Om bij het begin te beginnen... Eerst heb ik met Xen een nieuwe virtuele machine aangemaakt. Deze draaide op Ubuntu Gutsy, omdat nieuwere images nog niet op onze server staan (of niet goed werkten). Hier beognnen de problemen, ik had namelijk geen netwerk vanaf deze VM... Na een tijd troubleshooten bleek dat er nog een (door Xen) aangemaakte route in de routetabel was blijven staan... Nadat ik deze had verwijderd kon ik pingen en via SSH bij de VM komen, wat een stuk fijner werkt dan de Xen console.

Afijn de VM voor (in de toekomst) diverse beheertaken liep eindelijk prima, dus dacht gelijk maar even upgraden naar Intrepid. En hier begonnen de problemen... Bij de upgrade kreeg ik gelijk deze fout:
E: Internal Error, Could not perform immediate configuration (2) on libc6
Helaas weinig zinvols hierover kunnen vinden. Daarom heb ik toen maar besloten om eerst naar Hardy te upgraden en later dit probleem uit te zoeken. Gelukkig ging deze upgrade wel goed.

Nou het belangrijkste, Nagios... :)
Ik heb eerst maar even de configuratie doorgelopen van onze eigen server, waar nu alle snog op draait (websites, mail, databases e.d.). Kwam erachter dat deze nog de gateway van ons vorige datacenter monitorde, oops! Gelijk maar even verholpen :). Verklaart ook waarom ik zo nu en dan mails kreeg dat de gateway eruit zou liggen, terwijl alles gewoon functioneerde. Af en toe is 't zo simpel! :D

Omdat ik wil dat er specifieke zaken gemeten moete kunnen worden (bijvoorbeeld de load van de server) moest ik met de nrpe-plugin van Nagios aan de slag. Op de server van de klant nagios-nrpe-server geïnstalleerd en op de beheerserver nagios-nrpe-plugin. Natuurlijk zou 't te mooi zijn als het nu ook zou werken, maar dat deed het dus niet.

Vanaf de beheerserver via de commandline getest en hier kreeg ik steeds een foutmelding. Telnetten naar poort 5666 dan (poortje die Nagios geopend zou moeten hebben) werkte niet vanaf de beheerserver, wel vanaf de server van de klant en vanaf mijn eigen PC thuis. Nagios heeft dus in iedergeval de poort open staan. Na een tijdje troubleshooten kwam ik erachter dat als ik een traceroute deed naar de server van de klant vanaf de beheerserver hij naar een verkeerd IP ging. Toen /etc/hosts maar even bekeken. En toen viel gelijk mijn kwartje, Xen vind het blijkbaar leuk om zowel op de Xenhost zelf als op alle nieuw aan te maken Xen VM's de aangemaakte hostnamen + IP-adressen in de host-file vast te leggen. Ja en eerder had ik het IP-adres wat nu de klant gebruikt al is voor iets anders gebruikt... GRRR! Dus overal deze regels heel snel uit de hosts-file verwijderd en hierna deed de commandline check van Nagios 't als een trein! Nou dacht ik, heel optimistisch, dan werkt het nu ook als ik het in de Nagios config-files gooi en 't zaakje start. Helaas... Na een paar minuten kreeg ik al mail met als onderwerp: Disk Space is unknown.

Goed, dan maar weer googlen. Overal stond dat ik op de server van de klant bijv. deze regels moet gebruiken:
command[check_sda2]=/usr/lib/nagios/plugins/check_disk -w 20 -c 10 -p /dev/sda2
Op de beheerserver hoorde daar dan dit blok bij:
define service{
use generic-service ; Name of service template to use
host_name
service_description Disk Space
check_command check_nrpe!check_sda2
}

Dit werkte dus niet.. Daarom heb ik zelf toen maar even de diverse scripts en definitiefiles van de nrpe-service bekeken. Wat beel, was er ook een functie check_nrpe_1arg. Die laatste 3 letters was toen precies wat ik dacht :). Wat zou goede documentatie soms toch handig zijn...!
Blokje als volgt aangepast:
define service{
use generic-service ; Name of service template to use
host_name
service_description Disk Space
check_command check_nrpe_1arg!check_sda2
}
Nagios gestart en 't werkte zowaar!

Daarna voor elke te checken service een command op de te monitoren server aangemaakt, blokje als hierboven op de eigen beheerserver aangemaakt en 't werkt.

Weer veel bijgeleerd over Xen en Nagios :).

Reacties

NewMessage