Nagios - ESX monitorozas

Nem egy egszerű eset az ESX monitorozása Nagios alól. A legtöbb közösségi plugin vagy már elavult API-ra épít, vagy egyszerűen csak nem működik, illetve volt olyan is, ami működött ugyan, csak épp nem tudom, mit figyelt.

Szóval, belevágtam egy olyan script írásába, mely képes a számomra érdekes információkat monitorozni az ESX-ben. Ezek elsősorban a memória információk, illetve a datastore-k telítettsége. Szerencsémre a libvirt könnyedén képes kapcsolódni az ESX szerverhez, és van Ruby bindingje is, így a kérdéses információkat elő lehetett keresni vele.

Némi kísérletezést követően megszületett a plugin. A cikk alján ott van, hogy honnét lehet leszedni.

A script jelenleg nincs tesztelve vSphere környezetben, mivel ilyenhez hozzáférésem jelenleg nincs, és pillanatnyilag az a gépem, amit ilyenre fel tudnék használni, nincs használható állapotban. Természetesen, ha valaki úgy gondolja, hogy hozzájárulna a projekthez egy olyan teszt vSphere rendszerrel, mellyel lehet kísérletezni, akkor megnézem, hogy mi lehet szükséges a dologhoz.

A projekt a nálam szokásos CreativeCommons licenc alatt került publikálásra, annak is a BY-SA 3.0 változata alatt.

Letöltés és telepítési instrukciók: https://github.com/hron84/check_esx

( NagyZ v | 2012. 02. 17., p – 14:16 )

miert a libvirten keresztul dolgozol ESXi/vSphere-el? van neki sajat, hasznalhato WS APIja.

Elsosorban azert, mert ahhoz nem talaltam hivatalos Ruby bindinget. Mivel a WS API-t folyamatosan fejlesztik, nem szeretnek abba beleszaladni, hogy hirtelen nem mukodove valik az az API hivas, amit egy community altal (nem) menedzselt binding hasznal. A libvirt-et folyamatosan fejlesztik, a hozza tartozo binding is ugyanonnan jon, szoval egy kicsit - de csak egy kicsit - nagyobb biztonsagban van a plugin.

Rengeteg olyan WS API-t hasznalo Nagios pluginba szaladtam bele, ami mar tobbmillio eve deprecated API-kat hasznalt.

Hab a tortan, hogy ezt a plugint kesobb at tudom dolgozni Xen/KVM monitorozasra is, minimalis modositassal.

Es hogy miert ruby? Mert volt egy problema, ami miatt megirtam ezt a plugint, es ebben volt a leggyorsabb, mert ebben van aktiv tudasom. Megirhattam volna eppen Pythonban is, csak sokkal tovabb tartott volna.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

1, nem kedeztem, hogy miert ruby, tudom, hogy ebben bontogatod a szarnyaid
2, ha a ruby nem tud _standard_ SOAP WS -eket kezelni, az szegyen lenne, szerintem 99.9%, hogy tud :)
3, mivel a vmware API ilyen, igy a "nem volt binding" duma nem helytallo
4, a vmware kenyes nagyon az API valtozasra, a deprecated APIkat benthagyja, meg az 5 eves kod is mukodik az WS API-val, tehat
e miatt biztos, hogy nem lesz olyan, hogy valtoztatnak valamit, es nem fog menni.
5, a libvirt a vmware API toredeket (<10%, de szerintem <5%) tudja

a Xen-es dologban igazad van, a libvirten keresztul tenyleg lehet mindent egyszerre monitorozni, csak ha vSphere -t akarnek monitorozni, akkor igy biztos, hogy nem ezt valasztanam. sajat hobbira persze jo, de akkor mar erdemes profin megirni, IMHO.

Tudom, hogy tud SOAP WS-eket, de ezeket a monitorozo izeket CIM/WBEM-mel irtak meg, mivel nem ismerem a SOAP API-t, gondoltam nyilvan azert, mert abban lehetett ilyet. Sajnos pont ebben az API-ban egy csomo minden nem mukodott, tobbek kozott az, ami nekem kritikus volt, a datastore monitoring.

A Ruby tud SOAP API-t kezelni, csak epp semmi ertelmes wrappert, egyebet nem talaltam VMware-hez, nullarol megirni egy ilyet meg azert valljuk be, munkas, legalabbis egy kesz cucc felhasznalasahoz kepest munkasabb. Ha egyszer sok idom lesz, es jut a taszklistamban ilyesmire is, mindenkeppen szeretnek megismerkedni a VMware API-javal, foleg mert Rubyban ez elegge hianyteruletnek szamit. Illetve azert, mert majd szuksegem is lesz ra. De ez nem az a projekt volt.

Ez a script egy este + egy delelott munkaja, igy tessek hozzaallni. Nekem jo, megosztottam, hatha masnak is jo lesz tole.

Tenyleg no offense, es koszonom a kritikat.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Mert rubyra meg nem talaltam olyan WSDL->kod generalot, ami ertelmes kodot lett volna kepes kiadni magabol, borzaszto idiota nevu classok jonnek ki az ilyenbol. Aztan van olyan is, ami siman csak elhanyja magat egynemely WSDL-tol. Majd utananezek, itt mi a helyzet.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

En a maven fele tortenetre gondoltam, az fogja, gyart egy gen mappat, es oda vagdos be mindent, ami nem userinputbol szarmazott vala.

Nem tudom, lehet, hogy azota valtozott a vilag, mint amikor utoljara neztem (feleve? egy?), de nekem volt egy olyan kinlodasom, hogy volt egy egymetodusos WSDL-em (_Dispatch, mar ez maga egy iszonyu megoldas...), es valami horror jott ki a konverzio utan. Utana fogtam, szepen beincludoltam a libet, es meggyartottam en magam azt a ruhes egy metodust, mert sokkal egyszerubb volt, mint azzal a borzalommal dolgozni. Es meg tudtam logikat is tenni bele, jol (megcsinaltam azokat a cuccokat, amiket a _Dispatch hivogatott a kabel tuloldalan). De amennyit ertek hozza, ez meg akar a WSDL hibaja is lehetett, mindenesetre en azota egy pottyet felek ezektol Ruby alatt.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Te, lehet am, hogy szar volt a WSDL-em. Megnezegettem ugyan, de en csak annyit ertettem belole, hogy egy bazinagy XML fajl. Viszont tudtam, hogy milyen metodust milyen szintaxissal kell hivni (a dokumentacio jobb volt), es addig erolkodtem, mig sikerult megertetnem ezt a proxyval is. Lehet, hogy mukodott volna az a kod is, amit a generator tolt ki magabol, csak nem lattam benne a lehetoseget. Illetve folyamatosan nyuglodott is, mert valamiert baromira nem akarta szeretni a hasheket, nekem pedig ilyet kellett atpasszirozni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal