1. L'ancien modèle de licence (Composants séparés) #
Historiquement, Dynatrace proposait un modèle où les licences étaient découpées en plusieurs quotas spécifiques (Unités).
La segmentation par Unités #
Dans ce modèle, vous deviez acheter et allouer un volume précis pour chaque type d'utilisation :
- Unités d'Hôtes (Host Units) : Utilisées pour surveiller l'infrastructure et les applications. Chaque hôte se voit attribuer un nombre d'unités basé sur la quantité de RAM (Ex: un hôte de 16 Go de RAM = 1 unité d'hôte).
- DEM (Digital Experience Monitoring) : Utilisées pour la surveillance des utilisateurs réels (RUM) et la surveillance synthétique (Robots).
- DDU (Davis Data Units) : Utilisées pour la collecte de métriques personnalisées, de logs, de traces et d'événements.
- AppSec (Application Security) : Unités allouées à la détection et à l'analyse des vulnérabilités applicatives.
Bilan de l'ancien modèle #
Avantages : Contrôle strict et prévisibilité par silo. Vous savez exactement combien de serveurs ou de volume de logs vous êtes autorisés à surveiller, ce qui limite les débordements financiers inattendus pour une fonctionnalité spécifique.
Inconvénients : Grande rigidité (effet de silo). Si vous consommez tous vos DDU pour l'ingestion de logs, mais qu'il vous reste des "Unités d'Hôtes" inutilisées, vous ne pouvez pas transférer ce budget d'un pilier à un autre. Cela freine l'adoption de nouvelles fonctionnalités et engendre une gestion administrative lourde (avenants de contrats réguliers).
2. Le nouveau modèle : DPS (Dynatrace Platform Subscription) #
Pour s'adapter aux environnements Cloud et unifier la facturation, Dynatrace a introduit le modèle DPS.
Le principe de l'engagement global #
Le modèle DPS met fin à la gestion par silos. L'entreprise s'engage sur un budget global annuel (un "Pool" monétaire). Toutes les fonctionnalités de la plateforme (monitoring d'hôtes, traces, logs, sécurité, DEM) sont valorisées selon une grille tarifaire (Rate Card) et consomment dynamiquement ce budget partagé à la demande.
Bilan du modèle DPS #
Avantages : Flexibilité absolue. L'entreprise dépense son budget là où elle en a besoin, quand elle en a besoin. Ce modèle offre une grande transparence financière et donne un accès immédiat à toutes les nouvelles fonctionnalités de Dynatrace sans nécessiter l'achat de nouvelles licences spécifiques.
Inconvénients : Nécessite une gouvernance forte et proactive (approche FinOps). Comme toutes les données puisent dans le même budget, une application mal optimisée qui générerait soudainement un volume excessif de logs ou de traces peut drainer l'enveloppe budgétaire globale de l'entreprise si aucun quota ou aucune alerte de consommation n'est mis en place.
3. Quel modèle selon votre environnement ? #
Plateforme classique ou nouvelle plateforme.
Correspondance #
| Environnement | Modèle de licence | Ce qu'il faut suivre |
|---|---|---|
| Dynatrace SaaS « latest » (Grail, AppEngine, nouvelles applications) | DPS : obligatoire pour Grail et les applications de la nouvelle plateforme | Coût par capacité dans Account Management > Subscription |
| Dynatrace SaaS sous contrat historique | Classique (Host Units, DEM, DDU) jusqu'à la migration du contrat vers DPS | Consommation des Host Units, DEM et DDU |
| Dynatrace Managed | Classique dans la plupart des contrats | Consommation dans la console Cluster Management (Licensing) |
À savoir : Les DDU ne sont donc pas « obsolètes » : elles restent la référence pour les contrats classiques. En revanche, une formation ou une procédure qui ne parle que des DDU ne s'applique pas à un environnement DPS, où la même donnée (logs, métriques, traces) est facturée par capacité.
Comment la consommation est comptée #
| Capacité (DPS) | Unité de mesure | Équivalent classique |
|---|---|---|
| Full-Stack Monitoring | GiB-heure de mémoire des hôtes supervisés | Host Units |
| Infrastructure Monitoring | Heure d'hôte | Host Units (mode infrastructure) |
| Log Management and Analytics | GiB ingéré, GiB-jour conservé, GiB analysé par requête | DDU (logs) |
| Métriques et traces personnalisées | Volume ingéré (points de données, spans) | DDU (métriques, traces) |
| Real User Monitoring, Synthetic | Session, requête ou action synthétique | DEM Units |
| Application Security | GiB-heure des hôtes protégés | AppSec Units |
4. Suivre et maîtriser la consommation #
FinOps appliqué à Dynatrace.
En modèle classique #
- Suivre la consommation des Host Units, DEM et DDU par environnement (voir la vidéo suivante sur les DDU).
- Définir des quotas de DDU par environnement pour éviter qu'un environnement de test n'épuise le volume annuel.
- Repérer les principales sources de DDU : logs, métriques personnalisées, spans, événements.
Avec DPS #
- Account Management > Subscription : budget, consommation par capacité et prévision de fin de contrat.
- Alertes de consommation sur le budget, à des paliers (50 %, 75 %, 90 %).
- Attribution des coûts par équipe ou par produit avec les champs
dt.cost.costcenteretdt.cost.product.
La consommation est aussi enregistrée dans Grail sous forme d'événements, que l'on peut analyser en DQL :
fetch dt.system.events, from: -7d
| filter event.kind == "BILLING_USAGE_EVENT"
| summarize events = count(), by: { event.type }
| sort events descBonne Pratique : Avant un changement de contrat, comparez sur quelques semaines la consommation classique et son équivalent DPS : les volumes de logs et de requêtes DQL sont souvent les postes qui varient le plus.
Erreur Courante : Avec DPS, une requête DQL qui parcourt de gros volumes de logs a un coût : préférez des filtres de temps courts, des buckets dédiés et des segments plutôt que des requêtes sur toute la rétention.
