[FoLUG] Nagios

[m]

* Silvio Lo Sciuto (silviodinotte@hotmail.com) [140319 11:52]:
>
>1 - in realtà pur avendo configurato il minimo di default in tutte le
>macchine , non tutte mi inviano dei messaggi
>2 - i messaggi sono di default , vorrei invece che questi arrivassero
>SOLO ( e non ogni 1h ) se raggiunti alcuni valori critici che devo
>ESSERE IO ad impostare - per ogni singola macchina , load , max jobs
>running , disco pieno,  etc
>3 - cosa piu importante , la richiesta fattami senza via di fuga , è
>quella di fare in modo che non siano le singole macchine         ad
>interagire con me LOL ma : che sia un Master , un Server , una macchina
>a scelta , che monitori tutte le altre 20 e che  ( in base ai limiti e
>pregi di ogni singola ) mi avvisi via email , una per tutte
>4 - trovare un sistema che nel caso di un load troppo alto , mi killi (
>sempre una per tutte ) il job che lo ha procurato e che eventualmente
>mi riavvii lo stesso o mi avvisi del kill
>5 - riattivare un ssh or un apache2 o un http nel caso che questi siano
>giu
>6 - avvisare nel caso di un fily system compromesso che magari non
>permette la scrittura
>7 - eventuali altri suggerimenti
>
>Qualcuno sarebbe in grado di darmi una sufficiente consulenza per poter
>settare in maniera pratica questi pochi punti che ho evidenziato ?
>

non sono in grado di darti una consulenza per email, perché sarebbe una
cosa troppo lunga, cioè in realtà dovrei configurarti il sistema io, ma
posso darti un paio di consigli ...

>Naturalmente sarei disposto , se ragionevole , a gratificare la
>suddetta consulenza.
>

... dunque, quello che vuoi fare tu è abbastanza normale: vuoi
monitorare un'infrastruttura, nel tuo caso di calcolo

Nagios e affini sono una buona scelta, e quindi sei partito col piede
giusto: i problemi che riscontri sono problemi di tutti, perché la
documentazione è quella che è, gli strumenti sono complicati e bisogna
capirne la logica, ecc.

alcuni punti:
- io (la mia azienda, in realtà: http://www.biodec.com/) fa per mestiere
   queste cose: per cui ne ho un'idea, da un lato, e facciamo supporto
   commerciale, dall'altro, proprio a sistemi basati su Nagios (et
   similia)
- non usare Nagios on the rock, ma prova a vedere se una distribuzione
   come omdistro.org fa meglio al caso tuo, visto che pacchettizza -
   tutte insieme - una serie di varianti a Nagios che spesso sono più
   usabili
- i punti 1. e 2. sono normale amministrazione
- il punto 3. anche è legittimo: che ci sia un solo server che si occupa
   di spedire gli allarmi (ma tu hai installato Nagios su *ogni* server ?)
- i punti 4. e 5. NON si fanno con Nagios e annessi, ma con altri tool,
   come puppet / cfengine3 che hanno uno scopo diverso (quello appunto di
   fungere da cron distribuito e mantenere uno stato consistente fra un
   un gruppo di sistemi)
- il punto 6. è spiegato male: cosa vuol dire file system compromesso ?
   non è un concetto ben definito: se hai un problema hardware, sarà il
   kernel che metterà il file system read only: se hai un problema
   hardware, il sistema di allarme ti avvertirà del problema per tempo,
   se opportunamente configurato
- punto 7.: prendi una decisione: o studi sta roba per un po' o avrai
   sempre l'impressione che funzioni un po' per caso, e alla fine non
   risolverà mai appieno l'obiettivo per cui la stai configurando, ovvero
   avvertirti tempestivamente che c'è un problema

quindi il consiglio è: se vuoi fare da solo, bene: mi permetto di
suggerirti di usare OMD e check_mk come sistema di monitoraggio (client
e server) e di lasciare i punti 4. e 5. a sistemi come puppet (magari
studia questo che è più semplice), se no, fallo fare a qualcuno che lo
fa di mestiere

-- 
  .*.                            finelli
  /V\
(/ \) --------------------------------------------------------------
(   )       Linux: Friends dont let friends use Piccolosoffice
^^-^^ --------------------------------------------------------------

Suppose you're working on an optimizer to render \X unnecessary (or
rather, redundant, which isn't the same thing in my book).
		-- Larry Wall in <199710211624.JAA17833@wall.org>