19 min de lecture

Objectifs d'apprentissage

À la fin de ce module, vous serez en mesure de:

  • Associer les quatre plans de télémétrie IONOS CLOUD (métriques, journaux, audit, flux réseau) à leurs périmètres fixes et d'acheminer chaque signal de manière délibérée, plutôt que de vous attendre à ce qu'un seul panneau de console affiche tout
  • Concevoir en tenant compte des trois lacunes d'observabilité qui piègent les équipes en production : les événements du plan de contrôle Kubernetes qui n'atteignent jamais le Logging Service, l'absence d'agrégation inter-contrats, et la fenêtre de conservation de 35 jours du journal d'activité
  • Utiliser la journalisation centralisée afin que les produits intégrés transmettent leurs propres journaux sans que chacun ne doive exécuter une pile d'ingestion distincte
  • Positionner l'observabilité de vCenter VMware dédié aux côtés des plans de la plateforme pour un parc hybride
  • Construire un pipeline de métriques avec une alerte et activer un journal de flux dans Data Center Designer, et diffuser la télémétrie vers un SIEM externe en tant que modèle d'agrégation d'entreprise

Unité 7.2 : Observabilité et opérations

Introduction

L'observabilité sur IONOS CLOUD ne constitue pas un produit unique. Elle se compose de quatre plans distincts, chacun ayant un périmètre 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éterminer quel signal est acheminé vers quel plan, où se situent les jonctions entre les plans, et comment assembler une vue opérationnelle unifiée à travers ces plans et à travers les contrats.

FinCorp, notre entreprise allemande de services financiers soumise aux obligations RGPD et BSI, a besoin d'une vue opérationnelle de niveau audit couvrant un noyau de charge de travail régulé, une plateforme Managed Kubernetes et un parc VMware dédié, ce qui met en évidence chaque jonction du modèle de télémétrie de la plateforme. Cette unité examine les quatre plans, identifie honnêtement les lacunes, construit un pipeline de métriques avec une alerte et un journal de flux dans Data Center Designer, et se conclut sur le motif de convergence qui permet à FinCorp de disposer d'un point unique de corrélation.

1. Les quatre plans de télémétrie et leurs périmètres fixes

La plateforme répartit le signal opérationnel sur quatre produits. Aucun d'entre eux n'est un sur-ensemble des autres, et les frontières sont rigides, et non des conventions.

Métriques (Monitoring Service). Un service par contrat et par région qui ingère des métriques au format Prometheus (Counter, Gauge, Histogram, Summary), 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, avec un intervalle de poussée par défaut de 1 minute, configurable. Derrière le point d'accès, les données sont stockées dans Grafana Mimir et visualisées dans une instance Grafana managée, limitée par contrat et par région. Vous pouvez exécuter jusqu'à 10 pipelines par contrat.

Journaux (Logging Service). Un service par contrat et 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 assuré par 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 ou 30 jours, ou illimitée (30 jours par défaut). Les journaux s'affichent dans la même instance Grafana managée, mais la fenêtre de requête Grafana est de 30 jours ; tout élément conservé au-delà de cette durée en mode illimité est récupéré par le biais d'une demande d'assistance, et non via le tableau de bord.

Audit (Activity Logs). La piste d'audit du plan de contrôle : qui a fait quoi sur quelle ressource. Elle enregistre les connexions des utilisateurs, le provisionnement des ressources, les modifications de configuration, l'accès aux données, ainsi que les récupérations, modifications et suppressions de ressources. Elle est en lecture seule par conception, chaque appel est un GET vers https://api.ionos.com/activitylog/v1, et la rétention est de 35 jours. Il s'agit d'un plan de gouvernance, traité en profondeur dans l'Unité 2.3 ; ici, il est important car sa fenêtre courte impose une discipline d'exportation que les plans de métriques et de journaux n'imposent pas.

