Unité 7.2 : Observabilité et opérations

Introduction

L'observabilité sur IONOS CLOUD n'est pas un produit unique. Il s'agit de quatre plans distincts, chacun avec une portée fixe, son propre chemin d'ingestion et son propre modèle de rétention. Le travail architectural ne consiste pas à "activer la surveillance" ; il s'agit de décider quel signal atterrit dans quel plan, où se trouvent les jonctions entre les plans et comment vous créez une image opérationnelle unique à travers eux et à travers les contrats.

FinCorp, notre société financière allemande sous obligations GDPR et BSI, a besoin d'une vue opérationnelle d'audit de classe qui couvre un noyau de charge de travail réglementé, une plateforme Managed Kubernetes et un domaine VMware dédié, ce qui expose chaque jonction du modèle de télémétrie de la plateforme. Cette unité parcourt les quatre plans, nomme les lacunes honnêtement, crée un pipeline de métriques avec une alerte et un journal de flux dans le Data Center Designer, et se termine sur le modèle de fan-in qui donne à FinCorp un seul endroit pour corréler.

1. Les quatre plans de télémétrie et leurs portées fixes

La plateforme divise le signal opérationnel en quatre produits. Aucun d'entre eux n'est un sur-ensemble des autres, et les limites sont rigides, et non des conventions.

Métriques (Monitoring Service). Un service par contrat, par région qui ingère des métriques au format Prometheus (Compteur, Jauge, Histogramme, Résumé), avec une alternative JSON qui doit être compressée à l'aide de Snappy. Les métriques sont poussées par un agent : Prometheus, Grafana Agent, OpenTelemetry ou Fluent Bit, à un intervalle de poussée par défaut de 1 minute qui peut être configuré. Derrière le point de terminaison, les données atterrissent dans Grafana Mimir et sont visualisées dans une instance Grafana gérée avec une portée par contrat et par région. Vous pouvez exécuter jusqu'à 10 pipelines par contrat.

Journaux (Logging Service). Un service par contrat, par région qui ingère des flux de journaux à partir d'un ensemble fixe de sources : Kubernetes, Docker, Linux Systemd, HTTP (une API REST JSON), et Générique. Le transport est TLS sur TCP (Fluent Bit forward, port 9000) ou HTTPS (port 443). Chaque pipeline transporte jusqu'à 5 flux de journaux, vous pouvez exécuter jusqu'à 10 pipelines par contrat, et la rétention par flux est de 7, 14, 30 jours ou illimitée (par défaut 30). Les journaux apparaissent dans la même instance Grafana gérée, mais la fenêtre de requête Grafana est de 30 jours ; tout ce qui est conservé sous rétention illimitée est lu à nouveau en soumettant une demande d'assistance, et non dans le tableau de bord.

Audit (Activity Logs). La traînée d'audit du plan de contrôle : qui a fait quoi à quelle ressource. Elle enregistre les connexions d'utilisateurs, les mises à disposition de ressources, les modifications de configuration, l'accès aux données et les récupérations, modifications et suppressions de ressources. Elle est en lecture seule par conception, chaque appel est un GET contre https://api.ionos.com/activitylog/v1, et la rétention est de 35 jours. Il s'agit d'un plan de gouvernance, couvert en profondeur dans l'Unité 2.3 ; ici cela compte car sa courte fenêtre force une discipline d'exportation que les plans de métriques et de journaux ne possèdent pas.

Flux réseau (Flow Logs). Des enregistrements de connexion par flux (5-uplet plus comptage de paquets et d'octets, plus un champ action d'ACCEPT ou REJECT montrant le verdict du pare-feu) émis vers un bucket Object Storage appartenant au client sous forme de texte compressé gzip, rotatif toutes les 10 minutes. Les Flow Logs sont attachés à une carte réseau VM, à un Managed Network Load Balancer, à un Managed Application Load Balancer ou à un Managed NAT Gateway, et capturent IPv4 et IPv6. Ce plan est construit dans l'Unité 3.2 en tant qu'outil de vérification du pare-feu ; il réapparaît ici comme la jambe du réseau du tableau opérationnel.

La surface unifiante est Grafana : les métriques et les journaux sont tous deux interrogables via une instance Grafana gérée par contrat et par région. Le point de conception délibéré est que les données d'audit et de flux réseau vivent entièrement en dehors de cette interface utilisateur, dans l'API Activity Log et dans Object Storage respectivement. Une vue opérationnelle complète est quelque chose que vous assemblez, et non quelque chose que la console vous donne.

