Observabilité

Amazon OpenSearch Service offre de nouvelles fonctionnalités pour vous aider à résoudre vos problèmes d'observabilité. Utilisez des interfaces ouvertes pour collecter, acheminer et transformer les données de télémétrie (notamment OpenTelemetry, Fluentd, Fluent Bit, Logstash, Data Prepper, etc.). Vous pouvez rechercher et analyser de grandes quantités de données semi-structurées grâce à des fonctionnalités natives. Vous pouvez visualiser, surveiller et émettre des alertes grâce aux fonctionnalités d'observabilité de détection des anomalies des tableaux de bord OpenSearch, et effectuer une analyse et une visualisation interactives des données à l'aide du Piped Processing Language (PPL), une interface de requête.

Amazon OpenSearch Service aborde le problème de l'observabilité, de l'analytique des traces, de l'analytique des journaux et de la surveillance des performances des applications (APM) sous quatre aspects :

Collecter : tout d'abord, vous devez collecter les données à analyser. La collecte comprend la collecte, l'enrichissement, le filtrage, la transformation et la normalisation des données provenant de plusieurs sources.

Détecter : souvent, les clients ne détectent pas les problèmes dès qu'ils surviennent. Il existe souvent un décalage entre le moment où un problème survient et celui où vous en êtes informé. Vous souhaitez donc le réduire autant que possible. La détection doit être proactive et multidimensionnelle (par exemple, des alarmes sur la télémétrie). La détection des anomalies est un outil essentiel, de même que la possibilité de relier entre elles des alarmes connexes afin de réduire la fatigue des alarmes. Un élément essentiel de la détection est également la visualisation et la surveillance, ce que fait Amazon OpenSearch Service à l'aide d'un composant nommé OpenSearch Dashboards. Vous pouvez même analyser les données de manière interactive avec des outils comme PPL.

Enquêter : l'enquête est l'activité à laquelle on consacre le plus de temps au cours d'un événement opérationnel celle qui mobilise généralement plusieurs personnes. C'est elle qui contribue le plus au temps moyen jusqu'à l'incident (MTTI) et au temps moyen de récupération (MTTR). Faire la part des choses et savoir sur quoi se concentrer demeure une tâche complexe. Utilisez les journaux, les métriques et le traçage pour vous aider à mener rapidement une analyse de la cause racine, tout en établissant une corrélation entre les métriques, les journaux et les traces sur AWS, sur site ou dans d’autres clouds. Vous pouvez collaborer sur les enquêtes et documenter votre analyse avec les blocs-notes OpenSearch Dashboard. 

Corriger : après avoir identifié la cause d'un échec, vous devez le corriger. Il n'y a rien de pire que d'essayer de réparer quelque chose et d'aggraver la situation. N'oubliez pas de procéder à une analyse post-événement afin de déterminer comment vous auriez pu éviter l'échec à l'origine. Documentez les changements proposés afin d'éviter que le problème ne se reproduise. Votre objectif doit être de faire en sorte que le même problème ne se reproduise jamais. Mais si tel est le cas, vous devez être en mesure de l'identifier et de le corriger automatiquement.

Pour l'analytique des journaux, il existe plusieurs tâches pour créer un canal d'intégration. Les producteurs sont des serveurs dorsaux, des services AWS, des serveurs web et bien d'autres encore, notamment OpenTelemetry, AWS Distro for OpenTelemetry, Jaeger et Zipkin. Les collecteurs déplacent les données depuis la source, en les transformant éventuellement localement. Pour les services AWS natifs, vous pouvez utiliser l'agent Amazon Kinesis ou l'agent Amazon CloudWatch. Pour open source, les collecteurs standard sont Elastic Beats, Fluentd, Fluentbit ou OpenTelemetry. Les agrégateurs mettent les informations provenant des collecteurs en tampon, ce qui réduit considérablement le nombre total de connexions vers Amazon OpenSearch Service. Ensuite, Amazon OpenSearch Service indexe et analyse le résultat des agrégateurs. Pour visualiser et surveiller les résultats, vous pouvez utiliser OpenSearch Dashboards ou Kibana.

Parfois, la surveillance des performances de l'application (APM) constitue le premier niveau de maturité de l'observabilité. Toutefois, l'APM ne suffit pas Votre application fonctionne-t-elle réellement comme prévu, même si tous les voyants de votre tableau de bord de surveillance des applications sont au vert ? Vos clients bénéficient-ils de l'expérience utilisateur dont ils ont besoin ? Quelle est l'utilisation de votre application ? Quels composants de votre application se heurtent à des limites d'échelle ? Dans quelle région géographique constatez-vous la croissance la plus marquée ? Quelles tendances pouvez-vous visualiser et planifier ? Si vous pouviez rassembler des métriques, vous pourriez avoir la certitude que lorsque vous déployez un nouveau code ou modifiez votre infrastructure, vous pouvez constater l'impact de ces changements. L'observabilité avance l'APM pour répondre à ces questions supplémentaires.

La fonctionnalité d'observabilité d'Amazon OpenSearch Service vous permet d'aller au-delà de la simple surveillance afin de comprendre non seulement quels événements se produisent, mais aussi pourquoi ils se produisent. Dans cet atelier, vous apprendrez à instrumenter, collecter et analyser les métriques, les traces et les données de journal, depuis les user frontends des utilisateurs jusqu'aux backends des services et tout ce qui se trouve entre les deux. Mettez cela en commun avec Amazon OpenSearch Service, AWS Distro for OpenTelemetry, FluentBit et Data Prepper.