Surveillance des applications C ++

Nous mettons en œuvre une nouvelle solution de surveillance centralisée (Zenoss). L'intégration de serveurs, de réseaux et de programmes Java est simple avec SNMP et JMX.

Cependant, la question est de savoir quelles sont les meilleures pratiques pour surveiller et gérer des applications C ++ personnalisées dans de grands environnements hétérogènes (Solaris x86, RHEL Linux, Windows)?

Les possibilités que je vois sont:

1. Net SNMP

• Les avantages

1. démon central unique sur chaque serveur
2. norme bien connue
3. intégration facile dans les solutions de surveillance
4. nous exécutons déjà des démons Net SNMP sur nos serveurs

Désavantages:

1. implémentation complexe (MIB, bibliothèque Net SNMP)
2. nouvelle technologie à introduire pour les développeurs C ++

rsyslog

• Les avantages

1. démon central unique sur chaque serveur
2. norme bien connue
3. intégration inconnue dans les solutions de surveillance (je sais qu'ils peuvent faire des alertes basées sur du texte, mais dans quelle mesure cela fonctionnerait-il pour l'envoi de télémétrie comme l'utilisation de la mémoire, la profondeur des files d'attente, la capacité des threads, etc.)
4. mise en œuvre simple

Désavantages:

1. problèmes d'intégration possibles
2. technologie quelque peu nouvelle pour les développeurs C ++
3. problèmes de portage possibles si nous changeons de fournisseur de surveillance
4. implique probablement l'élaboration d'un protocole de communication ad hoc (ou l'utilisation de données structurées RFC5424; je ne sais pas si Zenoss prend en charge cela sans codage Zenpack personnalisé)

Embedded JMX (embarquez une JVM et utilisez JNI)

• Les avantages

1. interface de gestion cohérente pour Java et C ++
2. norme bien connue
3. intégration facile dans les solutions de surveillance
4. mise en œuvre assez simple (nous le faisons déjà aujourd'hui à d'autres fins)

Désavantages:

1. complexité (JNI, couche thunking entre C ++ natif et Java, écrivant essentiellement le code de gestion deux fois)
2. problèmes de stabilité possibles
3. nécessite une machine virtuelle Java dans chaque processus, utilisant beaucoup plus de mémoire
4. JMX est une nouvelle technologie pour les développeurs C ++
5. chaque processus a son propre port JMX (nous exécutons beaucoup de processus sur chaque machine)

Démon JMX local, les processus s'y connectent

• Les avantages

1. démon central unique sur chaque serveur
2. interface de gestion cohérente pour Java et C ++
3. norme bien connue
4. intégration facile dans les solutions de surveillance

Désavantages:

1. complexité (écrit essentiellement le code de gestion deux fois)
2. besoin de trouver ou d'écrire un tel démon
3. besoin d'un protocole entre le démon JMX et le processus C ++
4. JMX est une nouvelle technologie pour les développeurs C ++

Ion CodeMesh JunC ++

• Les avantages

1. interface de gestion cohérente pour Java et C ++
2. norme bien connue
3. intégration facile dans les solutions de surveillance
4. démon central unique sur chaque serveur lorsqu'il est exécuté en mode JVM partagé
5. implémentation assez simple (nécessite la génération de code)

Désavantages:

1. complexité (génération de code, nécessite une interface graphique et plusieurs cycles de réglages pour produire le code mandaté)
2. problèmes de stabilité JNI possibles
3. nécessite une machine virtuelle Java dans chaque processus, en utilisant considérablement plus de mémoire (en mode embarqué)
4. Ne prend pas en charge Solaris x86 (deal breaker)
5. Même s'il prend en charge Solaris x86, il existe des problèmes de compatibilité avec le compilateur (nous utilisons une étrange combinaison de STLPort et Forte sur Solaris
6. chaque processus possède son propre port JMX lorsqu'il est exécuté en mode intégré (nous exécutons beaucoup de processus sur chaque machine)
7. empêche éventuellement un serveur JMX partagé pour les processus non C ++ (?)

Existe-t-il une solution simple et raisonnablement standardisée qui me manque?

En l'absence d'autres solutions raisonnables, laquelle de ces solutions est généralement utilisée pour les programmes C ++ personnalisés?

Mon intuition est que Net SNMP est la façon dont les gens font cela, mais j'aimerais avoir la contribution et l'expérience des autres avant de prendre une décision.

Je ne connais pas très bien Zenoss, mais lorsque j'utilisais nagios pour ce genre de choses, nous faisions écouter le processus c / c ++ sur un socket et écrivions un plugin nagios personnalisé qui transmettrait des informations de diagnostic et d'état.

La première étape consiste à choisir la bibliothèque que vous souhaitez utiliser pour faire écouter votre processus. Quelque chose comme C ++ Socket Library fera pour cela. Rien de compliqué là-bas .. faites simplement écouter le processus.

Ensuite, vous devez définir la réponse que votre processus enverra en fonction d'un stimulus particulier. Cela signifiait vraiment (au moins avec les nagios) définir le «service» puis envoyer au processus le signal correspondant à ce service. La chose la plus simple que vous puissiez faire est de créer un «ping de processus» pour voir si vous pouvez vous connecter avec succès au processus en cours. Si vous le faites, le plugin nagios personnalisé sait au moins que le processus est toujours en cours.

Il y a des choses beaucoup plus sophistiquées que vous pouvez faire, mais l'idée est assez simple. Vous pouvez écrire votre propre petite bibliothèque de code d'écoute de processus encapsulé dans des objets et le glisser dans vos trucs c ++ personnalisés de manière standardisée chaque fois que vous construisez un (ou tous) vos exécutables

Ma compréhension est que Zenoss peut le faire aussi .

Comme Zenoss est python, vous allez probablement écrire votre plugin personnalisé à l'aide de quelque chose comme Twisted pour vous connecter à votre exécutable c ++ d'écoute.

Je ne connais pas ces produits que vous nommez, mais pour Windows, je surveille la consommation de mémoire à l'aide de perfmon, il existe des compteurs spéciaux, tels que les défauts de pool non paginés, qui vous indiquent si votre programme contient des fuites de mémoire, elles peuvent être peu importantes et donc prendre beaucoup de temps. le temps de surveiller, mais à mon avis, c'est une méthode de vérification simple.

Sur Windows, vous pouvez faire beaucoup en utilisant perfmon, même à distance Ou utiliser WMI pour vous attacher aux mêmes compteurs, et faire une certaine automatisation dessus (en wmi) pour effectuer des actions.

Je reprends cela car nous avons récemment suivi le même processus que vous: nous recherchions une solution open source légère, non bloquante qui permet d'exposer et de surveiller à distance les métriques à partir des services C / C ++ ( nous avons environ ~ 3000).

SNMP est venu le plus près, mais l'intégration dans la source et le système de surveillance est pénible et ne convient pas à nos processus en temps réel.

Finalement, nous avons décidé de développer une nouvelle solution appelée CMX qui utilise la technologie de mémoire partagée et la rendait open-source. Vous pouvez le vérifier ici: www.cern.ch/cmx .

Je ne suis pas très familier avec le côté c ++ des choses, mais en Java, nous utilisons largement les métriques CodaHale en conjonction avec Graphite . CodaHale stocke les métriques par instance dans la mémoire locale de l'instance, puis utilise un thread d'arrière-plan pour vider les métriques sur un serveur de graphite toutes les minutes (configurable). Dans le graphite, nous pouvons agréger les instances et identifier les instances défectueuses. Si vous ne voulez pas la complexité de la maintenance d'un cluster de graphite, vous pouvez utiliser HostedGraphite .

Cette configuration signifie qu'il n'y a pas de point de défaillance unique pour l'agrégation ou la génération de rapports de métriques (l'agrégation basée sur le temps se produit sur les nœuds eux-mêmes et l'agrégation de rapports se produit dans un cluster de graphite distribué (ou graphite hébergé).

Enfin, vous pouvez utiliser Seyren pour fournir des alertes en plus des données de surveillance.

Si vous êtes sous Windows, vous avez tendance à écrire dans le journal des événements, puis à utiliser un WMI ou un processus similaire pour lire les événements. Si vous souhaitez surveiller, ajoutez des compteurs de moniteur de performances à votre application et laissez perfmon les lire. Les deux sont des services système dans Windows.

Sous Linux, il a évidemment tendance à être plus flexible, mais j'ai toujours vu des moniteurs de style nagios implémentés, avec un socket personnalisé envoyant des données à un serveur de style nagios.

Cela dit, j'ai vu plusieurs endroits où SMNP est utilisé, et franchement, je ne vois pas pourquoi vous ne l'utiliseriez pas - surtout si vous utilisez un environnement complètement hétérogène.