2. Les lacunes à contourner lors de la conception

Trois limites sont celles qui posent problème en production. Chacune est une entrée de conception, et non un défaut, et chacune a une composition native autour d'elle.

Les événements du plan de contrôle Kubernetes ne transitent pas par le Logging Service. Le Logging Service répertorie Kubernetes comme une source prise en charge, mais cela signifie que les journaux de charge de travail et de nœud que vous envoyez depuis l'intérieur du cluster, et non le plan de contrôle géré. Le SLA IONOS CLOUD Managed Kubernetes ne couvre que l'API Kubernetes du plan de contrôle, et les événements du plan de contrôle ne sont pas émis dans votre pipeline Logging Service. Le cluster propose un commutateur "Logging to S3" distinct qui écrit les données de journal du cluster dans un bucket Object Storage ; traitez-le comme un chemin distinct, activé séparément, et non comme une visibilité du plan de contrôle dans votre Grafana. Pour la visibilité des charges de travail, vous déployez un agent intra-cluster (Fluent Bit pour les journaux, un exportateur compatible Prometheus pour les métriques) qui pousse vers vos pipelines Logging et Monitoring. La couture est la ligne entre le plan de contrôle géré et vos charges de travail : vous instrumentez les secondes, IONOS CLOUD exploite le premier.

