Monitoraggio delle applicazioni C ++

Naviga le tue risposte
10

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 grandi ed eterogenei (Solaris x86, RHEL Linux, Windows)?

Le possibilità che vedo sono:

  1. Net SNMP
    2.     
  • I vantaggi
    •         
  1. singolo daemon centrale su ciascun server
    2.             
  2. standard noto
    3.             
  3. facile integrazione nelle soluzioni di monitoraggio
    4.             
  4. eseguiamo daemon Net SNMP sui nostri server già
    5.         
  • Svantaggi:
    •         
    1. implementazione complessa (MIB, libreria Net SNMP)
      2.             
    2. nuova tecnologia da introdurre per gli sviluppatori C ++
      3.         
  • rsyslog
    •     
    • I vantaggi
      •         
    1. singolo daemon centrale su ciascun server
      2.             
    2. standard noto
      3.             
    3. integrazione sconosciuta nelle soluzioni di monitoraggio (so che possono fare avvisi basati sul testo, ma quanto bene potrebbe funzionare per l'invio di telemetria come l'utilizzo della memoria, le profondità delle code, la capacità del thread, ecc.)
      4.             
    4. implementazione semplice
      5.         
  • Svantaggi:
    •         
    1. possibili problemi di integrazione
      2.             
    2. una tecnologia in qualche modo nuova per gli sviluppatori C ++
      3.             
    3. possibili problemi di porting se cambiamo fornitore di monitoraggio
      4.             
    4. probabilmente implica l'introduzione di un protocollo di comunicazione ad hoc (o l'utilizzo di dati strutturati RFC 5424, non so se Zenoss lo supporta senza codifica Zenpack personalizzata)
      5.         
  • Embedded JMX (incorpora una JVM e usa JNI)
    •     
    • I vantaggi
      •         
    1. interfaccia di gestione coerente per Java e C ++
      2.             
    2. standard noto
      3.             
    3. facile integrazione nelle soluzioni di monitoraggio
      4.             
    4. implementazione piuttosto semplice (lo facciamo già oggi per altri scopi)
      5.         
  • Svantaggi:
    •         
    1. complessità (JNI, strato thunking tra C ++ nativo e Java, in pratica scrivere due volte il codice di gestione)
      2.             
    2. possibili problemi di stabilità
      3.             
    3. richiede una JVM in ogni processo, utilizzando molta più memoria
      4.             
    4. JMX è una nuova tecnologia per gli sviluppatori C ++
      5.             
    5. ogni processo ha la propria porta JMX (eseguiamo molti processi su ogni macchina)
      6.         
  • Demone locale JMX, i processi si connettono ad esso
    •     
    • I vantaggi
      •         
    1. singolo daemon centrale su ciascun server
      2.             
    2. interfaccia di gestione coerente per Java e C ++
      3.             
    3. standard noto
      4.             
    4. facile integrazione nelle soluzioni di monitoraggio
      5.         
  • Svantaggi:
    •         
    1. complessità (in pratica scrivendo due volte il codice di gestione)
      2.             
    2. ha bisogno di trovare o scrivere un demone simile
      3.             
    3. richiede un protocollo tra il daemon JMX e il processo C ++
      4.             
    4. JMX è una nuova tecnologia per gli sviluppatori C ++
      5.         
  • CodeMesh JunC ++ ion
    •     
    • I vantaggi
      •         
    1. interfaccia di gestione coerente per Java e C ++
      2.             
    2. standard noto
      3.             
    3. facile integrazione nelle soluzioni di monitoraggio
      4.             
    4. singolo daemon centrale su ciascun server quando eseguito in modalità JVM condivisa
      5.             
    5. implementazione piuttosto semplice (richiede la generazione del codice)
      6.         
  • Svantaggi:
    •         
    1. complessità (generazione del codice, richiede una GUI e diversi round di tweaking per produrre il codice proxy)
      2.             
    2. possibili problemi di stabilità JNI
      3.             
    3. richiede una JVM in ogni processo, utilizzando molta più memoria (in modalità incorporata)
      4.             
    4. Non supporta Solaris x86 (deal breaker)
      5.             
    5. Anche se supportava Solaris x86, ci sono problemi di compatibilità con il compilatore (usiamo una strana combinazione di STLPort e strong su Solaris
      6.             
    6. ogni processo ha la propria porta JMX quando viene eseguito in modalità incorporata (eseguiamo molti processi su ciascuna macchina)
      7.             
    7. probabilmente preclude un server JMX condiviso per i processi non C ++ (?)
      8.         

    C'è una soluzione semplice e standardizzata che mi manca?

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

    Il mio istinto è che Net SNMP è il modo in cui le persone lo fanno, ma mi piacerebbe l'input e l'esperienza degli altri prima di prendere una decisione.

        
    posta Scott A 21.07.2011 - 00:43
    fonte

    5 risposte

    1

    Non ho molta familiarità con Zenoss ma quando usavo nagios per questo genere di cose avremmo fatto la c / c ++ process ascolta su un socket e scrive un plug-in nagios personalizzato che consegnerà la diagnostica e informazioni sullo stato.

    Il primo passo è scegliere la lib che vuoi usare per far ascoltare il tuo processo .. Qualcosa come C ++ Socket Library fai per quello. Niente di complicato lì ... basta far ascoltare il processo.

    Quindi devi definire la risposta che il tuo processo invierà dato un particolare stimolo. Ciò significava veramente (almeno con i nagios) la definizione del "servizio" e quindi l'invio del processo al segnale corrispondente a quel servizio. La cosa più semplice che puoi fare è creare un "ping di processo" per vedere se riesci a connetterti correttamente al processo in esecuzione. Se lo fai, il plugin personalizzato nagios 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 di oggetti e trascinarla nel tuo materiale c ++ personalizzato in un modo standardizzato ogni volta che ne crei uno (o tutti) i tuoi eseguibili

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

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

        
    risposta data 28.07.2011 - 01:39
    fonte
    1

    Non ho familiarità con questi prodotti, ma per Windows monitoro il consumo di memoria usando perfmon, ci sono alcuni contatori speciali, come errori di pool non di paging, che mostrano se il tuo programma contiene perdite di memoria, potrebbero essere poco e quindi impiegare molto tempo per monitorare, ma a mio avviso questo è un semplice metodo di controllo.

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

        
    risposta data 24.06.2013 - 18:23
    fonte
    1

    Sto riprendendo questo dato che recentemente abbiamo affrontato lo stesso processo come te: Stavamo cercando una soluzione open source leggera, non bloccante, che consenta l'esposizione e il successivo monitoraggio remoto delle metriche dai servizi C / C ++ (abbiamo circa 3000).

    SNMP è diventato il più vicino, ma l'integrazione nell'origine e nel sistema di monitoraggio è dolorosa e non adatta ai nostri processi in tempo reale.

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

        
    risposta data 10.06.2014 - 22:58
    fonte
    0

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

    Questa impostazione non implica un singolo punto di errore per l'aggregazione o la segnalazione delle metriche (l'aggregazione basata sul tempo avviene sui nodi stessi e l'aggregazione dei rapporti avviene in un cluster di grafite distribuito (o grafite ospitata).

    Infine, puoi utilizzare Seyren per fornire avvisi sulla parte superiore dei dati di monitoraggio.

        
    risposta data 14.05.2013 - 23:07
    fonte
    0

    Se sei su Windows, tendi a scrivere nel registro eventi, quindi utilizza un WMI o un processo simile per leggere gli eventi. Se vuoi monitorare, aggiungi i contatori di Performance Monitor alla tua app e lascia che Perfmon li legga. Entrambi sono servizi di sistema in Windows.

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

    Ciò detto, ho visto diversi luoghi in cui viene utilizzato SMNP e, francamente, non riesco a vedere un motivo perché non lo useresti, specialmente se stai utilizzando un ambiente completamente eterogeneo.

        
    risposta data 24.06.2013 - 19:05
    fonte

    Leggi altre domande sui tag

    Che cosa vogliono imparare gli sviluppatori al loro prossimo avvio? [chiuso] Perché è consigliabile chiudere tutti i programmi prima di installare un nuovo programma?