Flux réseau (Flow Logs). Des enregistrements de connexion par flux (5-uplet, plus les compteurs de paquets et d'octets, ainsi qu'un champ action de type ACCEPT ou REJECT indiquant la décision du pare-feu), émis vers un bucket Object Storage appartenant au client, au format texte compressé gzip, avec rotation toutes les 10 minutes. Les Flow Logs sont associés à une carte réseau de VM, à un Managed Network Load Balancer, à un Managed Application Load Balancer ou à un Managed NAT Gateway, et capturent les adresses 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 le volet au niveau réseau de la vue opérationnelle.

La surface unificatrice est Grafana : les métriques et les journaux sont tous deux interrogeables via une seule instance Grafana managé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, respectivement dans l'API Activity Log et dans Object Storage. Une vue opérationnelle complète est quelque chose que vous assemblez, et non quelque chose que la console vous fournit.

2. Les limites à prendre en compte dans la conception

Trois frontières sont celles qui posent problème en production. Chacune constitue une donnée de conception, et non un défaut, et chacune dispose d'une composition native qui l'entoure.

Les événements du plan de contrôle Kubernetes ne transitent pas par le Logging Service. Le Logging Service répertorie Kubernetes comme source prise en charge, mais cela signifie les journaux des charges de travail et des nœuds que vous envoyez depuis l'intérieur du cluster, et non le plan de contrôle géré. Le SLA du Managed Kubernetes d'IONOS CLOUD 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 interrupteur distinct « Logging to S3 » qui écrit les données de journaux du cluster dans un bucket Object Storage ; considérez cela comme un chemin distinct, activé séparément, et non comme une visibilité du plan de contrôle dans votre Grafana. Pour l'observabilité des charges de travail, vous déployez un agent au sein du cluster (Fluent Bit pour les journaux, un exporteur compatible Prometheus pour les métriques) qui pousse vers vos pipelines de surveillance et de journalisation. La frontière se situe entre le plan de contrôle géré et vos charges de travail : vous instrumentez ces dernières, IONOS CLOUD exploite le premier.

Il n'existe aucune agrégation inter-contrat. Les pipelines de surveillance et de journalisation sont par contrat et par région, et le journal d'activité est par contrat, sans poussée ni point d'agrégation. Si FinCorp répartit la production, la non-production et une charge de travail isolée pour la conformité sur des contrats distincts (la discipline des frontières de l'Unité 2.1), il n'existe aucun panneau natif qui unisse leur télémétrie. L'agrégation est quelque chose que vous construisez, en diffusant le signal de chaque contrat vers un collecteur externe unique (Section 5).

La fenêtre de rétention du journal d'activité est de 35 jours. C'est l'horizon de suppression définitif pour la piste d'audit. Pour une entreprise soumise à réglementation 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 à long terme documenté 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 explicitement recommandée, idéalement sous verrouillage d'objet pour une archive infalsifiable (Unité 2.3, Unité 5.2). Si vous manquez la fenêtre, l'enregistrement est perdu.

3. Journalisation centralisée et observabilité vCenter hybride

3.1 Journalisation centralisée pour la transfert initié par le produit

Par défaut, vous envoyez vous-mêmes les journaux 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 intégrés d'IONOS CLOUD de transférer leurs propres journaux vers le Logging Service en votre nom, affichés dans le même Grafana managé, sans que chaque produit n'exécute une pile d'ingestion distincte. Un Managed Network Load Balancer, par exemple, envoie ses journaux d'accès à votre Logging Service dès 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'aucun produit puisse effectuer une ingestion en votre nom, car elle affecte à la fois votre vue opérationnelle et votre facturation. L'activation est effectuée par région, et seuls les administrateurs de contrat, les propriétaires et les utilisateurs disposant du privilège « Access and manage Logging Service » peuvent l'activer ou la désactiver. Elle peut être activée depuis le DCD (un interrupteur d'état par région dans la vue Journalisation centralisée du Logging Service), depuis l'API Logging, ou par un produit intégré en votre nom. Les produits qui sont intégrés sont confirmés par votre gestionnaire de compte ou le support IONOS CLOUD, plutôt que publiés sous forme de liste statique, il convient donc de considérer l'ensemble pris en charge comme quelque chose à vérifier pour chaque collaboration.

