Monitoreo de aplicaciones C ++

Estamos implementando una nueva solución de monitoreo centralizado (Zenoss). Incorporar servidores, redes y programas Java es sencillo con SNMP y JMX.

La pregunta, sin embargo, es ¿cuáles son las mejores prácticas para monitorear y administrar aplicaciones C ++ personalizadas en entornos grandes y heterogéneos (Solaris x86, RHEL Linux, Windows)?

Las posibilidades que veo son:

1. SNMP neto

• Ventajas

1. demonio central único en cada servidor
2. estándar bien conocido
3. fácil integración en soluciones de monitoreo
4. ya ejecutamos demonios Net SNMP en nuestros servidores

Desventajas

1. implementación compleja (MIB, biblioteca SNMP neta)
2. nueva tecnología para introducir para los desarrolladores de C ++

rsyslog

• Ventajas

1. demonio central único en cada servidor
2. estándar bien conocido
3. integración desconocida en soluciones de monitoreo (sé que pueden hacer alertas basadas en texto, pero qué tan bien funcionaría para enviar telemetría como uso de memoria, profundidades de cola, capacidad de hilo, etc.)
4. implementación simple

Desventajas

1. posibles problemas de integración
2. tecnología algo nueva para desarrolladores de C ++
3. posibles problemas de portabilidad si cambiamos los proveedores de monitoreo
4. probablemente implica crear un protocolo de comunicación ad-hoc (o usar datos estructurados RFC5424; no sé si Zenoss lo admite sin la codificación personalizada de Zenpack)

JMX incorporado (incrustar una JVM y usar JNI)

• Ventajas

1. Interfaz de gestión coherente para Java y C ++
2. estándar bien conocido
3. fácil integración en soluciones de monitoreo
4. implementación algo simple (ya lo hacemos hoy para otros fines)

Desventajas

1. complejidad (JNI, capa de conexión entre C ++ nativo y Java, básicamente escribiendo el código de administración dos veces)
2. posibles problemas de estabilidad
3. requiere una JVM en cada proceso, usando considerablemente más memoria
4. JMX es una nueva tecnología para desarrolladores de C ++
5. cada proceso tiene su propio puerto JMX (ejecutamos muchos procesos en cada máquina)

Demonio JMX local, los procesos se conectan a él

• Ventajas

1. demonio central único en cada servidor
2. Interfaz de gestión coherente para Java y C ++
3. estándar bien conocido
4. fácil integración en soluciones de monitoreo

Desventajas

1. complejidad (básicamente escribir el código de administración dos veces)
2. necesita encontrar o escribir tal demonio
3. necesita un protocolo entre el demonio JMX y el proceso C ++
4. JMX es una nueva tecnología para desarrolladores de C ++

CodeMesh JunC ++ ion

• Ventajas

1. Interfaz de gestión coherente para Java y C ++
2. estándar bien conocido
3. fácil integración en soluciones de monitoreo
4. demonio central único en cada servidor cuando se ejecuta en modo JVM compartido
5. implementación algo simple (requiere generación de código)

Desventajas

