SAMGARR: tak super :))

SAMGARR: ještě zápis toho commandu ideálně

HALELUJA: fstab neposlusnejch mountu - http://pastebin.com/puFQ7y1f, check plugin http://pastebin.com/rTApGw0m. Diky.

SAMGARR: ahoj, těžko říct.. hoď sem fstab a syntaxi toho checku a třeba něco vykoumáme :)

Zdar, mam problem s nagiosem, pomoci pluginu check_nfs_health kontroluju stav NFS mountpointu. U 4 mountpointu mi plugin hlasi "not mounted". Pritom jsou pripojene, system s nima normalne pracuje, netusite cim to muze byt? Logy nic zajimavyho neukazujou.

TLOUDEV: http://forums.cacti.net/viewtopic.php?t=8415
Hooray!

AQUARIUS: a propos: nejde to primo nejak v cacti, poskladat graf z nekolika datasources z vice hostu?

AQUARIUS: no vidis.. ja vedel ze nekoho napadne jednodussi cesta.
Ja tam samozrejme ty hodnoty mam. Akorat budu muset nasprtat rrd v perlu. A hlavne nekde definovat, kterych grafu se to tyka. Vlastne to ani nemusi byt integrovano v cacti, bude mi pak stacit viewgraph.cgi nebo jak se ten jejich blbinec jmenuje..

TLOUDEV: neni jednodussi si napsat skript, kterej ty hodnoty vytahne z jednotlivejch rrd databazi a pak to akorat hodi do jednoho grafu? vyhoda je, ze to budes rovnou mit i s historii.

Hi, jsem postaven pred nelehky ukol agregovat do cacti do jednoho grafu vstupy z vice stroju. Mam-li byt konkretni, jedna se o "secteni" vsech IO operaci vsech stroju, abych videl, zda nahrazeni storage jednotlivych stroju jednim centralnim ulozistem bude diskove operace stihat. Tedy v podstate "secteni" hodnot. V cacti jsou templates, jak znamo, delany pro jednotlive stroje. Tusite nekdo, jak si z takovou integraci poradit? Cely ukol je jednorazovy, tzn nemusi fubgovat univerzalne, genericky..
Moje idea do zacatku je, napsat check script, ktery vezme nejaky seznam stroju a jejich SNMP parametry (diskIOread, diskIOwrite), secte, pokud je k dispozici soubor s predeslou hodnotou, pak ji odecte a do rrd zapise rozdil, pokud neni, vrati 0 a ulozi hodnotu nekam do souboru.
Otazka do plena: neni nejaka jednodussi cesta ci jiz hotove reseni?

KRISHNA: nj ale to ovlivní všechny :/

AQUARIUS: odjel sem na dovču a vysral se na to, ale vypadá to, že to buď nejde a nebo jedině nějak v kombinaci s těmi eskalacemi

KRISHNA: když to je taky globální pro celej template. já to potřebuju jen pro ten jeden kontakt.. možná, že natvrdlost se mě furt drží :D

AQUARIUS: díky, jasně že jsem nerestartoval nrpe:-) už to běží, došlo mi to už včera asi hodinu poté..

RUDOLF: restartoval jsi nrpe po uprave tech konfiguraku? Co vidis v tcpdumpu?

ahoj, začínám s nagiosem

.. změnila se teď IP adresa nagios serveru:

intranet:/usr/lib/nagios/plugins # rcnagios status
Checking for nagios : running
Tj. nagios běží bez xinet.d


intranet:/usr/lib/nagios/plugins # ./check_nrpe -H localhost
Connection refused by host
intranet:/usr/lib/nagios/plugins # ./check_nrpe -H public
CHECK_NRPE: Error - Could not complete SSL handshake.

na nagios serveru jsem změnil IP tady:
intranet:/usr/lib/nagios/plugins # grep -r 10.3.0.28 /etc/
/etc/hosts:10.3.0.28 intranet intranet
/etc/nagios/objects/hosts.cfg: address 10.3.0.28

na remote jsem zmenil:
/etc/nagios/nrpe.cfg:allowed_hosts=***.***.***.***,10.3.0.28 //hvezdicky jsou public IP

všechny stroje mi hlasí:
CHECK_NRPE: Error - Could not complete SSL handshake.

dokumentace nějak nepomohla.. možná něco s certifikáty, ale ty jsou přeci na domain name a né na IP..

jakékoliv nápady ocením!

A nebo "first notification delay" v define services

Object Definitions
http://nagios.sourceforge.net/docs/3_0/objectdefinitions.html#service

KRISHNA: podle toho, co pise, bych spis predpokladal, ze hleda notification escalations.

HALELUJA: Nuu, nastavíš si retry_interval na 1 a max_check_attempts na 10.. ?

Já sem dneska nějak ultra natvrdlej.. můžete mě nakopnout jak udělat, aby u generic-hosta byl kromě ostatních notifikačních kontaktů ještě jeden, na kterej se ale bude notifikovat až po deseti minutách stavu down/up?

ALLES32: mno nic moc jsem tam užitečného zatím nenašel :/
nasazuju vždy a všude nagios. icinga se zdá, že by mohla být dobrá, ale momentálně nemám potřebu přecházet na něco jiného. to spíš z novejch věcí pokuju po Livestatusu - teď jsem ho zkušebně nasazoval kvůli jNagu a vypadá to pěkně a navíc nenáročně - jenže si to zas tak úplně nerozumí s Centreonem

KRISHNA: Pokud je celej server dole (host down event), pak se na nefunkcni sluzby neupozornuje. Zavislostma dosahnes jinejch veci. Napriklad mam sluzbu NFS server na serveru A a sluzbu "NFS mounts" na serverech B-Z. Pokud nejede NFS server, tak nema smysl kontrolovat, ze maji klienti namountovano, takze udelam service dependency. Dale se, pokud pouzivas NRPE, velice hodi kontrolovat beh NRPE jako takovyho a na nej jako zavislosti navesit vsechny sluzby, ktery pres NRPE kontrolujes - v pripade problemu ti tech mailu prijde o dost min.
Jinak ja mam zatim kompletni konfiguraci v textovejch souborech a diky duslednymu pouzivani sablon to nepovazuju za nejaky zasadni omezeni.
ALLES32: Zatim Icingu jen tak otukavam a moje poznatky by se daly shrnout takto:
1. Icinga ma o neco lip reseny webovy rozhrani (classic UI), daji se tam treba elegantne posilat hromadne prikazy (to je v nagiosu skutecne bolestiva zalezitost)
2. Icinga web je hodne zajimavej projekt, nicmene jsem tam nenasel ekvivalent "unhandled services" z classic UI, sice tam jdou nastavovat custom filtry a hromada dalsich veci, ale dost casto ty vypisy jsou celkem neprehledny - ve chvili, kdy mi tisic sluzeb hlasi nejakej problem, potrebuju to i za cenu, ze to bude pomaly, videt na jedny strance a ne se tim proklikavat.
3. Icinga umi IPv6, coz by vas mohlo nektere zajimat. Mne se to bohuzel nejspis jeste dost dlouho tykat nebude.

Mimochodem, nedavno jsem videl prezentaci komercniho nagiosu (Nagios IX) a v zasade mi prislo, ze je nenabizi nic navic proti tomu, co zvladne Icinga s novym UI a par addonama (BPI, pnp4nagios).