Das Thema Monitoring habe ich hier ja schon in einigen Postings erläutert. Ich möchte nun eine sehr interessante Variante eines Monitoringsystems vorstellen, die ich mir am Wochenende angeschaut habe.

Warum überhaupt eine neue Lösung?
Ich wollte meine Nagiosspielwiese schon seit Monaten auf OracleLinux6 neu bauen, hatte aber noch immer nicht die ultimative Lösung, wie ich das mit möglichst wenig Aufwand machen kann. Das Ziel sollte sein, eine Umgebung mit möglichst wenig Anpassungen zu bauen, die darüber hinaus auch einfach zu aktualisieren ist.

Altsystem:
Meine derzeitige Umgebung ist komplett selbst gebaut und kompiliert, da es vor 1,5 Jahren noch nicht die benötigen RPMs gab bzw. die Versionen zu alt waren. Ich habe folgende Komponenten gebaut:
- Nagios Core
- PNP4Nagios
- NagiosQL
- Thruk
- Livestatus
- check_nrpe

Das ist eine nicht zu unterschätzende Liste, wobei einige Komponenten sehr einfach zu bauen sind, da lediglich ein tar.gz entpackt und ein paar Dateien konfiguriert werden müssen. Technisch interessant vom Pflegeaufwand aber nicht so toll.

Geht es besser?
Ja, es geht mittlerweile sehr einfach und genau das habe ich mal probiert:
Man nehme OMD (Open Monitoring Distribution) und installiere diese auf OracleLinux6 als RPM.

wget -O - http://labs.consol.de/OMD/rh6/stable/omd.repo > /etc/yum.repos.d/omd.repo
yum search omd-

Nun das aktuelle Package von OMD installieren und warten bis fertig. Die notwendigen Abhängigkeiten werden aufgelöst, so das Du am Ende ein lauffähiges OMD hast. Der Apache muß noch aktiviert werden, da sonst nach nem Reboot die Weboberfläche nicht funktioniert.

Dann bekommt man fertig konfiguriert folgende Komponenten:

nagios
nagios-plugins
nsca
check_nrpe
Icinga
Shinken
nagvis
pnp4nagios
rrdtool/rrdcached
Check_MK
MK Livestatus
Multisite
dokuwiki
Thruk
Mod-Gearman
check_logfiles
check_oracle_health
check_mysql_health
jmx4perl
check_webinject
check_multi

Die Liste ist schon krank aber wirklich genial an dem System ist, das man nur das OS installieren muß, das RPM drauf packt und alle Komponenten sind zusammen installiert und miteinander konfiguriert. Den letzten Punkt konnte ich erst nicht glauben und habe es daher mal ausprobiert und kann bestätigen das es funktioniert. Ich habe nicht alles probiert, da ich mich vorerst mit Komponenten beschäftigen möchte, die mir bekannt sind.
Ich habe mir bisher folgendes angeschaut, die 'out of the box' funktionierten:
- Nagios Core
- pnp4nagios
- Check_MK
- Multisite
- Thruk
- MK Livestatus

=> Das ist alles was man so braucht. 🙂

Das hat mich sehr beeindruckt, da ein RPM + 2 Befehle für OMD zu einer lauffähigen Umgebung geführt haben.
check_mk rundet das ganze richtig toll ab, weil check_mk ein Agent auf dem zu überwachenden System mit bringt, der die zu konfigurierenden Services in Nagios automatisch generiert. (Das hatte mich früher abgeschreckt, weil ich hier starke Einschränkungen in der Flexibilität befürchtet habe, die sich jedoch nicht bestätigt haben.)
Man kann mit dieser Konfiguration innerhalb von Minuten zahlreiche Systeme in ein Nagios-Monitoring bringen, weil der Agent lediglich xinetd + Python auf dem zu überwachenden System benötigt. Der Agent ist so gebaut, das er problemlos mit Shell-Skript o.ä. erweitert werden kann.

check_mk und NRPE
Das ist schon eingebaut. Man kann bestehende Nagios-Plugins die für NRPE gebaut wurden in den Agenten von check_mk integrieren - also beliebig erweitern. Auch das war im Test sehr einfach. Analog zur nrpe.cfg muss man eine /etc/check_mk/mrpe.cfg erzeugen, die Einträge im passenden Format für check_mk eintragen und speichern.
Nun auf dem OMD den Client neu inventarisieren, die Konfig in Nagios übernehmen und der Check ist als Passivecheck eingebunden. (Erneute Verwunderung wie einfach das sein kann...)
Das hat aber einen Nachteil. check_mk inventarisiert die Checks automatisch aber sie müssen auf dem Agenthost konfiguriert werden, was beim alten NRPE aber ebenfalls notwendig war.

Wichtig ist. Es können alle bekannten Plugins von Nagios in check_mk eingebunden werden und das bei genauer Betrachtung mit weniger Aufwand als beim klassischen NRPE.

Ist OMD ernst zu nehmen?
Definitiv ja, da zahlreiche bekannte Personen hinter dem Projekt stehen. Mathias Kettner bietet eine kommerzielle Lösung von OMD an, die sich von der frei verfügbaren Lösung im Funktionsumfang kaum unterscheidet. Man bekommt dort auf Wunsch einen kommerziellen Support für OMD.
Es gibt eine wirklich große verteilte Installation die zeigt, was OMD kann:
http://mathias-kettner.de/check_mk_success_edeka.html

Fazit:
Nagios kann man so innerhalb von Minuten in lauffähiger Form bekommen. Einfach zu konfigurieren, Updates von OMD sind im Konzept von Grund auf eingeplant und man kann mehrere Nagioskonfigurationen parallel betreiben.
Den letzten Punkt finde ich besonderst lustig. Einfach mal eine neue Nagioskonfiguration auf dem bestehenden System aufsetzen, testen und bei Bedarf wieder weg werfen. Man kann auch eine bestehende Konfiguration kopieren, ändern oder auf einen neue Version von OMD bringen und bei Bedarf dann wieder entsorgen.
Hier braucht man zum Spielen keine 2 getrennten Systeme mehr, da man alles mit 1 System machen kannst und der Updatemodus ist halt von Haus aus vorgesehen, worauf die Entwickler gezielt geachtet haben.
check_mk ist so gewaltig, das ich die Möglichkeiten noch nicht alle verstanden habe. Das was ich bisher gesehen habe hat mich aber sehr überzeugt - ich werde definiiv auf OMD umsteigen und bin gerade dabei meinen heimischen Nagioshost von Grund auf neu zu bauen.

Der Verzicht auf NagiosQL als Administrationsfrontend ist mittlerweile zu verschmerzen, da es mit den neuen Versionen von Thruk oder der GUI von check_mk möglich ist, diesen Punkt zu ersetzen. Das war zum damaligen Bauzeitpunkt der Altumgebung noch nicht der Fall.

Gruß
Thorsten

Enable CPU-Hot Plug and RAM-Hot Add at Virtual machines on VMware vCenter 5

Update 12.02.2013 / Gabrie post in the comments a important extra info about Hot-Add and post the link to the blog from Duncan Eppinghttp://www.yellow-bricks.com/2012/01/16/enabling-hot-add-by-default-cc-gabvirtualworld/ it's important to read this!!!

vSphere Virtual Machine Administration, Chapter 8 “Configuring Virtual Machines”, Section “Change CPU Hot Plug Settings in the … Client”, page 94.

cpu-and-ram-hot-add

Some conditions and requirements for CPU Hot Plug

To enable new CPU after adding a new CPU. You can use this script:

Hot add cpu to supported Linux guestOS

#!/bin/bash
# William Lam
# http://engineering.ucsb.edu/~duonglt/vmware/
# hot-add cpu to LINUX system using vSphere ESX(i) 4.0
# 08/09/2009

for CPU in $(ls /sys/devices/system/cpu/ | grep cpu | grep -v idle)
do
CPU_DIR="/sys/devices/system/cpu/${CPU}"
echo "Found cpu: "${CPU_DIR}" ..."
CPU_STATE_FILE="${CPU_DIR}/online"
if [ -f "${CPU_STATE_FILE}" ]; then
STATE=$(cat "${CPU_STATE_FILE}" | grep 1)
if [ "${STATE}" == "1" ]; then
echo -e "t${CPU} already online"
else
echo -e "t${CPU} is new cpu, onlining cpu ..."
echo 1 > "${CPU_STATE_FILE}"
fi
else
echo -e "t${CPU} already configured prior to hot-add"
fi
done

Hot adding memory in Linux

ONLY for Suse Linux Enterprise Linux 11

Note: These instructions work for SLES OS. Other distributions may be different.

To enable acpi_memhotplug, run this command within the SLES virtual machine:

modprobe acpi_memhotplug

Using vSphere Client, edit the virtual machine settings to increase the memory assigned to the virtual machine. For more information, see Increasing the amount of memory assigned to a virtual machine (1004059).

Bring the memory online in /sys/devices/system/memory with the command:

echo online > /sys/devices/system/memory/memory[number]/state

Run this command to check the state of the memory, looking for memory that appears offline:

grep line /sys/devices/system/memory/*/state

If memory appears as offline, set it to online with the command:

echo online > /sys/devices/system/memory/memory[number]/state

Verify that you can see the extra memory with the command:

free -m

Expert Mode: PowerCLI

This Works when System is online, but need one "cold" start to enable this function.

Enable-MemHotAdd and Enable-vCpuHotAdd

Function Enable-MemHotAdd($vm){
$vmview = Get-vm $vm | Get-View
$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec

$extra = New-Object VMware.Vim.optionvalue
$extra.Key="mem.hotadd"
$extra.Value="true"
$vmConfigSpec.extraconfig += $extra

$vmview.ReconfigVM($vmConfigSpec)
}
Function Enable-vCpuHotAdd($vm){
$vmview = Get-vm $vm | Get-View
$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec

$extra = New-Object VMware.Vim.optionvalue
$extra.Key="vcpu.hotadd"
$extra.Value="true"
$vmConfigSpec.extraconfig += $extra

$vmview.ReconfigVM($vmConfigSpec)
}

 

Good information about hot-add cpu and memory can found here

 

Das Monitoring einer OVM-Umgebung kann eine sportliche Aufgabe werden, wenn kein Cloud-Control zur Verfügung steht.
In meiner Spielwiese habe ich für Cloud-Control keine Resourcen und darüber hinaus muß der 'Basic Support' bestellt werden, wenn man im Cloud-Control die notwendigen Packs zum Überwachen nutzen möchte.

Gibt es eine Alternative?
Da ich mich schon seit Jahren mit Nagios beschäftige, ist für mich klar, das es Nagios zum Monitoring sein muß. Das schöne an Nagios ist das Plugin-Konzept, das eine sehr flexible Erweiterung ermöglicht und aufgrund einer breiten Basis an verfügbaren Plugins sehr flexibel einsetzbar ist.
Leider gab es bisher noch kein Plugin, um die SSHCLI von OVM3 abzufragen. Ich habe mit dem auf Nagios Exchange veröffentlichten Plugin diese Lücke geschlossen und wünsche allen viel Spaß damit.

Was braucht man für ein Monitoring mittels Nagios?
- Nagios Core
Den Daemon der für das Monitoring verantwortlich ist und je nach Konfiguration entsprechend Meldungen verschickt.
- NRPE oder NSCA
Ich bevorzuge den Nagios Remote Plugin Executor vor dem Nagios Service Check Acceptor. Beide Daemons haben aber ein großes Problem, wenn man sie auf einen OVM-Server installieren möchte. Oracle hat das Betriebssystem vom OVM-Server so stark reduziert, das ein Betrieb des NRPE zzgl. der Plugins in der Praxis kaum möglich ist. Darüber hinaus ist die Installation von zusätzlichen RPMs problematisch, da Oracle dafür keine Updates bereit stellt und hier unter Umständen der Supportpfad verlassen wird.

Reich das Plugin?
Bei genauer Berachtung reicht ein Plugin zur Abfrage der SSHCLI vom Manager definitiv nicht aus, da darüber keine Kernelmeldungen in Erfahrung zu bringen sind.
=> Wie soll man Fehler im Multipathing, OCFS2 etc. erkennen?

Die Lösung ist sehr einfach:
Ich biege den syslog der OVM-Server auf einen Syslogserver, den Nagios-Host oder den OVM-Manager um. Dort dann ein Monitoring mittels check_logfiles und eine umfangreiche Überwachung läßt sich mit sehr überschaubaren Mitteln bauen, ohne eine umfangreiches Framework wie Cloud Control zu benötigen. (In kleinen Umgebungen mit 1-2 OVM-Server und wnigen VMs lohnt sich der Aufwand für ein Cloud-Control nur, wenn es neben der OVM-Umgebung auch noch für weitere Zwecke genutzt wird...)

Ich habe meine heimische Spielwies umgebaut, so das der OVM-Server sein syslog an die Nagios-VM schickt und dort mittels check_logfiles überwacht wird. Parallel nutze ich check_ovm3, um den Status von virtuellen Maschinen sowie des Repositories zu überwachen. (Das Heine/Ei-Problem mit der Nagios-VM auf dem laufenden OVM-Server sei hier einfach mal ignoriert - es ist eine Spielwiese!)

(mehr …)

© 2011-2019 SJT CONSULTING – Alle Rechte vorbehalten. | Datenschutz | Impressum