La position fonceuse et son enlacement en haut à droite du Magic Quadran du Gartner font de Dynatrace un outil intéressant, voir indispensable et surtout scruté à la loupe.
Depuis 5 ans Dynatrace et sa technologie OneAgent enrichit son catalogue de fonctionnalités et le mode de licensing qui était très simple à l’origine commence un peu s’étoffer et à devenir complexe.
Les types de licences
En effet le package d’entrée s’appelle les Host Unit (HU). Il se vend par une souscription à l’année d’une machine de 16 Go monitorée de fond en comble en mode Full Stack. Mais depuis 3 autres types de consommables sont venu s’ajouter pour répondre à diverses fonctionnalités.
Il y a tout d’abord les crédits DEM (Digital Experience Monitoring) , qui sont vendu par pack de 1 million, à consommer sur l’année et permettent deux choses, d’un côté le monitoring de ce qui se passe dans le navigateur et la comptabilité des sessions qu’on appelle le RUM (Real User Monitoring) de l’autre les session Replay, permettant de rejouer des sessions critique afin de mieux les débuguer, et pour finir le synthétique monitoring qui consomme des crédit DEM à haute fréquence lors des passages de scripts fonctionnels permettant de vérifier le bon fonctionnement d’une application.
Mais Dynatrace fonctionne avec un moteur IA qui a, lui aussi, son mode de facturation interne. Ainsi ce dernier nécessite des DDU (Davis Data Unit), vendu aussi par pack de 1 million ils sont consommés lors de l’import de métriques externe comme du SNMP ou de l’OpenTelemetry. On les trouve aussi lors de l’ingestion de logs et pas mal d’autres ajouts externes transformant Dynatrace en une gigantesque HUB de concentration télémétrique.
Le petit dernier vient du monde de la sécurité, c’est la licence du WAF, les ASU (Application Security Unit), qui s’achètent par pack de 10 000 heures (il faut 8750 heures pour couvrir une machine pendant une année) et permet de détecter, proposer et sécurité les serveurs exposés.
Bref 4 types de licences, dont 1 en souscription (HU) et 3 en crédit à consommer sur l’année (DEM, DDU et ASU). Un bazar commercial qui peut vite stresser les clients sur leur prise de commande et surtout le suivi des consommations dans l’année.
La gestion naturelle des Host Unit
Un client qui prend une souscription de 100 HU a le loisir de monitorer l’équivalent de 100X16Go soit 1600 Go de mémoire machine, donc toutes les petites VM de 4Go qui hébergent des serveurs Web ou même des AS pourront être intégralement monitorés. Mais il existe une subtilité, car il y a deux modes de monitoring : Le mode système (CPU, RAM, NIC, HDD), et me mode Full Stack (transactions java, PHP JMS etc.).
Et c’est là qu’on peut, ou même qu’on doit faire des réductions de couts, à commencer par la base de données. Cette dernière fait usuellement 64 GO (4 HU) mais le monitoring Full Stack ne sert à rien car le suivit de son activité interne se faire par des modules additionnels et non pas par le OneAgent déployé. Donc je recommande vivement de la passer en monitoring système. Le suivi des process est le même et les transactions, que dis-je les requêtes SQL, sont monitorées par les appels émis du serveur d’application.
Autre que les serveurs de Base de données, il est évident que les serveurs de fichiers, n’ont pas besoin de monitoring Full-Stack. D’une manière générale tous les serveurs dont le travail est plus “système” que “applicatif” peuvent être monitoré à minima pour sauvegarder des HU.
Les HU libérés peuvent ainsi être reventilés sur d’autres applications.
La maitrises de DEM
Alors comment réduire sa consommation de DEM tout en gardant un niveau de surveillance et de qualité suffisant.
Pour commencer les DEM utilisé pour suivre les utilisateurs, le RUM, peut être échantillonné, dans les configurations d’une application vous trouverez un critère en pourcentage pour baisser le volume des utilisateurs traités. L’inconvénient c’est que si vous abaissez à 50% et que vous avez des debuggages sur certains utilisateurs à faire, vous risquerez de ne pas les voir. L’avantage c‘est une réduction immédiate de la consommation des crédits DEM.
Coté synthétique monitoring, nous savons qu’il n’est pas possible de désactiver un injecteur pour les périodes de maintenance ou même de nuit. En fait un synthétique monitoring est démarré pour faire des requêtes tous les 5 ou 15 mins et il n’y a pas de fonctions de planification programmable.
Alors je propose deux méthodes, mais elles passent par l’API de Dynatrace. Tout d’abord on peut arrêter et démarrer un synthétique, pour cela une simple requête d’API fait l’affaire. Il en faut une le matin et une le soir, on peut aussi en faire en début et fin de weekend. Mais je conseille plutôt la méthode qui consiste à modifier la fréquence de test, au lieu de 5 min on la passe à 60 minutes, ceci permet de garder un œil sur l’application la nuit et le weekend sans couter trop cher. Une requête d’API est aussi capable de modifier cette fréquence, vos automaticiens vont adorer ce type de customisation.
Un des problèmes de la maitrise des DEM est le suivi des consommations, il y a bien des tableaux dans l’admin du Cluster pour vérifier le volume des DEM consommé mais cela reste très imprécis pour faire des projections de consommation et un suivi fin par application et environnement.
Pour cela je recommande la création de Dashboard Dédié, qui peut sortir des graphiques sur les consommations par application, jour, mois, année. De manière à avoir un solide point de vue sur le grignotage de ses crédits.
Le casse-tête des DDU
Les DDU sont issues directement des configurations de métriques et des recherches sur les logs et du travail de filtrage du moteur Davis. Un menu propose de bien visualiser la consommation en cours, et il est possible de créer des Dashboards détaillés sur chaque type d’entêtées monitorées.
Il n’y a pas réellement de Tips qui permette de réduire la facture sur ces consommations. Toutefois la création de chaque métrique est toujours accompagnée d’une petite note prévenant que sa création va engendrer des consommations.
D’un point de vue de la méthode je conseillerais surtout de consulter les graphes de consommations à la journée ou à la semaine afin de se faire des projections sur les quotas de consommations en rapport avec le crédit restant.
Les débuts des ASU
Comme je l’ai déjà écrit plus haut, les ASU sont vendu par crédit de 10 000 ce qui permet allégrement de surveiller une machine sur un an. Toutefois cette protection existe à deux niveaux. Il y a d’abord les audits de vulnérabilité qui testent les versions installées et fournissent des rapports et des solutions de renforcement. Ce besoin n’est pas nécessairement full-time, peut être des audits de 1 à 2 jours par machines suffit à sécuriser jusqu’à 95% les Applications exposées. Donc avec une seule licence il est possible d’auditer tout son parc.
Mais l’autre possibilité de cette solution est la coupure de service en cas d’attaque, classique dans un WAF, celle-ci nécessite que le service de sécurité soit actif 24/7 sur chaque machine exposée. Dans ce cas-là je n’ai pas de méthode pour réduire les couts.
Conclusions
Ce modèle basé d’un coté sur des quotas de HU et des crédits de DEM et DDU est un casse-tête en termes de pilotage, de suivi de consommation et de gestion administrative pour les grandes entreprises. En effet une entreprise du CAC40 qui fonctionne avec des marchés structurés n’a pas la souplesse pour repasser des commandes à la volé en cours d’année. De plus Dynatrace évolue tellement vite que de nouvelles fonctionnalités apparaissent en cours d’année et peuvent parfois utiliser des crédits non planifiés. Pour finir les cycles de ventes de ces gros logiciels sont devenu annuels à cause des souscriptions ce qui oblige le client à entrer en phase de négociation en permanence entre ses besoins en monitoring, ses achats, sont fournisseur.
Dynatrace étude un futur business model moins complexe et plus facile à piloter et suivre afin de permettre à ses clients de gagner en usage et en confiance sur l’avenir.
En attendant, suivez mes petits conseils et ne perdez pas de vue vos applications.
Comments