Monitoraggio di applicazioni C ++

Stiamo implementando una nuova soluzione di monitoraggio centralizzata (Zenoss). Incorporare server, reti e programmi Java è semplice con SNMP e JMX.

La domanda, tuttavia, è quali sono le migliori pratiche per il monitoraggio e la gestione di applicazioni C ++ personalizzate in ambienti di grandi dimensioni, eterogenei (Solaris x86, RHEL Linux, Windows)?

Le possibilità che vedo sono:

1. SNMP netto

• vantaggi

1. demone singolo e centrale su ciascun server
2. standard ben noto
3. facile integrazione in soluzioni di monitoraggio
4. eseguiamo già demoni Net SNMP sui nostri server

1. implementazione complessa (MIB, libreria Net SNMP)
2. nuova tecnologia da presentare per gli sviluppatori C ++

• vantaggi

1. demone singolo e centrale su ciascun server
2. standard ben noto
3. integrazione sconosciuta in soluzioni di monitoraggio (so che possono fare avvisi basati sul testo, ma quanto funzionerebbe bene per l'invio di telemetria come l'utilizzo della memoria, profondità della coda, capacità del thread, ecc.)
4. semplice implementazione

1. possibili problemi di integrazione
2. tecnologia un po 'nuova per gli sviluppatori C ++
3. possibili problemi di porting se cambiamo fornitore di monitoraggio
4. probabilmente comporta la creazione di un protocollo di comunicazione ad hoc (o l'utilizzo di dati strutturati RFC5424; non so se Zenoss lo supporti senza codifica Zenpack personalizzata)

• vantaggi

1. interfaccia di gestione coerente per Java e C ++
2. standard ben noto
3. facile integrazione in soluzioni di monitoraggio
4. implementazione piuttosto semplice (lo facciamo già oggi per altri scopi)

1. complessità (JNI, layer thunking tra C ++ nativo e Java, fondamentalmente scrivendo due volte il codice di gestione)
2. possibili problemi di stabilità
3. richiede una JVM in ogni processo, utilizzando molta più memoria
4. JMX è una nuova tecnologia per gli sviluppatori C ++
5. ogni processo ha la sua porta JMX (eseguiamo molti processi su ogni macchina)

• vantaggi

1. demone singolo e centrale su ciascun server
2. interfaccia di gestione coerente per Java e C ++
3. standard ben noto
4. facile integrazione in soluzioni di monitoraggio

1. complessità (fondamentalmente scrivendo due volte il codice di gestione)
2. bisogno di trovare o scrivere un tale demone
3. è necessario un protocollo tra il demone JMX e il processo C ++
4. JMX è una nuova tecnologia per gli sviluppatori C ++

• vantaggi

1. interfaccia di gestione coerente per Java e C ++
2. standard ben noto
3. facile integrazione in soluzioni di monitoraggio
4. demone singolo e centrale su ciascun server quando eseguito in modalità JVM condivisa
5. implementazione piuttosto semplice (richiede la generazione di codice)

1. complessità (generazione del codice, richiede una GUI e diversi round di ottimizzazione per produrre il codice proxy)
2. possibili problemi di stabilità JNI
3. richiede una JVM in ogni processo, utilizzando molta più memoria (in modalità integrata)
4. Non supporta Solaris x86 (deal breaker)
5. Anche se supportava Solaris x86, ci sono possibili problemi di compatibilità del compilatore (usiamo una strana combinazione di STLPort e Forte su Solaris
6. ogni processo ha la propria porta JMX quando eseguito in modalità incorporata (eseguiamo molti processi su ogni macchina)
7. forse preclude un server JMX condiviso per processi non C ++ (?)

C'è qualche soluzione ragionevolmente standardizzata e semplice che mi manca?

Dato altre soluzioni ragionevoli, quale di queste soluzioni viene in genere utilizzata per i programmi C ++ personalizzati?

La mia sensazione è che Net SNMP sia il modo in cui le persone fanno questo, ma mi piacerebbe il contributo e l'esperienza degli altri prima di prendere una decisione.

Io non sono super familiarità con Zenoss, ma quando ho usato per usato Nagios per questo genere di cose che vorrei fare il / C ++ processo c ascolta su un socket e scrivere un costume Nagios plug-in che sarebbe consegnare informazioni di diagnostica e di stato.

Il primo passo è scegliere la libreria che si desidera utilizzare per ascoltare il processo. Qualcosa come C ++ Socket Library farà per quello. Niente di complicato lì ... fai semplicemente ascoltare il processo.

Quindi devi definire la risposta che il tuo processo invierà con uno stimolo particolare. Ciò significava davvero (almeno con i nagios) definire il "servizio" e quindi inviare al processo il segnale corrispondente a quel servizio. La cosa più semplice che puoi fare è creare un "ping di processo" per vedere se riesci a connetterti con successo al processo in esecuzione. Se lo fai, il plug-in nagios personalizzato sa che almeno il processo è ancora attivo.

Ci sono cose molto più sofisticate che puoi fare ma l'idea è abbastanza semplice. Puoi scrivere la tua piccola lib di codice di ascolto del processo incapsulato all'interno degli oggetti e trascinarlo nella tua roba c ++ personalizzata in modo standardizzato ogni volta che costruisci uno (o tutti) i tuoi eseguibili

La mia comprensione è che Zenoss può fare anche questo .

Probabilmente dal momento che Zenoss è Python, scriverai il tuo plugin personalizzato per esso usando qualcosa come Twisted per la connessione al tuo eseguibile in ascolto c ++.

non ho familiarità con questi prodotti che chiami ma per Windows monitoro il consumo di memoria usando perfmon, ci sono alcuni contatori speciali, come errori di pool non paginati, che ti mostrano se il tuo programma contiene perdite di memoria, potrebbero essere piccole e quindi richiedere molto tempo tempo di monitorare ma secondo me questo è un semplice metodo di controllo.

Su Windows puoi fare molto usando perfmon, anche da remoto O usare WMI per collegarti agli stessi contatori, e fare un po 'di automazione su di esso (in WMI) per eseguire azioni.

Sto riprendendo questo mentre recentemente abbiamo attraversato lo stesso processo come te: stavamo cercando una soluzione open source leggera, non bloccante, che consenta di esporre e il successivo monitoraggio remoto delle metriche all'interno dei servizi C / C ++ ( abbiamo circa ~ 3000).

SNMP è arrivato il più vicino, ma l'integrazione nella fonte e nel sistema di monitoraggio è una seccatura e non adatta ai nostri processi in tempo reale.

Alla fine, abbiamo deciso di sviluppare una nuova soluzione chiamata CMX che utilizza la tecnologia della memoria condivisa e l'ha resa open-source. Puoi verificarlo qui: www.cern.ch/cmx .

Non ho molta familiarità con il lato c ++ delle cose, ma in Java utilizziamo ampiamente le metriche CodaHale insieme a Graphite . CodaHale memorizza le metriche per istanza nella memoria locale dell'istanza, quindi utilizza un thread in background per scaricare le metriche su un server di grafite ogni minuto (configurabile). In grafite possiamo aggregare tra istanze e identificare istanze difettose. Se non si desidera la complessità del mantenimento di un cluster di grafite, è possibile utilizzare HostedGraphite .

Questa configurazione non implica alcun singolo punto di errore per l'aggregazione o il reporting delle metriche poiché (l'aggregazione basata sul tempo avviene sui nodi stessi e l'aggregazione dei report avviene in un cluster di grafite distribuito (o grafite ospitata).

Infine, è possibile utilizzare Seyren per fornire avvisi in aggiunta ai dati di monitoraggio.

Se sei su Windows, tendi a scrivere nel registro eventi e quindi a utilizzare un WMI o un processo simile per leggere gli eventi. Se desideri monitorare, aggiungi contatori di monitoraggio delle prestazioni alla tua app e consenti a perfmon di leggerli. Entrambi sono servizi di sistema in Windows.

Su Linux, ovviamente, tende ad essere più flessibile, ma ho sempre visto implementati monitor in stile nagios, con un socket personalizzato che inviava dati a un server in stile nagios.

Detto questo, ho visto diversi luoghi in cui viene utilizzato SMNP e, francamente, non riesco a vedere un motivo per cui non lo utilizzeresti, soprattutto se gestisci un ambiente completamente eterogeneo.