Da qualche giorno si sta consumando uno scontro piuttosto acceso tra gli (ormai ex) sviluppatori e manutentori dei nagios-plugins e Nagios Enterprises, che detiene i diritti per il marchio oltre a sviluppare e distribuire la soluzione commerciale e Nagios Core.

Da quanto è emerso pare che Nagios Enterprises abbia letteralmente defenestrato il gruppo di sviluppatori e li abbia estromessi dalla gestione del sito e del progetto dopo che questi hanno cominciato a citare anche altre soluzioni alternative al loro Core (Icinga, Naemon, Shinken etc etc..), sostituendoli con altre persone non meglio definite e che non hanno alcuna esperienza su quei progetti, mettendo a capo del tutto colui che ha mantenuto i nagios-plugins inizialmente (ma che da molti anni non contribuisce).
Il gruppo di sviluppatori storici dei nagios-plugins ha creato un fork e sta sottoponendo i propri package ai manutentori dei principali repository, trovate tutte le info al sito https://www.monitoring-plugins.org.

Per quanto può valere esprimo la mia più totale solidarietà ai ragazzi di monitoring-plugins.org che hanno subito un torto mostruoso, aggravato da futili motivazioni e da una arroganza spaventosa da parte del team ufficiale di Nagios, questi ragazzi hanno svolto un lavoro FANTASTICO e sono certo faranno altrettanto con il nuovo progetto, auguro a loro ogni fortuna.
Non so voi ma oggi ho un motivo in più per valutare seriamente un fork alternativo a Nagios Core…

Potete trovare riassunta un po’ tutta la diatriba alla url https://bugzilla.redhat.com/show_bug.cgi?id=1054340

Uno degli alert che odio maggiormente da parte del monitoraggio di server Windows (nel mio caso pochi e in lenta ma costante riduzione) è quello relativo al superamento delle soglie di occupazione sullo storage, specialmente quando questo riguarda l’unità di sistema e il cestino.

Sull’unità di sistema c’è poco da dire, il processo di update di questo sistema operativo (e dei relativi file che tendono ad accumularsi nelle directory di Windows) è una delle grandi follie di questo sistema operativo che non riuscirò mai a comprendere…

Quello su cui vorrei concentrarmi in questa sede invece è il cestino, questa mistica entità in grado di dare anche all’utente più banale il potere di causare disservizi su un intero server (ad esempio saturando a suon di cancellazioni il volume di turno).
Chiaramente anche ripulire il cestino dai file è tutt’altro che un’operazione scontata, non perchè questo sia complesso ma più che altro perchè i file “cancellati” da altri utenti risultano categorizzati sotto directory che riportano il security identifier (SID) dell’utente, quindi risulta piuttosto criptico capire “chi ha cancellato cosa” e regolarsi di conseguenza sulle possibili azioni da intraprendere.

Per “tradurre” questi identificativi negli username locali occorre lanciare il comando “wmic useraccount get name,sid”

Proprio durante queste feste mi sono ritrovato a fronteggiare un problema abbastanza rognoso su un cluster WebSphere Portal 6.0, come da tradizione i problemi più bloccanti sono quasi sempre originati da cause che più banali non si può…

Lo scenario in cui si è presentato il problema è il seguente:

• cluster WPS 6.0 composto da 4 nodi distribuiti su due server fisici, uno dei quali ospitante deployment manager
• OS RedHat Enterprise Linux ES 4 x86
• shutdown dell’intero cluster per attività di manutenzione sul dbms Oracle 10g utilizzato dal cluster
• al riavvio del cluster solo uno dei 4 nodi WPS non effettua lo startup bloccandosi immediatamente dopo il comando di avvio (sia tramite interfaccia dmgr che tramite script startServer.sh)

E’ parso chiaro fin da subito che la causa non potesse essere legata al dbms o altri servizi di supporto (es ldap) in quanto gli altri nodi che utilizzano le medesime risorse risultavano funzionare perfettamente, a prescindere da ciò il problema si presentava molto prima che il servizio potesse anche solo inizializzare le connessioni a ldap o database; escluse queste componenti non è restato da fare altro che concentrarsi su JVM e sistema operativo.

Analizzando la directory che contiene i log del nodo ho notato che:

1. la gran parte dei log presentava timestamp allineato e corrispondente allo shutdown del nodo (effettuato tramite deployment manager, nessun SIGKILL di processo o altre porcate del genere).
2. L’unico log modificato al momento dello startup è risultato essere lo startServer.log, aprendo il quale non risultano esserci indicazioni particolarmente utili.
   