Il n'y a pas d'agrégation inter-contrat. Les pipelines Monitoring et Logging sont par contrat et par région, et le journal d'activité est par contrat sans point de terminaison d'agrégation. Si FinCorp divise la production, la non-production et une charge de travail isolée pour des raisons de conformité en plusieurs contrats (la discipline des limites à partir de l'Unité 2.1), il n'y a pas de volet natif qui réunit leur télémétrie. L'agrégation est quelque chose que vous construisez, en éventail chaque signal de contrat vers un collecteur externe (Section 5).

La fenêtre de rétention du journal d'activité est de 35 jours. C'est l'horizon de suppression définitive pour la piste d'audit. Pour une entreprise réglementée dont les obligations de rétention s'étendent sur des années, la fenêtre de 35 jours est une date limite d'exportation, et non une politique de rétention. Le modèle documenté à long terme consiste à télécharger les données du journal d'activité selon un calendrier et à les stocker sur un stockage différent, avec IONOS Cloud Object Storage comme cible recommandée explicitement, idéalement sous verrouillage d'objet pour un archive tampon-évident (Unité 2.3, Unité 5.2). Manquez cette fenêtre et l'enregistrement disparaît.

3. Journalisation centralisée et observabilité hybride vCenter

3.1 Journalisation centralisée pour le transfert initié par les produits

Par défaut, vous envoyez les journaux vous-même en pointant un agent vers un point de terminaison de pipeline. La journalisation centralisée est l'interrupteur au niveau du contrat, par région, qui permet aux produits IONOS CLOUD intégrés d'envoyer leurs propres journaux au Logging Service en votre nom, affiché dans le même Grafana géré, sans que chaque produit exécute une pile d'ingestion distincte. Un Managed Network Load Balancer, par exemple, envoie ses journaux d'accès à votre Logging Service une fois que la journalisation centralisée est activée. Le même modèle s'étend à la surveillance centralisée pour le Monitoring Service.

La journalisation centralisée doit être activée avant qu'un produit ne puisse ingérer en votre nom, car elle affecte à la fois votre vue opérationnelle et votre facturation. L'activation est par région, et seuls les administrateurs de contrat, les propriétaires et les utilisateurs avec le privilège « Accéder et gérer le Logging Service » peuvent basculer celui-ci. Il peut être activé à partir du DCD (un interrupteur d'état par région dans la vue de journalisation centralisée du Logging Service), à partir de l'API de journalisation ou par un produit intégré en votre nom. Les produits qui intègrent sont confirmés via votre gestionnaire de compte ou le support IONOS CLOUD plutôt que publiés sous forme de liste statique, donc traitez l'ensemble pris en charge comme quelque chose à vérifier par engagement.

3.2 Observabilité vCenter pour le patrimoine dédié-VMware

Le noyau réglementé de FinCorp s'exécute sur IONOS CLOUD Private Cloud, le SDDC VMware géré dédié (Unité 4.4). Ses télémétries ne s'écoulent pas dans les quatre plans de plateforme. Au lieu de cela, l'observabilité pour ce patrimoine est l'outillage natif VMware qui est livré avec la pile dédiée : vCenter Server 8.0 pour les graphiques de performances hôte, cluster et VM, les événements et les alarmes, ainsi que la surveillance de la santé et de la capacité vSAN exposée dans le Cloud Panel pour la couche de stockage. L'API REST vSphere (limitée à 100 requêtes par seconde) est la couture programmatique si vous souhaitez extraire ces données vers l'extérieur.

N'énoncez que ce que la matrice prend en charge ici : la surface d'observabilité dédiée-VMware est vCenter et vSAN. Ne supposez pas un pont géré inter-plans qui ingère des alarmes vCenter dans le Logging Service ; aucun n'est documenté. Pour un patrimoine hybride, le modèle honnête est constitué de deux domaines d'observabilité s'exécutant côte à côte, les quatre plans de plateforme pour les ressources cloud natives et vCenter/vSAN pour le noyau VMware dédié, réconciliés uniquement lorsque vous transférez délibérément les deux dans un collecteur externe commun.

4. Démarche de mise en œuvre de DCD

Vous allez configurer la partie métriques de la vue opérationnelle de FinCorp et la partie flux réseau : un pipeline de métriques avec une alerte, et un journal de flux sur le Load Balancer situé à la limite du réseau. Cela met en œuvre deux des quatre plans présentés dans la Section 1 et vous fournit des points de terminaison concrets pour les agents. La troisième partie, les journaux, suit le même modèle de pipeline dans le DCD.

Objectif de construction : Créer un pipeline de métriques avec une alerte et activer les journaux de flux.

Prérequis. Un bucket Object Storage existant dans la région cible que vous possédez (la destination du journal de flux doit être un bucket appartenant à l'utilisateur). Le privilège "Créer des journaux de flux" pour le travail de journal de flux, et le privilège "Accéder et gérer le Monitoring Service" pour le pipeline de métriques. La sortie HTTPS sur le port 443 depuis l'emplacement où vos agents de métriques s'exécutent.

Partie A : le pipeline de métriques (Monitoring Service). Le pipeline de métriques du Monitoring Service peut être créé à partir d'un formulaire de création DCD ou via l'API du Monitoring Service, et le DCD fournit également un accès au Grafana résultant. Le cycle de vie complet du pipeline (créer, récupérer, modifier, supprimer) est disponible via l'API, qui est le chemin utilisé ci-dessous avant de passer à Grafana pour les alertes.

1. Choisissez le point de terminaison régional qui correspond à votre emplacement de données, par exemple https://monitoring.de-txl.ionos.com/pipelines pour Berlin. La région détermine où les métriques sont traitées et stockées, donc gardez-la cohérente avec la décision de résidence de la charge de travail.
2. Créez le pipeline avec un PUT (ou POST) vers ce point de terminaison transportant un properties.name, authentifié avec un jeton Bearer. La réponse comprend une clé unique key dans ses métadonnées et un grafanaEndpoint. Enregistrez la clé lors de la création ; pour des raisons de sécurité, elle n'est pas renvoyée à nouveau, et vous ne pouvez pas envoyer des métriques sans elle.
3. Configurez un agent de métriques (Prometheus, Grafana Agent, OpenTelemetry ou Fluent Bit) pour envoyer des données au point de terminaison HTTP du pipeline avec api/v1/push ajouté au chemin, en envoyant la clé enregistrée comme en-tête d'autorisation Bearer sur le port 443. Les métriques arrivent à l'intervalle par défaut de 1 minute, sauf si vous le modifiez.
4. Ouvrez le Grafana géré à l'adresse renvoyée grafanaEndpoint et confirmez que les métriques sont interrogables, ce qui vérifie l'ingestion de bout en bout.
5. Créez l'alerte à l'intérieur de Grafana : définissez une règle d'alerte sur la métrique qui vous intéresse (pour le niveau d'application sans état de FinCorp, un seuil d'utilisation du CPU qui devrait précéder une action d'auto-mise à l'échelle), et attachez un point de contact afin que la règle notify le canal d'appel. L'alerte Grafana est la surface d'alerte ; il n'y a pas d'objet d'alerte IONOS CLOUD séparé pour le plan des métriques.

Un appel créatif illustratif (le point architectural est que ce plan est provisionné via l'API, et non via la console) :

curl --location --request POST 'https://monitoring.de-txl.ionos.com/pipelines' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer $TOKEN' \
  --data '{ "properties": { "name": "fincorp-app-metrics" } }'

Partie B : le journal d'écoulement (DCD). Cette étape est une véritable construction DCD, attachée à une ressource que vous possédez déjà depuis le Module 3.

6. Dans le DCD, ouvrez le centre de données, sélectionnez la ressource de bord dont vous souhaitez enregistrer le trafic. Pour un serveur ou un Cube, ouvrez l'onglet Réseau et les propriétés du contrôleur de réseau (NIC) ; pour un Managed Network Load Balancer, Managed Application Load Balancer ou Managed NAT Gateway, ouvrez l'onglet Paramètres dans le volet Inspector.
7. Ouvrez le menu déroulant du journal d'écoulement et créez une règle. Définissez un nom (il devient également la première partie du préfixe de nom d'objet Object Storage), donc nommez-le pour la ressource et l'environnement.
8. Définissez la direction à Entrant, Sortant ou Bidirectionnel, et l'action à Rejeté, Accepté ou Tout. Pour une posture d'investigation de sécurité, Bidirectionnel plus Rejeté affiche ce que le pare-feu bloque ; pour l'analyse de capacité et de connexion, Accepté est l'ensemble utile.
9. Définissez le bucket Object Storage cible à votre bucket existant appartenant à l'utilisateur dans la région. Enregistrez. Les enregistrements commencent à arriver sous forme d'objets .log.gz, tournés tous les 10 minutes.
10. Appliquez une politique de cycle de vie sur ce bucket pour faire vieillir les objets de journal d'écoulement, car les journaux d'écoulement n'ont pas de rétention intégrée : la rétention est entièrement gérée par le client via une politique de cycle de vie Object Storage ou une suppression manuelle.

Erreurs courantes :

• Ne pas enregistrer la clé de pipeline de surveillance lors de la création. La clé est renvoyée une seule fois et jamais à nouveau. La perdre signifie recréer le pipeline. La même règle de clé unique s'applique à un pipeline Logging Service.
• Traiter « Kubernetes » dans la liste des sources Logging Service comme visibilité du plan de contrôle. Il s'agit uniquement des journaux de charge de travail dans le cluster ; les événements du plan de contrôle n'y arrivent jamais. Déployez un agent dans le cluster et n'attendez pas des événements qui n'arriveront pas.
• Supposer que la rétention des journaux d'écoulement est gérée pour vous. La suppression de la règle de journal d'écoulement ne supprime pas les objets déjà écrits, et il n'y a pas d'expiration automatique. Sans politique de cycle de vie du bucket, l'archive grandit et facture indéfiniment.
• Pointer un journal d'écoulement vers un bucket que vous ne possédez pas ou situé dans la mauvaise région. La destination doit être un bucket appartenant à l'utilisateur ; une cible incorrecte échoue silencieusement à livrer les enregistrements.
• Oublier la fenêtre de 35 jours du journal d'activité. Il ne s'agit pas d'une rétention, mais d'un horizon de suppression. Planifiez l'exportation vers Object Storage avant le jour 35, sinon l'enregistrement d'audit est irrécupérable.

5. Fan-In vers un SIEM externe

Pour une entreprise comme FinCorp, le modèle à quatre plans, par contrat et par région, ne produit pas la vue corrélée unique dont a besoin une équipe d'opérations de sécurité et un auditeur. Le modèle d'entreprise est fan-in : chaque plan de chaque contrat s'écoule dans un SIEM externe unique qui devient le système d'enregistrement pour la corrélation, la rétention à long terme et l'alerte sur l'ensemble du patrimoine. La plateforme vous donne les moyens de le faire sans forwarder géré :

• Journaux et métriques : dirigez vos agents (ou les forwarders initiés par produit de Central Logging) vers les pipelines IONOS CLOUD pour Grafana sur la plateforme, et en parallèle, transférez les mêmes flux de vos agents au collecteur SIEM. Le Logging Service expose également une API Telemetry en lecture seule (authentifiée avec le même jeton d'API Cloud) que le SIEM peut interroger, bien que l'envoi dual côté agent soit l'itinéraire le plus direct.
• Flux réseau : les Flow Logs atterrissent déjà dans l'Object Storage sous forme de texte gzip ; le SIEM les ingère à partir du bac, qui sert également d'archive durable.
• Audit : un travail planifié extrait le journal d'activité via son API GET uniquement avant que la fenêtre de 35 jours ne se ferme, puis transfère les enregistrements dans le SIEM, satisfaisant ainsi à la fois la rétention à long terme et la corrélation entre contrats.
• Hybrid VMware : l'API REST vSphere et les alarmes vCenter sont transférées à partir du patrimoine dédié vers le même SIEM, réunissant ainsi les deux domaines d'observabilité au point où l'unification est significative.

C'est la même leçon de composition que la plateforme répète ailleurs : il n'y a pas de produit d'agrégation géré entre contrats, vous devez donc en composer un. L'Object Storage est le hub durable, le SIEM est le cerveau de corrélation, et les points de terminaison par plan sont les robinets.

Résumé

L'observabilité d'IONOS CLOUD est constituée de quatre plans à portée fixe (métriques via le Monitoring Service, journaux via le Logging Service, audit via les Activity Logs et flux réseau via les Flow Logs) unifiés uniquement partiellement, dans Grafana, avec des données d'audit et de flux vivant en dehors de ce panneau par conception. Le travail opérationnel porteur de charge consiste à router chaque signal de manière délibérée, en concevant autour des trois lacunes (pas d'événements de plan de contrôle dans le plan de journalisation, pas d'agrégation inter-contrat, une fenêtre d'audit de 35 jours), en utilisant la journalisation centralisée pour le transfert initié par les produits, en traitant le domaine dédié VMware comme un domaine d'observabilité vCenter/vSAN distinct, et en dirigeant tout vers un SIEM externe où la corrélation et la rétention à long terme se produisent réellement.

Points clés :

• Quatre plans, portées fixes : Monitoring Service (métriques Prometheus, basé sur le push, Grafana Mimir), Logging Service (cinq types de sources, 5 flux par pipeline, rétention de 7/14/30/jours illimités), Activity Logs (lecture seule GET, fenêtre de 35 jours), Flow Logs (enregistrements 5-uplets vers un bucket Object Storage appartenant à l'utilisateur, rétention gérée par le client).
• Le pipeline métrique du Monitoring Service peut être créé à partir d'un formulaire de création DCD ou via l'API ; la clé du pipeline doit être sauvegardée lors de la création.
• Les événements de plan de contrôle Kubernetes n'atteignent jamais le Logging Service ; instrumentez les charges de travail avec un agent dans le cluster et traitez le cluster « Logging to S3 » comme un chemin distinct.
• Il n'y a pas d'agrégation inter-contrat et la trace d'audit est supprimée au bout de 35 jours, donc l'agrégation et la rétention à long terme sont construites à l'extérieur, avec Object Storage comme hub durable et un SIEM comme point de corrélation.
• La journalisation centralisée est une fonctionnalité au niveau du contrat et par région (contrôlée par l'administrateur) qui permet aux produits intégrés d'Ionos Cloud d'envoyer des journaux pour vous ; le domaine dédié VMware est observé via vCenter 8.0 et vSAN, un domaine distinct réconcilié uniquement au niveau du SIEM.

Terminologie importante :

• Plan de télémétrie : l'un des quatre produits d'observabilité à portée fixe (métriques, journaux, audit, flux réseau), chacun ayant son propre chemin d'ingestion et son modèle de rétention.
• Journalisation centralisée : une fonctionnalité au niveau du contrat et par région qui permet aux produits intégrés IONOS CLOUD d'envoyer leurs journaux au Logging Service en votre nom, présenté dans le Grafana géré.
• Journal de flux : une règle par ressource émettant des enregistrements de connexion 5-uplets avec le verdict ACCEPT/REJECT du pare-feu vers un bucket Object Storage appartenant au client, rotatif toutes les 10 minutes.
• Fan-in : le modèle d'agrégation d'entreprise consistant à transférer chaque plan à partir de chaque contrat vers un SIEM externe unique pour la corrélation inter-contrat et la rétention à long terme.

Lecture supplémentaire

• Unité 2.3 : Activity Logs et la traçabilité des audits (le plan d'audit et la date limite d'exportation)
• Unité 3.2 : Sécurité du réseau : pare-feu et groupes de sécurité (journaux de flux en tant qu'outil de vérification du pare-feu)
• Unité 4.4 : Private Cloud (VMware dédié) (le domaine dédié observé via vCenter et vSAN)
• Unité 6.1 : Conception de la plateforme Kubernetes (pourquoi les événements du plan de contrôle se situent en dehors du plan de journalisation)
• Centre d'architecture IONOS CLOUD