AWS lance CloudWatch Omni, un espace d’observabilité centré sur les applications plutôt que sur une succession de tableaux de bord. Il combine logs, métriques, traces, cartographie des dépendances et enquêtes assistées par Amazon DevOps Agent.

La réponse rapide

QuestionRéponse
Faut-il remplacer CloudWatch ?Non. Omni réutilise les signaux et alarmes existants.
Les équipes ont-elles besoin de la console AWS ?Non, elles accèdent à une URL dédiée avec SSO.
Quels standards sont pris en charge ?OpenTelemetry et un point d’entrée OTLP pour les environnements externes.

L’application avant l’infrastructure

Omni découvre les services à partir de la télémétrie et d’AWS Config, puis construit une topologie qui évolue avec les déploiements. Les équipes définissent des objectifs de disponibilité, de latence ou d’erreur au lieu de maintenir manuellement chaque vue. Cette organisation peut réduire les angles morts entre composants.

Une enquête partagée

Lorsqu’une alarme se déclenche, une session rassemble les signaux corrélés, les changements récents et l’historique des décisions. Un SRE peut inviter l’équipe responsable sans reconstruire le contexte dans une discussion séparée. L’objectif est de conserver la chronologie jusqu’au retour d’expérience.

DevOps Agent doit rester un assistant

L’agent recherche les corrélations, propose des causes et suggère des étapes de mitigation. Ses conclusions restent dépendantes de la qualité des traces et de la carte des services. Une équipe doit donc vérifier la causalité avant un rollback ou une action automatique, surtout lors d’un incident complexe.

Préparer le coût et la gouvernance

Avant un déploiement global, il faut définir les Spaces, les droits SSO, la rétention et les volumes OpenTelemetry. Centraliser davantage de signaux facilite l’enquête mais peut augmenter l’ingestion et exposer des données sensibles. Le pilote doit mesurer à la fois le temps gagné et la facture.