3. Nei log di stdout (SystemOut.log) e stderr (SystemErr.log) della JVM non risultano record significativi tranne poche eccezioni relative a transazioni non completate verso i datasource JDBC (risolvibili mediante avvio in modalità recover, oppure eliminazione dei trasactlog e partnerlog WPS).
   Sniffando il traffico tra nodo WPS e listener Oracle durante l’avvio del nodo problemativo non risultano alcuna comunicazione, pertanto si escludono problemi legati ai datasource o alle transazioni con il repository dbms.
4. Non sussistono problemi legati ai permessi di lettura/scrittura sui filesystem dove risiedono i file del servizio, il file di pid non è presente e non ci sono processi in ascolto su porte utilizzate dal nodo WPS.

A questo punto stavo cominciato a brancolare nel buio, verificando nella directory WAS_HOME ho rilevato un file javacore.txt con timestamp corrispondente allo shutdown del nodo, spulciando tra le prime righe di questo file di trace ho notato una indicazione chiave.

Da Wikipedia: “The SIGXFSZ signal is sent to a process when it grows a file larger than the maximum allowed size”

A questo punto mi sono messo alla ricerca di file di dimensioni considerevoli nelle principali directory dove il servizio (o i processi del servizio) vanno a scrivere, principalmente logs.
Proprio nella directory dei log del nodo era presente il log di errore del Garbage Collector JVM (native_stderr.log) di dimensione “abbastanza” sospetta: 2GB precisi precisi.
Aprendonolo risulta che l’ultimo record in coda risulta stranamente troncato.

Dopo aver svuotato il log il nodo è magicamente partito e non ha mostrato alcun segno di anomalia!
VITTORIA! :)

Giusto un piccolo assaggio di cosa è capace una san con dello storage performante e ben configurato.

La crisi morde, le tasse pure, le bollette sono uno strazio…
Quindi quale miglior argomento per iniziale l’anno di una bella panoramica sul reale assorbimento elettrico dei più comuni dispositivi che troviamo nelle nostre case?

Sembra un argomento banale o scontato, in realtà ogni volta che incappo in una discussione che tratta questo argomento trovo dati a dir poco fantasiosi, tra gente che si affida a qualche sito per stimare l’assorbimento del proprio pc o della propria televisione, a quelli che non sanno nemmeno distinguere la tensione dall’assordimento elettrico.

Visto che ho passato gli ultimi giorni a inseguire come un segugio ogni dispositivo di casa con un wattmetro (economico ma pur sempre indicativo) ho pensato di pubblicare i risultati per dare un riferimento realistico e oggettivo a quanti vanno cercando informazioni di questo tipo.

• TV LCD LED 22″ (standby) ~0,2 W
• TV LCD LED 22″ (acceso) 22 W
• Stampante Laser monocromatica (standby) 13 W
• Stampante Laser monocromatica (in stampa) 800 W
• Router ADSL domestico (no AP) + switch ethernet unmanaged 8 porte Gbps 27 W
• Raspberry PI + HDD 2,5″ 6 W
• Display HP ZR24W LCD S-IPS 24″ (standby) ~0,3 W
• Display HP ZR24W LCD S-IPS 24″ (acceso) 50 W
• PC Gaming** (idle) 72 W
• PC Gaming** (CPU stress) 180 W
• PC Gaming** (GPU stress) 250 W
• Climatizzatore da parete incluso unità esterna (idle) 9 W
• Spazzolino elettrico ~0,2 W
• Radiosveglia 1 W
• Access Point 300Mbps 3 antenne 4 W
• Switch ethernet unmanaged 5 porte Gbps 5 W
• TV 42″ plasma (standby) 1 W
• TV 42″ plasma (immagine bianca) 313 W
• TV 42″ plasma (immagine nera) 52 W
• TV 42″ plasma (immagine grigia) 220 W
• Network Media Tank HDD 3.5″ SATA (standby HDD standby) 8 W
• Network Media Tank HDD 3.5″ SATA (standby HDD attivo) 15 W
• Network Media Tank HDD 3.5″ SATA (in riproduzione) 16 W
• Decoder Sky HD 2013 (idle) 11 W
• Decoder Sky HD 2013 (attivo) 12 W
• Telefono cordless (in carica) 2 W
• Netbook 11″ CPU Atom 20 W
• TV LCD 22″ 26 W
• Congelatore a pozzo (idle) 8 W
• Congelatore a pozzo (compressore attivo) 65 W
• Affettatrice elettrica 114 W
• Frigorifero + congelatore 60x60x200 (compressore attivo) 90W

** Configurazione: Core i7 3770, 8GB RAM DDR3, GPU Radeon HD7850, SSD 128GB, 3x HDD SATA 3,5″, 1x HDD SATA 2,5″