3.2 Observabilité vCenter pour le parc VMware dédié

Le cœur régulé de FinCorp fonctionne sur IONOS CLOUD Private Cloud, le SDDC VMware managé dédié (Unité 4.4). Sa télémétrie ne s'écoule pas dans les quatre plans de la plateforme. À la place, l'observabilité pour ce parc est constituée des outils natifs VMware livrés avec la pile dédiée : vCenter Server 8.0 pour les graphiques de performance, les événements et les alarmes des hôtes, des clusters et des VM, ainsi que la surveillance de santé et de 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 le point d'entrée programmatique si vous souhaitez extraire ces données vers l'extérieur.

Ne décrivez ici que ce que la matrice prend en charge : la surface d'observabilité du VMware dédié est vCenter et vSAN. Ne supposez pas un pont inter-plans managé qui ingère les alarmes vCenter dans le Logging Service ; aucun n'est documenté. Pour un parc hybride, le modèle honnête est celui de deux domaines d'observabilité fonctionnant côte à côte, les quatre plans de la plateforme pour les ressources cloud natives et vCenter/vSAN pour le cœur VMware dédié, réconciliés uniquement là où vous transférez délibérément les deux vers un collecteur externe commun.

4. Déroulement de la mise en œuvre de DCD

Vous allez mettre en place le volet métriques de la vue opérationnelle de FinCorp et le volet flux réseau : un pipeline de métriques avec une alerte, et un journal de flux sur l'équilibreur de charge frontal. Cela concrétise deux des quatre plans de la section 1 et vous fournit des points d'ingestion concrets vers lesquels orienter les agents. Le troisième volet, 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, dont vous êtes propriétaire (la destination du journal de flux doit être un bucket appartenant à l'utilisateur). Le privilège « Create Flow logs » pour le travail sur les journaux de flux, et le privilège « Access and manage Monitoring » pour le pipeline de métriques. Sortie HTTPS sur le port 443 depuis l'endroit 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 offre également un accès à l'instance Grafana résultante. Le cycle de vie complet du pipeline (création, récupération, modification, suppression) est disponible via l'API, qui est le chemin utilisé ci-dessous avant de passer à Grafana pour la gestion des alertes.

  1. Choisissez le point d'accès régional qui correspond à l'emplacement de vos 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, il convient donc de la garder cohérente avec la décision de résidence de la charge de travail.
  2. Créez le pipeline avec une PUT (ou POST) vers ce point d'accès, portant une properties.name, authentifiée par un jeton Bearer. La réponse contient une key à usage unique dans ses métadonnées et une 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 de métriques sans elle.
  3. Configurez un agent de métriques (Prometheus, Grafana Agent, OpenTelemetry ou Fluent Bit) pour envoyer les données vers le point d'accès HTTP du pipeline avec api/v1/push ajouté au chemin, en envoyant la clé enregistrée en tant qu'en-tête d'autorisation Bearer sur le port 443. Les métriques arrivent à un intervalle par défaut de 1 minute, sauf si vous le modifiez.
  4. Ouvrez l'instance Grafana gérée à l'adresse grafanaEndpoint renvoyée et vérifiez que les métriques sont interrogeables, ce qui valide l'ingestion de bout en bout.
  5. Créez l'alerte dans Grafana : définissez une règle d'alerte sur la métrique qui vous intéresse (pour la couche applicative sans état de FinCorp, un seuil d'utilisation du CPU qui devrait précéder une action de mise à l'échelle automatique), et attachez un point de contact afin que la règle notifie le canal de garde. L'alerting Grafana constitue la surface d'alerte ; il n'existe pas d'objet d'alerte IONOS CLOUD distinct pour le plan des métriques.

Un appel de création illustratif et succinct (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 de flux (DCD). Cette étape constitue une véritable construction DCD, attachée à une ressource que vous possédez déjà depuis le Module 3.

  1. Dans le DCD, ouvrez le centre de données, puis sélectionnez la ressource d'extrémité 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 réseau (carte réseau) ; pour un Managed Network Load Balancer, un Managed Application Load Balancer ou un Managed NAT Gateway, ouvrez l'onglet Paramètres dans le panneau Inspecteur.
  2. Ouvrez la liste déroulante Flow Log et créez une règle. Définissez un Nom (il devient également la première partie du préfixe du nom d'objet du bucket Object Storage), nommez-le donc en fonction de la ressource et de l'environnement.
  3. Définissez Direction sur Ingress, Egress ou Bidirectional, et Action sur Rejected, Accepted ou Any. Pour une posture d'investigation de sécurité, Bidirectional associé à Rejected met en évidence ce que le pare-feu bloque ; pour l'analyse de la capacité et des connexions, Accepted est le jeu de données utile.
  4. Définissez le bucket Object Storage cible sur votre bucket existant appartenant à l'utilisateur dans la région. Enregistrez. Les enregistrements commencent à arriver sous forme d'objets .log.gz, avec une rotation toutes les 10 minutes.
  5. Appliquez une politique de cycle de vie sur ce bucket pour éliminer les objets du journal de flux, car les Flow Logs ne disposent d'aucune rétention intégrée : la rétention est entièrement gérée par le client via une Object Storage Lifecycle Policy ou une suppression manuelle.

Erreurs courantes :

  • Ne pas enregistrer la clé du pipeline de surveillance lors de la création. La clé est renvoyée une seule fois et jamais à nouveau. Si vous la perdez, vous devez recréer le pipeline. La même règle de clé unique s'applique à un pipeline Logging Service.
  • Considérer « Kubernetes » dans la liste des sources Logging Service comme une visibilité sur le plan de contrôle. Il s'agit uniquement de vos journaux de charge de travail au sein du cluster ; les événements du plan de contrôle n'y arrivent jamais. Déployez un agent au sein du cluster et n'attendez pas des événements qui ne viendront pas.
  • Supposer que la rétention des journaux de flux est gérée pour vous. La suppression de la règle du journal de flux ne supprime pas les objets déjà écrits, et il n'y a aucune expiration automatique. Sans politique de cycle de vie du bucket, l'archive grandit et génère des factures indéfiniment.
  • Pointer un journal de flux vers un bucket que vous ne possédez pas ou vers un bucket dans la mauvaise région. La destination doit être un bucket appartenant à l'utilisateur ; une mauvaise cible entraîne un échec silencieux de la livraison des enregistrements.
  • Oublier la fenêtre de 35 jours de l'Activity Log. Il ne s'agit pas d'une rétention, mais d'une limite de suppression. Planifiez l'export vers Object Storage avant le jour 35, sinon l'enregistrement d'audit est irrécupérable.

5. Agrégation vers un SIEM externe

Pour une entreprise comme FinCorp, le modèle par contrat, par région et à quatre plans ne produit pas la vue corrélée unique dont ont besoin à la fois une équipe des opérations de sécurité et un auditeur. Le modèle d'entreprise est l'agrégation (fan-in) : chaque plan de chaque contrat est acheminé vers un SIEM externe unique, qui devient le système de référence pour la corrélation, la conservation à long terme et l'alerte sur l'ensemble de l'infrastructure. La plateforme vous fournit les points d'attache nécessaires pour réaliser cela sans un transmetteur géré :

  • Journaux et métriques : configurez vos agents (ou les transmetteurs initiés par le produit de Central Logging) vers les pipelines IONOS CLOUD pour Grafana au sein de la plateforme, et en parallèle, transférez les mêmes flux depuis vos agents vers le collecteur du SIEM. Le Logging Service expose également une API Telemetry en lecture seule (authentifiée avec le même jeton Cloud API) qu'un SIEM peut interroger, bien que le double envoi côté agent soit le chemin le plus direct.
  • Flux réseau : les Flow Logs sont déjà stockés dans Object Storage au format texte gzip ; le SIEM les ingère depuis le bucket, qui sert également d'archive durable.
  • Audit : un planifié extrait le Journal d'activité via son API en lecture seule avant la fin de la fenêtre de 35 jours et transfère les enregistrements vers le SIEM, satisfaisant ainsi simultanément la conservation à long terme et la corrélation inter-contrats.
  • VMware hybride : l'API REST vSphere et les alarmes vCenter sont transférées depuis l'infrastructure dédiée vers le même SIEM, réunissant ainsi les deux domaines d'observabilité au seul point où l'unification est pertinente.

C'est la même leçon de composition que la plateforme répète ailleurs : il n'existe pas de produit géré d'agrégation inter-contrats, il faut donc en composer un. Object Storage est le hub durable, le SIEM est le cerveau de corrélation, et les points d'accès par plan sont les prises.

Résumé

L'observabilité IONOS CLOUD repose sur quatre plans à périmètre 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 de manière partielle dans Grafana, les données d'audit et de flux résidant par conception en dehors de ce plan. Le travail opérationnel essentiel consiste à acheminer chaque signal de manière délibérée, à concevoir en tenant compte des trois lacunes (absence d'événements du plan de contrôle dans le plan de journalisation, absence d'agrégation inter-contrats, fenêtre d'audit de 35 jours), à utiliser le Central Logging pour la transmission initiée par les produits, à traiter le parc VMware dédié comme un domaine d'observabilité vCenter/vSAN distinct, et à acheminer l'ensemble vers un SIEM externe, où la corrélation et la conservation à long terme sont effectivement réalisées.

Points clés :

  • Quatre plans, périmètres fixes : Monitoring Service (métriques Prometheus, basé sur la poussée, Grafana Mimir), Logging Service (cinq types de sources, 5 flux par pipeline, conservation de 7/14/30 jours ou illimitée), Activity Logs (GET en lecture seule, fenêtre de 35 jours), Flow Logs (enregistrements 5-tuples vers un bucket Object Storage appartenant à l'utilisateur, conservation gérée par le client).
  • Le pipeline de métriques du Monitoring Service peut être créé depuis le formulaire de création DCD ou via l'API ; la clé de pipeline à usage unique doit être enregistrée lors de la création.
  • Les événements du plan de contrôle Kubernetes n'atteignent jamais le Logging Service ; instrumentez les charges de travail avec un agent intra-cluster et considérez le « Logging to S3 » du cluster comme un chemin distinct.
  • Il n'y a pas d'agrégation inter-contrats et la piste d'audit est supprimée après 35 jours, de sorte que l'agrégation et la conservation à long terme sont construites en externe, avec le Object Storage comme nœud durable et un SIEM comme point de corrélation.
  • Le Central Logging est un commutateur au niveau du contrat et par région (sous contrôle de l'administrateur) qui permet aux produits intégrés de transmettre vos journaux à votre place ; le parc VMware dédié 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é à périmètre fixe (métriques, journaux, audit, flux réseau), chacun ayant son propre chemin d'ingestion et son modèle de conservation.
  • Central Logging : une capacité au niveau du contrat et par région qui permet aux produits IONOS CLOUD intégrés de transmettre leurs journaux au Logging Service en votre nom, visible dans Grafana managé.
  • Journal de flux : une règle par ressource émettant des enregistrements de connexion 5-tuples avec le verdict ACCEPT/REJECT du pare-feu vers un bucket Object Storage appartenant au client, régénéré toutes les 10 minutes.
  • Convergence (fan-in) : le motif d'agrégation d'entreprise consistant à acheminer chaque plan de chaque contrat vers un SIEM externe unique pour la corrélation inter-contrats et la conservation à long terme.

Lectures complémentaires

  • Unité 2.3 : Activity Logs et piste d'audit (le plan d'audit et l'échéance d'exportation)
  • Unité 3.2 : Sécurité réseau : pare-feu et groupes de sécurité (les journaux de flux comme outil de vérification du pare-feu)
  • Unité 4.4 : Private Cloud (VMware dédié) (l'infrastructure dédiée observée via vCenter et vSAN)
  • Unité 6.1 : Conception de la plateforme Kubernetes (pourquoi les événements du plan de contrôle sont situés en dehors du plan de journalisation)
  • IONOS CLOUD Architecture Center