Stack de métrologie à Picasoft

Une solution de métrologie se décompose généralement en différents composants, chacun ayant un rôle bien spécifique.

D’un côté les différentes applications et serveurs, qui produisent des métriques. De l’autre la solution de métrologie.

Le premier composant se charge de collecter les métriques. Il existe 2 modèles pour cela : le push ou le pull.

Le modèle push implique que ce sont les serveurs et applicatifs qui vont envoyer les métriques au composant de collecte. Cette pratique a les avantages suivants :

• les sondes décident de quand elles envoient des métriques, par exemple uniquement lorsque les valeurs sont mises à jour, ou après l’exécution d’un évènement particulier (ex. tâche cron)
• les services et serveurs sont autonomes : lorsque l’on déploie un nouveau service il envoie automatiquement ses métriques, il n’y a pas de configuration à modifier côté outil de collecte

Cependant le modèle push a les inconvénients suivants :

• il faut autoriser l’accès à l’outil de collecte depuis la totalité de l’infrastructure. Il faut s’attendre à une configuration firewall ou d’authentification complexe côté de l’outil de collecte
• si l’outil de collecte est indisponible, la totalité des sondes auront une erreur. Si cette erreur n’est pas bien gérée (ce qui est probable, la sonde n’était pas la fonction première de l’application on peut s’attendre à une moins bonne fiabilité au développement) cela peut avoir des effets de bords directs sur l’application.