J’ai récemment effectué une mission chez un client visant à mettre en place la supervision de plusieurs briques applicatives constituant un éco-système complexe. La plupart de ces briques sont externes au système d’information du client et donc hors de sa responsabilité.

Il était toutefois nécessaire de connaître l’état de santé de ces briques afin de pouvoir réagir rapidement en cas de la défaillance de l’une d’entre-elles.

Le client disposant de Dynatrace (en mode SAAS) il a été décidé d’utiliser le framework ActiveGate pour interroger les différentes briques et remonter leurs états sous forme de métriques vers Dynatrace.

Architecture

L’architecture est relativement simple et est constituée des éléments suivants :

• Un ensemble d’applications internes ou externes au système d’information, accessible via internet et qui expose leur état de santé sous une forme ou sous une autre (ping, page html, API XML ou JSON, etc…)
• Une infrastructure Dynatrace, en mode SAAS ou en mode managé.
• Une VM Linux équipée du moteur de Plugins ActiveGate.
• Un ensemble de plugins développés en Python (3.6.6 actuellement) qui s’appuient sur le SDK Dynatrace ActiveGate.

Fonctionnement

A chaque minute, Dynatrace interroge les plugins ActiveGate. Chaque plugin interroge à son tour l’application qu’il doit surveiller, en détermine l’état et renvoie l’information vers Dynatrace sous la forme de métriques.

Retour d’expérience

Documentation

La documentation ActiveGate est accessible ici.

Personnellement je pense qu’elle manque de profondeur et de détails sur les concepts et APIs exposés.

Installation et prise en main

Le SDK est téléchargeable directement depuis l’environnement SAAS Dynatrace. Il est pré-configuré de manière à ce qu’il ne soit nullement nécessaire de lui indiquer par exemple l’URL de Dynatrace pour que la communication se fasse avec ActiveGate. L’installation est réalisée à l’aide d’un script Shell téléchargeable également.

L’installation est donc facile et ne nécessite aucune configuration postérieure. Une fois installée, l’environnement ActiveGate est directement opérationnel.

Développement, déploiement et mise au point

Le développement des plugins se fait avec Python 3.6.6 à l’heure où cet article est écrit. Il faut respecter ce pré-requis sous peine de dysfonctionnement des plugins.

Le développement des plugins à l’aide du SDK ActiveGate est ensuite assez facile et ne présente pas de grande difficulté.

Le packaging des plugins s’effectue à l’aide d’un script Shell fournit avec le SDK AcivateGate. Le résultat obtenu est un fichier zip qui sera ensuite déployé. Rien à dire de particulier sur cette partie.

La mise au point se fait à l’aide d’un simulateur inclus dans le SDK. Il permet de « simuler » le fonctionnement du moteur de plugins ActiveGate sans avoir à déployer le plugin. Le client n’ayant qu’un seul environnement de Production et pas de tenant de test il était indispensable de pouvoir tester les plugins avant tout déploiement.

Lors de mes développements j’ai mis en évidence plusieurs fois des écarts de comportement entre le simulateur et le moteur de plugins. Le simulateur montrait un fonctionnement correcte du plugin alors que celui-ci dysfonctionnait une fois déployé dans le SAAS. En conséquence, il faut attendre le déploiement en production pour détecter d’éventuelles anomalies. C’est le très mauvais point du SDK selon moi.

J’ai remonté ce problème majeur au support Dynatrace qui m’a garanti se pencher sur la question. Wait and see.

J’ai également été confronté à un problème avec la gestion des logs au sein des plugins. Le SDK souffre d’un bug depuis pas mal de temps manifestement qui n’est toujours pas corrigé. Dynatrace est au courant du problème depuis longtemps mais n’a toujours pas proposé de solution. En résumé, il n’est pas possible d’utiliser des logs de niveau DEBUG au sein des plugins ; Il faut générer des logs de niveau INFO et configurer le logger au niveau DEBUG ; Cela donne un plugin qui fonctionne en permanence en mode DEBUG et qui donc peut générer un volume très important d’informations, surtout avec une sollicitation toutes les minutes. Ce problème illustre également le problème entre le simulateur et le moteur de plugins : Le logger fonctionne parfaitement sous le simulateur.

Ce problème est très impactant lors de la recherche d’anomalie sur le fonctionnement  des plugins.

Le déploiement des plugins se fait très facilement à l’aide de la console Dynatrace. Il se fait en 2 étapes :

• Upload et enregistrement du plugin dans l’environnement Dynatrace
• Création et configuration des end-points, c’est à dire des VMs ActiveGate

Fonctionnement en production

Le problème de la configuration des loggers expliqué dans le chapitre précédent constitue le principal dysfonctionnement du moteur selon moi. C’est dommage car ActiveGate permet de mettre à jour la configuration du plugin très facilement depuis la console Dynatrace. Il est donc possible théoriquement de passer d’un niveau de log INFO à DEBUG très facilement et à chaud afin d’obtenir une meilleure visibilité du fonctionnement du plugin en cas d’anomalie.

Il est regrettable également que la fréquence des appels depuis Dynatrace vers les plugins ActiveGate fixée à 1 minute ne puisse être modifiée. Si les services supervisés ne peuvent subir une fréquence aussi élevée il faut gérer la situation au niveau du code Python du plugin.

Support et forums de discussion

J’ai sollicité le forum de discussion Dynatrace et le support lors des problèmes rencontrés lors de la mise au point des plugins. Les retours sont plutôt rapides et généralement de bonne qualité. Ma seule objection concerne le problème du simulateur auquel le support m’a répondu que le client devrait disposer d’un tenant de tests. Et donc payer une souscription supplémentaire alors que le SDK fournit normalement les outils pour s’en passer.

Cycle de vie du SDK ActiveGate

Le rythme de sortie des releases du SDK ActiveGate est soutenu. Dynatrace publie une release au début de chaque mois. Mon conseil est de suivre les sorties des nouvelles versions de manière assez serrée.

La documentation évolue également pas mal, ce qui est une bonne chose.

Conclusion

Le bilan est très positif en terme de fonctionnalités attendues et dans leur mise en œuvre. Les problèmes de mise au point et de fonctionnement décrits dans cet article assombrissent toutefois un peu le tableau. Nul doute que ces problèmes seront résolus rapidement par les équipes de développement d’ActiveGate.