19 min de lecture

Objectifs d'apprentissage

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

  • Cartographier les quatre plans de télémétrie IONOS (métriques, journaux, audit, flux réseau) à leurs étendues fixes et acheminer chaque signal de manière délibérée plutôt que de s'attendre à ce qu'un seul panneau de console affiche tout
  • Concevoir autour des trois lacunes d'observabilité qui piègent les équipes en production : les événements de contrôle de Kubernetes qui ne parviennent jamais à Logging Service, l'absence d'agrégation inter-contrat, et la fenêtre de rétention de 35 jours des journaux d'activité
  • Utiliser la journalisation centralisée afin que les produits intégrés transmettent leurs propres journaux sans exécuter chacun une pile d'ingestion distincte
  • Positionner l'observabilité dédiée-VMware vCenter aux côtés des plans de plateforme pour un patrimoine hybride
  • Construire un pipeline de métriques avec une alerte et activer un journal de flux dans le Data Center Designer, et diriger 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 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 joints entre les plans et comment vous créez une image opérationnelle unique à travers eux et à travers les contrats.

FinCorp, notre entreprise de services financiers allemande sous GDPR et les obligations BSI, nécessite une vue opérationnelle d'audit de classe qui s'étend sur un noyau de charge de travail réglementé, une plateforme Managed Kubernetes, et un domaine dédié VMware, qui expose chaque jointure dans le 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 corriger.

1. Les quatre plans de télémétrie et leurs étendues 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 est configurable. Derrière le point de terminaison, les données atterrissent dans Grafana Mimir et sont visualisées dans une instance Grafana gérée étendue 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 (un JSON REST API), 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 de support, et non dans le tableau de bord.

Audit (Activity Logs). La piste d'audit du plan de contrôle : qui a fait quoi à quelle ressource. Il enregistre les connexions utilisateur, la mise à disposition de ressources, les modifications de configuration, l'accès aux données, et les récupérations, modifications et suppressions de ressources. Il 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 parce que 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 des comptes de paquets et d'octets, plus un champ action de ACCEPT ou REJECT montrant le verdict du pare-feu) émis dans un seau Object Storage appartenant au client, sous forme de texte compressé gzip, tourné tous les 10 minutes. Flow Logs s'attachent à 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 en tant que jambe du plan opérationnel au niveau du réseau.

La surface unifiante est Grafana : les métriques et les journaux sont tous deux interrogables à travers 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 fenêtre, dans le journal d'activité API 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 ont un impact 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 de contrôle de Kubernetes ne transitent pas par le Logging Service. Le Logging Service liste Kubernetes comme source prise en charge, mais cela signifie que la charge de travail et les journaux Node que vous envoyez depuis l'intérieur du Cluster, et non le plan de contrôle géré. La SLA d'IONOS Managed Kubernetes ne couvre que le Kubernetes API du plan de contrôle, et les événements de plan de contrôle ne sont pas émis dans votre pipeline Logging Service. Le Cluster propose un commutateur "Journalisation vers S3" distinct qui écrit les données de journal Cluster dans un seau Object Storage ; traitez 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é de la charge de travail, vous déployez un agent dans le Cluster (Fluent Bit pour les journaux, un exportateur compatible Prometheus pour les métriques) qui pousse vers vos pipelines de journalisation et de surveillance. La couture est la ligne entre le plan de contrôle géré et vos charges de travail : vous instrumentez les dernières, IONOS exploite les premières.

