Cloud
C'est la deuxième partie d'un blog en deux parties. Dans la première partie, nous avons expliqué comment le monitoring et l'observabilité vont de pair. Dans cet article, nous décrivons comment nous mettons en œuvre l'observabilité et le monitoring des services Public Cloud (PCMS) pour nos clients dans le cadre de notre offre de prestations Managed Services.
Pour commencer, je voudrais dire que le paysage de l'infrastructure et des applications de nos clients évolue constamment. Tout comme la clientèle et la diversité augmentent, l'adaptation des produits au marché augmente également. Parmi nos défis, il y a l'onboarding de nouveaux clients, ce qui signifie presque toujours trouver comment surveiller de nouvelles prestations de service et applications dans le Cloud, parfois dans un environnement natif et parfois dans un environnement hybride.
Une image dans l'image vaut mille mots. Le diagramme ci-dessus montre les détails de l'observabilité et du paysage du monitoring chez PCMS pour Azure (nous avons aussi des clients AWS, mais c'est un autre billet de blog pour un autre jour).
Le premier niveau, la télémétrie, se trouve en haut à droite. Il s'agit des sources de données de nos clients cloud public, comme les différents types de protocoles des ressources cloud PaaS et SaaS, par exemple les journaux d'activité ou les protocoles de connexion collectés avec EventHub, et leurs métriques collectées par Azure Monitor. De plus, les ressources IaaS envoient leurs métriques et leurs protocoles directement à notre pile Elastic à l'aide d'agents Beats et collectent également les protocoles de gestion et d'activité des offres cloud d'O365 et M365 pour fournir des solutions d'observation et de monitoring du domaine de travail cloud. Enfin, il faut mentionner la tendance aux scénarios hybrides, dans lesquels nos clients connectent leurs différents clouds et infrastructures sur site. Nous collectons les protocoles et les métriques de certains moyens d'exploitation, parfois directement et parfois via des offres cloud publiques comme Azure Arc et AWS Outpost.
Le deuxième niveau est celui de la conservation des données. Avant de l'aborder, il est important de comprendre l'importation des données. Il existe deux endpoints pour l'entrée des données. Ils peuvent être facilement divisés en modes push et pull. Nos auxiliaires Metricbeat et Filebeat fonctionnent sur l'infrastructure Kubernetes et extraient les métriques, les logs et les traces des clouds publics. Cela concerne principalement les moyens d'exploitation PaaS et SaaS. Les protocoles d'activité font exception et s'appliquent à tous les types de moyens d'exploitation. Le deuxième endpoint pour l'ingestion est notre Elastic Ingest Node, qui se trouve directement dans notre Elastic Stack. Les auxiliaires qui fonctionnent sur des appliances IaaS ou parfois sur des appliances cloud informatisées envoient leurs métriques, logs et traces directement à notre Elastic Stack. Dès que les données sont lues, elles sont stockées dans des index Lucene dans le backend. La rétention des données dépend du type de données et du business case. Elle peut cependant être configurée pour chaque jeu de données afin de soutenir les clients ayant des besoins spécifiques en matière de rétention.
Le troisième et dernier niveau est celui des performances réelles; c'est là que la magie opère. La première partie est le monitoring de l'état des différents composants, qui est dérivé des profils de monitoring. Un profil de monitoring typique contient plus d'un des composants ci-dessous:
Une autre performance de notre pile d'observabilité et de monitoring est de permettre aux équipes d'exploitation de comprendre les changements. Grâce à la possibilité d'interroger directement les ensembles de données sous-jacents, qui se composent de toutes sortes de protocoles et de métriques, les équipes d'exploitation peuvent répondre à la question "Qu'est-ce qui a provoqué le changement ? Cela peut se résumer ainsi:
Ou: "Quels sont les effets de ce changement?" Cela peut se résumer comme suit:
Pour reprendre le dernier mot de la première partie de la série de spécifications : le monitoring et l'observabilité vont de pair, l'un ne remplace pas l'autre, mais permet et améliore les résultats de l'entreprise définis ensemble. Ceci est la deuxième partie d'un blog en deux parties. La première partie, qui explique comment le monitoring et l'observabilité vont de pair, est disponible ici(ouvre une nouvelle fenêtre).
DevOps Engineer
Trouve le Job ou l’univers professionnel qui te convient. Où tu veux co-créer et évoluer.
Ce qui nous définit, c’est toi.