1. complejidad (generación de código, requiere una GUI y varias rondas de ajustes para producir el código proxy)
2. posibles problemas de estabilidad JNI
3. requiere una JVM en cada proceso, utilizando considerablemente más memoria (en modo incrustado)
4. No es compatible con Solaris x86 (factor decisivo)
5. Incluso si admitiera Solaris x86, existen posibles problemas de compatibilidad del compilador (utilizamos una combinación extraña de STLPort y Forte en Solaris
6. cada proceso tiene su propio puerto JMX cuando se ejecuta en modo incrustado (ejecutamos muchos procesos en cada máquina)
7. posiblemente excluya un servidor JMX compartido para procesos que no sean C ++ (?)

¿Me falta alguna solución simple y razonablemente estandarizada?

Sin otras soluciones razonables, ¿cuál de estas soluciones se usa típicamente para programas C ++ personalizados?

Mi intuición es que Net SNMP es la forma en que las personas hacen esto, pero me gustaría recibir los comentarios y la experiencia de otros antes de tomar una decisión.

No estoy muy familiarizado con Zenoss, pero cuando solía usar nagios para este tipo de cosas, hacíamos que el proceso c / c ++ escuchara en un socket y escribiera un complemento de nagios personalizado que entregaría información de diagnóstico y estado.

El primer paso es elegir la biblioteca que desea usar para que su proceso escuche. Algo como C ++ Socket Library hará para eso. Nada complicado allí ... solo haz que el proceso escuche.

Luego debe definir la respuesta que enviará su proceso dado un estímulo particular. Esto realmente significaba (al menos con nagios) definir el 'servicio' y luego enviar al proceso la señal que correspondía a ese servicio. Lo más simple que puede hacer es crear un 'ping de proceso' solo para ver si puede conectarse con éxito al proceso en ejecución. Si lo hace, el complemento nagios personalizado sabe que al menos el proceso aún está activo.

Hay cosas mucho más sofisticadas que puedes hacer, pero la idea es bastante simple. Puede escribir su propia pequeña lib de código de escucha de proceso encapsulado dentro de objetos y colocarlo en su material personalizado de C ++ de manera estandarizada cada vez que construya uno (o todos) sus ejecutables

Mi opinión es Zenoss puede hacer esto también .

Probablemente, dado que Zenoss es python, entonces escribirá su complemento personalizado para él usando algo como Twisted para conectarse a su ejecutable c ++ de escucha.

No estoy familiarizado con estos productos que usted nombra, pero para Windows monitorizo ​​el consumo de memoria usando perfmon, hay algunos contadores especiales, como fallas de grupo no paginado, que le muestran si su programa contiene pérdidas de memoria, pueden ser pequeñas y, por lo tanto, tomar mucho tiempo tiempo para monitorear pero en mi opinión este es un método de verificación simple.

En Windows, puede hacer mucho con perfmon, incluso de forma remota, o utilizar WMI para conectarse a los mismos contadores y automatizarlo (en wmi) para realizar acciones.

Estoy retomando esto, ya que recientemente pasamos por el mismo proceso que tú: estábamos buscando una solución ligera, sin bloqueos y de código abierto que permita la exposición y el monitoreo remoto posterior de las métricas desde los servicios C / C ++ ( Tenemos alrededor de ~ 3000).

SNMP se acercó más, pero la integración en la fuente y el sistema de monitoreo es una molestia y no es adecuada para nuestros procesos en tiempo real.

Al final, decidimos desarrollar una nueva solución llamada CMX que utiliza tecnología de memoria compartida y la convirtió en código abierto. Puede consultarlo aquí: www.cern.ch/cmx .

No estoy muy familiarizado con el lado c ++ de las cosas, pero en Java utilizamos ampliamente las métricas CodaHale junto con Graphite . CodaHale almacena las métricas por instancia en la memoria local de la instancia y luego usa un hilo de fondo para descargar las métricas a un servidor de grafito cada minuto (configurable). En grafito podemos agregar a través de instancias, así como identificar instancias defectuosas. Si no desea la complejidad de mantener un clúster de grafito, puede usar HostedGraphite .

Esta configuración significa que no hay un solo punto de falla para la agregación de métricas o informes ya que (la agregación basada en el tiempo ocurre en los propios nodos y la agregación de informes en un clúster de grafito distribuido (o grafito alojado).

Por último, puede usar Seyren para proporcionar alertas sobre los datos de monitoreo.

Si está en Windows, tiende a escribir en el registro de eventos y luego utiliza un WMI o un proceso similar para leer los eventos. Si desea monitorear, agrega contadores de monitoreo de rendimiento a su aplicación y deja que perfmon los lea. Ambos son servicios del sistema en Windows.

En Linux, obviamente tiende a ser más flexible, pero siempre he visto implementados monitores de estilo nagios, con un socket personalizado que envía datos a un servidor de estilo nagios.

Dicho todo esto, he visto varios lugares donde se usa SMNP y, francamente, no puedo ver una razón por la que no lo usarías , especialmente si estás ejecutando un entorno completamente heterogéneo.