Il n'y a pas d'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 point de transmission ni d'agrégation. Si FinCorp divise la production, la non-production et une charge de travail isolée pour la conformité en contrats distincts (la discipline de limite 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 de 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 échéance d'exportation, et non une politique de rétention. Le modèle documenté à long terme est de télécharger les données du journal d'activité à intervalles réguliers et de 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 inviolable (Unité 2.3, Unité 5.2). Manquez la fenêtre et l'enregistrement est perdu.

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és 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 que tout produit puisse ingérer des données 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 cette option. Elle peut être activée à partir du DCD (un commutateur d'état par région dans la vue de journalisation centralisée du Logging Service), à partir du API de journalisation, 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 d'être publiés sous forme de liste statique, vous devez donc considérer l'ensemble pris en charge comme quelque chose à vérifier pour chaque engagement.

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

Le noyau réglementé de FinCorp s'exécute sur IONOS Private Cloud, le VMware SDDC 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é de ce domaine est l'outillage natif VMware qui est livré avec la pile dédiée : vCenter Server 8.0 pour les graphiques de performances, les événements et les alarmes de l'hôte, du Cluster et du VM, ainsi que la surveillance de la santé et de la capacité de vSAN exposée dans le Cloud Panel pour la couche de stockage. L'interface de programmation vSphere REST API (limitée à 100 requêtes par seconde) est la couture programmatique si vous souhaitez extraire ces données vers l'extérieur.

N'indiquez 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é interplan qui ingère les alarmes vCenter dans le Logging Service ; aucun n'est documenté. Pour un domaine 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 dédié VMware, réconciliés uniquement lorsque vous les transférez délibérément vers un collecteur externe commun.

4. DCD Déploiement étape par étape

Vous allez mettre en place 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 bord Load Balancer. Cela réalise deux des quatre plans de la Section 1 et vous donne des points de terminaison de ingestion concrets pour pointer les agents. La troisième jambe, 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 Flow Logs.

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

Partie A : le pipeline de métriques (Monitoring Service). Notez une limite de plateforme importante : le pipeline de métriques Monitoring Service est créé via le Monitoring Service API, et non via un formulaire de création DCD. Le cycle de vie du pipeline (créer, récupérer, modifier, supprimer) est API-only pour le moment ; la surface DCD est pour accéder au Grafana résultant, et non pour provisionner le pipeline. Traitez ce qui suit comme le chemin de création API-niveau, puis passez à Grafana pour l'alerte.

  1. Choisissez le point de terminaison régional qui correspond à votre placement 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 inclut une clé key à usage unique 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 retourné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 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, à moins que vous ne le modifiiez.
  4. Ouvrez le Grafana géré à l'adresse grafanaEndpoint retournée 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 CPU qui devrait précéder une action d'auto-mise à l'échelle), et attachez un point de contact pour que la règle notify le canal de disponibilité. La fonction d'alerte de Grafana est la surface d'alerte ; il n'y a pas d'objet d'alerte IONOS séparé pour le plan de métriques.

Un appel de création illustratif (le point architectural est que ce plan est provisionné via le API, et non 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 est une véritable construction de 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, 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.
  2. Ouvrez le menu déroulant du journal de flux et créez une règle. Définissez un nom (il devient également la première partie du préfixe d'objet Object Storage), donc nommez-le pour la ressource et l'environnement.
  3. Définissez la direction à Entrée, Sortie ou Bidirectionnelle, et l'action à Rejetée, Acceptée ou Toute. Pour une posture d'investigation de sécurité, Bidirectionnelle plus Rejetée affiche ce que le pare-feu bloque ; pour l'analyse de la capacité et de la connexion, Acceptée est l'ensemble utile.
  4. Définissez le seau cible Object Storage à votre seau existant possédé par l'utilisateur dans la région. Enregistrez. Les enregistrements commencent à atterrir sous forme d'objets .log.gz, tournés tous les 10 minutes.
  5. Appliquez une politique de cycle de vie sur ce seau pour faire vieillir les objets de journal de flux, car les Flow Logs 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 :

  • S'attendre à un bouton "créer un pipeline" pour les métriques dans le DCD. Le pipeline Monitoring Service est provisionné par API ; seul l'accès Grafana atterrit dans l'expérience DCD. Planifiez la construction des métriques comme une étape API, et non comme un clic de console.
  • Ne pas enregistrer la clé de pipeline de surveillance lors de sa création. La clé est renvoyée une seule fois et jamais à nouveau. La perdre et vous devez recréer le pipeline. La même règle de clé à usage unique s'applique à un pipeline Logging Service.
  • Traiter "Kubernetes" dans la liste de sources Logging Service comme une visibilité du plan de contrôle. Il s'agit uniquement de vos journaux de charge de travail dans Cluster ; les événements de plan de contrôle n'arrivent jamais là. Déployez un agent dans Cluster et n'attendez pas des événements qui n'arriveront pas.
  • Supposer que la rétention du journal de flux est gérée pour vous. La suppression de la règle de journal de flux ne supprime pas les objets déjà écrits, et il n'y a pas d'expiration automatique. Sans politique de cycle de vie de seau, l'archive grandit et facture à tout jamais.
  • Pointer un journal de flux vers un seau que vous ne possédez pas ou qui se trouve dans la mauvaise région. La destination doit être un seau possédé par l'utilisateur ; une cible incorrecte échoue silencieusement à livrer les enregistrements.
  • Laisser un pipeline inactif en cours d'exécution. Un pipeline de journalisation ou de surveillance facture de la création à la suppression, quel que soit le fait que des données soient transmises ; l'arrêt de l'agent n'arrête pas la facturation. Supprimez les pipelines que vous n'utilisez pas.
  • 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 35e jour, ou 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 de sécurité et un auditeur. Le modèle d'entreprise est le 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 un forwarder géré :

  • Journaux et métriques : pointez vos agents (ou les forwarders initiés par produit de Central Logging) vers les pipelines IONOS 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 un Telemetry API en lecture seule (/api/v1/query, /api/v1/query_range, /api/v1/series, authentifié avec le même jeton Cloud API) que le SIEM peut interroger, bien que l'envoi double côté agent soit la voie la plus directe.
  • Flux réseau : les Flow Logs atterrissent déjà dans le Object Storage sous forme de texte gzip ; le SIEM les ingère à partir du bucket, qui sert également d'archive durable.
  • Audit : un travail planifié extrait le journal d'activité via son API API en lecture seule avant que la fenêtre de 35 jours ne se ferme, et transfère les enregistrements dans le SIEM, satisfaisant ainsi à la fois la rétention à long terme et la corrélation entre les contrats.
  • Hybrid VMware : les alarmes vSphere REST API et vCenter sont transférées à partir de l'ensemble dédié vers le même SIEM, réunissant ainsi les deux domaines d'observabilité en un seul 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 les contrats, vous devez donc en composer un. Le Object Storage est le hub durable, le SIEM est le cerveau de corrélation, et les points de terminaison de chaque plan sont les points de prise.

Résumé

L'observabilité IONOS est constituée de quatre plans à portée fixe (métriques via le Monitoring Service, journaux via le Logging Service, audit via le Activity Logs et flux réseau via le Flow Logs) unifiés seulement 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ées 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 (GET en lecture seule, fenêtre de 35 jours), Flow Logs (enregistrements 5-uplets vers un seau Object Storage propriétaire de l'utilisateur, rétention gérée par le client).
  • Le pipeline de métriques Monitoring Service est provisionné par API, et non par un formulaire de création DCD ; la clé de pipeline à usage unique doit être enregistrée lors de la création, et les pipelines inactifs sont toujours facturés.
  • Les événements de plan de contrôle Kubernetes ne parviennent jamais au Logging Service ; instrumentez les charges de travail avec un agent dans-Cluster et traitez « Cluster Logging to S3 » comme un chemin distinct.
  • Il n'y a pas d'agrégation inter-contrat et le trace d'audit est supprimé à 35 jours, donc l'agrégation et la rétention à long terme sont construites à l'extérieur, avec le Object Storage comme hub durable et un SIEM comme point de corrélation.
  • La journalisation centralisée est un commutateur au niveau du contrat et de la région (géré par l'administrateur) qui permet aux produits IONOS Cloud intégrés de transférer les journaux pour vous ; le domaine dédié-VMware est observé via vCenter 8.0 et vSAN, un domaine distinct réconcilié uniquement au 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 avec son propre chemin d'ingestion et son modèle de rétention.
  • Journalisation centralisée : une fonctionnalité au niveau du contrat et de la région qui permet aux produits IONOS Cloud intégrés de transférer leurs journaux vers le Logging Service en votre nom, affiché 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 seau Object Storage propriétaire du client, rotatif toutes les 10 minutes.
  • Fan-in : le modèle d'agrégation d'entreprise consistant à transférer chaque plan 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é (Flow Logs 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