Penser le monitoring d'un projet web dans la phase de prise de besoin

En effet, le monitoring d'un produit web (site ou appli) nécessite le développement de dashboards branchés sur la base donnée du front pour sortir des stats sur les utilisateurs, les biens consommés (vendu pour du e-commerce, mais aussi écoutés pour une smart radio, vus pour une webtv).

Or les problèmes arrivent à la mise en ligne de ces dashboards: leurs requêtes sont longues, font parfois planter le front, ralentissent la base de données ou soulève des problèmes plus complexes comme l'état du système au moment de la stat ( par exemple, mettre en relation une stat avec une mise en avant en homepage d'un produit, d'une news.) Et c'est inévitable car votre base a été faite pour servir un front, pas des dashboards. Vous perdez le principe de "single responsability" et vos dashboards sont une catastrophe.

D'où le titre de ce poste : penser le monitoring de votre projet dans la phase de prise de besoin. Cela permet de savoir quel type de monitoring vous allez devoir mettre en place et de maitriser votre budget. Selon les nécessités le niveau de complexité du monitoring peut varier et j'ai dégagé 3 niveaux :

Premier niveau :

Une bonne implémantation d'un outil d'analyse comme Google Analytics vous suffit. Eventuellement, pour certaines données, un dashboard branché sur la base de front remonte quelques données.

C'est simple à mettre en place mais vous aurez rapidement des problèmes de perf sur vos dashboards (la base grandit normalement !) et certainement des données vous manqueront dans vos analyses de ROI.

Deuxième niveau :

Vous branchez sur votre base de données de front un ETL qui pompe, aggrège et strucutre vos données. Un autre front web vient ensuite afficher les données aggrégées.

C'est techniquement un peu plus compliqué et votre ETL risque aussi de plomber votre front. C'est sûrement la meilleure idée si vous n'avez pas pensé votre monitoring à l'avance mais si vous avez lu ce post, vous préférerez sûrment la solution 3 !

Troisième niveau:

L'idée générale étant de collecter les logs de votre système via une api pour les pousser dans une base plate (pour nous c'est MongoDB et Hadoop). Depuis cette base, vous agglomérez et analyser vos données indépendemment. Vos logs doivent avoir tout l'état de votre système pour pouvoir être intéressants et il ne faut pas hésiter à logger beaucoup de variables. Le côut est assez faible.

Vous pouvez alors brancher un outil sympa sur vos logs comme Tableau qui vous permettra de sortir à n'importe quelle stat de votre base.

Image : 

  Melissa K. Santala

 Two m-plane sapphire substrates (200x)

 Department of Materials Science and Engineering - University of California - Berkeley, California, USA

 16th Prize of Nikon Miscroscopyu contest 2006