1. Pourquoi les segments #
Un nouveau modèle.
Comparaison #
| Management zones | Segments | |
|---|---|---|
| Plateforme | Classique | Nouvelle plateforme (Grail, applications) |
| Rôle | Filtrer les vues et porter des permissions | Filtrer les données dans les applications, notebooks, dashboards |
| Contrôle d'accès | Oui (permissions par zone) | Non : l'accès passe par les politiques IAM et les contextes de sécurité |
| Calcul | Règles évaluées sur les entités | Filtres sur les données de Grail, avec variables |
Erreur Courante : Un segment n'est pas une barrière de sécurité : un utilisateur peut retirer le filtre. Pour restreindre l'accès, utilisez des politiques IAM sur les buckets et les contextes de sécurité.
2. Concevoir des segments #
Par équipe, application, environnement.
Bonnes pratiques #
- Un segment par axe d'organisation stable :
team,application,environment. - Des variables pour un seul segment paramétrable (
environment = $env) plutôt que dix segments copiés. - Des tags et attributs posés à la source (OneAgent, Kubernetes, OpenTelemetry) pour que les règles restent simples.
Bonne Pratique : Profitez de la migration pour nettoyer : beaucoup d'environnements ont des dizaines de management zones obsolètes. Ne migrez que celles qui servent encore.
À savoir : Dynatrace évolue très vite (nouvelle plateforme, Grail, applications) : vérifiez les noms d'écrans et les versions d'API dans la documentation de votre environnement.
