Obervability
Services AudiTrace Ressources▾ Contact
FR ▾
Réserver un audit gratuit
Domaine d’audit · 11 contrôles

Audit Kubernetes Dynatrace : couverture, versions, échecs récurrents

Onze contrôles sur le parc de clusters — lesquels sont réellement connectés, quelles versions d’operator sont en retard, où des workloads remontent sans cluster, quels échecs se répètent en silence chaque jour.
Réserver un audit gratuit Les 71 contrôles

Ce que ces contrôles lisent

Connexion du cluster et version de l’operator

Chaque cluster connecté, sa version de Dynatrace Operator et son ancienneté par rapport à la version actuelle. Les operators anciens sont la cause habituelle du « la surveillance s’est arrêtée après la mise à niveau ».

Couverture des workloads

Des namespaces et des workloads qui ne remontent aucun pod, et des pods qui ne remontent aucun workload. Dans les deux cas, il y a un trou que le dashboard n’affichera pas comme un trou.

Échecs récurrents de pods et de conteneurs

Les boucles de redémarrage et les OOM kills qui reviennent à intervalle régulier passent en général pour du bruit. Comptés sur une fenêtre, ils deviennent une liste de workloads nommés.

Injection cloud-native full-stack ou injection classique

Le mode d’injection utilisé par chaque cluster, et les endroits où les deux sont présents en même temps — la configuration qui produit des entités en double et une consommation en double.

Pourquoi c’est important

C’est sur Kubernetes que la couverture de surveillance se périme le plus vite. Des clusters sont créés par des équipes qui ne portent pas l’observabilité, des namespaces apparaissent entre deux audits, et un operator à jour au moment du déploiement accuse deux versions mineures de retard quand quelqu’un finit par regarder.
Ces contrôles n’évaluent pas la conception de vos clusters. Ils répondent à une question plus étroite : ce que Dynatrace croit de vos clusters correspond-il à ce que vos clusters sont. Quand ce n’est pas le cas, le constat nomme le cluster, le namespace et le workload, en CSV — pas en pourcentage.
Le résultat le plus fréquent n’est pas un cluster manquant. C’est un cluster connecté, qui remonte des données, vert sur tous les dashboards, et instrumenté deux fois : une fois par l’operator, une fois par un init-container resté en place depuis l’approche précédente. Les deux jeux d’entités sont réels, les deux sont facturés, et aucun n’est assez faux pour déclencher une alerte.

Les questions qu’on nous pose sur ce domaine

L’audit s’exécute-t-il à l’intérieur de nos clusters ?

Non. Il lit le tenant Dynatrace via l’API — les entités cluster, leurs versions et les événements qu’elles remontent. Rien n’est installé, rien n’est planifié, et aucun identifiant de cluster n’est demandé.

Nous dira-t-il quels workloads ne sont pas surveillés ?

Il vous dit quels workloads Dynatrace voit et lesquels ne remontent aucun pod en cours d’exécution, ainsi que les namespaces sans aucun workload instrumenté. Un workload dans un cluster qui n’a jamais été connecté échappe à ce qu’un audit côté tenant peut voir — cet écart apparaît dans le domaine Coverage sous la forme d’un nombre de clusters qui ne correspond pas à votre propre inventaire.

Les autres domaines d’audit

Dix-neuf domaines, 71 contrôles, une exécution en read-only. Chaque domaine a sa page.
FinOps Où part l’argent, et ce qui est récupérable Kubernetes Couverture des clusters, versions, échecs récurrents Alerting Si un incident atteindrait réellement un humain Audit log Qui a changé quoi, quand, et hors heures ouvrées Coverage Ce qui est surveillé, et ce qui en a seulement l’air RUM Portée du monitoring des utilisateurs réels et réglages de confidentialité Grail Buckets, retention, coût de stockage annualisé Pipelines Traitement à l’ingestion, masquage, règles de rejet Synthetic Moniteurs Synthetic qui passent, échouent ou ne tournent jamais Topology Qualité de la détection d’entités et explosion du nombre d’entités OpenTelemetry Sources OTel et double instrumentation Security Portées des tokens, expiration, identifiants dormants Workflows Automatisations qui échouent ou ne se déclenchent jamais Bizevents Hygiène des fournisseurs d’événements métier Dashboards Inventaire des dashboards Davis Taux d’attribution de cause racine OpenPipeline Résolution des routes et des pipelines SLO Définitions de SLO qui cassent à la redétection Tagging Convention de tagging des environnements

Voyez ce que ce domaine trouve sur votre propre tenant.

Une exécution en read-only couvre les dix-neuf domaines. Vous gardez le rapport dans tous les cas.
Réserver un audit gratuit Voir comment fonctionne AudiTrace

Découvrez ce que votre Obervability fait réellement.

Un audit prend une exécution. Les constats prennent une réunion. Ce que vous en faites vous appartient.
Experts Dynatrace certifiés
+1
Envoyer
Obervability
Implémentation, services managés et support Dynatrace. Chaque constat arrive avec la source qui le sous-tend.
Services
Services AudiTrace Étude de cas
Guides
Audit Dynatrace Optimisation des coûts Dynatrace Étude de cas Articles
Nous joindre
© 2026 Obervability · Tous droits réservés.
Confidentialité Conditions d’utilisation Accessibilité