Déploiement

Observabilité

Métriques, journaux et piste d'audit de chaque service OpenKeel dans Grafana : une stack optionnelle installée par okadm --grafana, l'équivalent du Prometheus, du Grafana et de la journalisation centralisée de Kolla.

La stack d'observabilité

01
Services OpenKeel
Journaux JSON et événements d'audit CADF sur stdout ; /healthz, /readyz et /metrics sur le port d'administration :9090
02
Collecte
Les moniteurs du Prometheus Operator collectent les services et les services de données ; Alloy, un DaemonSet, lit tous les journaux des Pods de son nœud
03
Stockage
Prometheus pour les métriques ; Loki pour les journaux, avec un flux applicatif et un flux d'audit séparés
04
Grafana et alertes
Tableaux de bord OpenKeel dans leur propre dossier ; alertes PrometheusRule envoyées par Alertmanager

Ce que chaque service émet

Tous les modules Go sont construits sur le même modèle : ils émettent donc tous les mêmes signaux, au même format.

Journaux JSON structurés

JSON log/slog sur stdout, en anglais : time (UTC), level, service, pod, msg
request_id et global_request_id, transmis à chaque appel et message sortant, plus les identifiants d'utilisateur et de projet du jeton
Les valeurs des clés comme password, secret, token ou key sont masquées à toute profondeur ; les corps de requête ne sont jamais journalisés
Niveau de journalisation modifiable à chaud par SIGHUP, sans redémarrage

Piste d'audit CADF

Un événement CADF par appel d'API, au format pycadf de keystonemiddleware, vérifié champ par champ face à celui-ci
Les appels en 401 et 403 sont aussi audités ; Keystone ajoute ses événements d'identité (authentification, jetons, attributions de rôles)
N'enregistre jamais les corps, les jetons ni les paramètres de requête secrets
Ne bloque jamais une requête : une file pleine abandonne l'événement et le compte, et une alerte se déclenche

Sondes et métriques

Port d'administration :9090, non exposé hors du cluster : /healthz (processus vivant), /readyz (base de données et autres contrôles), /metrics
/metrics sert les compteurs d'audit, sur les Pods d'API : événements envoyés, perdus et en échec par destination
La mémoire et le CPU de chaque Pod viennent de cAdvisor, dans le kubelet ; les redémarrages de kube-state-metrics

Pas encore là : les débits et latences des requêtes, les compteurs de base de données, de cache et de messages, les métriques du processus Go et les traces OpenTelemetry font partie de la conception du modèle de module, mais les services ne les exportent pas aujourd'hui.

Composants et dimensionnement

Tout est installé dans le namespace openkeel-monitoring. Les versions des charts sont figées dans le manifeste de version d'okadm et intégrées au binaire.

Release	Chart	Quoi	Lab	Production
kube-prometheus-stack	92.10.1 (Prometheus Operator v0.94.1)	Prometheus Operator et ses CRD, Prometheus, Alertmanager, Grafana, kube-state-metrics, node-exporter, les tableaux de bord et alertes Kubernetes	1 réplique de chaque ; Prometheus garde 2 jours, sans volume	Prometheus ×2 (15 jours, 50 Gi), Alertmanager ×3, Grafana avec un volume de 10 Gi, sur la StorageClass bloc
loki	7.3.0 (Loki 3.6.12)	Stockage des journaux, interrogé par Grafana en LogQL	Binaire unique, volume de 5 Gi	Simple scalable : 3 write, 3 read, 3 backend, gateway ×2 ; chunks et index dans S3
alloy	1.13.1 (Alloy v1.20.1)	DaemonSet : chaque journal de conteneur de son nœud vers Loki, lignes d'audit séparées	1 Pod par nœud	1 Pod par nœud

Ce qui est collecté

Le chart parapluie ajoute ces objets à la release openkeel-infra quand la supervision est activée.

Objet	Collecte
PodMonitor `openkeel-services`	Le port d'administration de chaque Pod OpenKeel (API, workers, agents), étiqueté par service et composant
Métriques MariaDB	mysqld-exporter et son ServiceMonitor, ajoutés par l'opérateur MariaDB : taille du cluster Galera, connexions, requêtes, requêtes lentes
ServiceMonitor `openkeel-rabbitmq`	Le plugin rabbitmq_prometheus, y compris les métriques par file : messages prêts, consommateurs, alarmes
ServiceMonitors `openkeel-kubevirt`, `openkeel-longhorn`	KubeVirt et Longhorn, quand okadm plan les trouve dans le cluster
ConfigMaps `openkeel-dashboard-*`	Les tableaux de bord OpenKeel, chargés par le sidecar de Grafana dans le dossier OpenKeel

Le lab Kustomize (openkeel-lab) fait tourner ses propres services de données, sans exporters : son tableau de bord Data services reste vide, alors que okadm install --mode lab --grafana les a tous.

Journaux dans Loki : deux flux

Alloy aiguille chaque ligne selon son champ log_type de premier niveau : la piste d'audit est ainsi séparée des journaux applicatifs, avec sa propre rétention.

Flux	Lignes	Lab	Production
`{stream="audit"}`	Événements d'audit CADF (`"log_type": "audit"`)	30 jours	400 jours
`{stream="app"}`	Toutes les autres lignes de conteneur, OpenKeel ou non	7 jours	31 jours

La rétention est appliquée par le compacteur de Loki et se change dans le fichier de valeurs d'okadm. Chaque ligne porte les labels namespace, pod, container, node, service et component.

Tableaux de bord

Tableau de bord	Source de données	Affiche
OpenKeel / Audit trail	Loki	Événements, échecs, 401, 403, authentifications Keystone échouées et suppressions ; échecs par utilisateur et IP source ; suppressions et modifications par utilisateur et type de ressource ; les événements bruts. Filtres : service, résultat, utilisateur, IP source
OpenKeel / Services	Prometheus, Loki	Cibles de collecte par service, compteurs d'audit, mémoire et CPU de chaque Pod (cAdvisor), volume de journaux par niveau, erreurs par service et un panneau de journaux avec recherche
OpenKeel / Data services	Prometheus	MariaDB Galera et RabbitMQ (files qui s'accumulent ou sans consommateur, alarmes)
Kubernetes / …	Prometheus	Ceux de kube-prometheus-stack : cluster, nœuds, namespaces, Pods, charges de travail

Rechercher dans la piste d'audit

Dans Grafana, Explore, source de données Loki : les champs CADF sont extraits avec LogQL. Ici, les authentifications Keystone échouées.

{stream="audit", service="openkeel-keystone"}
  | json outcome="payload.outcome",
         initiator="payload.initiator.id",
         ip="payload.initiator.host.address",
         event_type="event_type"
  | event_type="identity.authenticate"
  | outcome="failure"

Alertes

Livrées dans la PrometheusRule openkeel, en plus des alertes Kubernetes de kube-prometheus-stack.

Alerte	Gravité	Se déclenche quand
OpenKeelAuditEventsDropped	critical	La file d'audit d'un service était pleine : la piste a un trou
OpenKeelAuditEventsFailed	warning	Une destination d'audit a échoué, par exemple RabbitMQ injoignable
OpenKeelServiceTargetDown		Le point de métriques d'un service ne peut pas être collecté
OpenKeelServiceNoTarget		Un service n'a aucune cible de collecte

Alertmanager n'envoie nulle part par défaut : définissez ses destinataires dans le fichier de valeurs d'okadm.

Activation

Rien n'est installé sans l'option. okadm installe la stack juste après Multus, avant openkeel-infra : namespace, mot de passe admin Grafana aléatoire, puis kube-prometheus-stack, Loki et Alloy, chacun attendu. Il mémorise l'option : les installations et mises à jour suivantes tiennent la stack à jour. install, upgrade et access affichent l'URL de Grafana et la commande qui lit le mot de passe.

okadm install --mode lab --grafana            # kind lab
okadm install --mode lab --grafana --ingress  # Grafana at grafana.127.0.0.1.nip.io
okadm install --grafana --domain cloud.example.org
# or, with the Kustomize lab
GRAFANA=1 make lab-up

En production

Sujet	Que faire
Stockage objet de Loki	Créer le Secret `openkeel-loki-s3` (endpoint, région, clés) et les buckets `openkeel-loki-chunks` et `openkeel-loki-ruler` avant l'installation ; `okadm plan` bloque sans eux. La passerelle Ceph RGW d'`okadm --ceph-s3` convient aussi
Routage des alertes	Définir les destinataires d'Alertmanager
Cibles du plan de contrôle	Sur Talos, exposer les métriques d'etcd, du scheduler et du controller manager, ou désactiver ces cibles
Prometheus Operator déjà présent	`okadm plan` le signale. Pour le garder, installer sans --grafana, activer les moniteurs OpenKeel et laisser ce Prometheus les sélectionner
Accès à Grafana	Ingress sur `grafana.<domain>`, sinon un port-forward ; le mot de passe admin est aléatoire, dans le Secret `openkeel-grafana-admin`
Valeurs	Une section `observability.<release>` par release, dans le même fichier `-f` que le reste d'OpenKeel

Piste d'audit : ce que la plateforme doit ajouter

Les services produisent la piste ; la garder complète, intacte, horodatée et lisible pendant la durée requise est le travail de la plateforme.

Obligation	PCI-DSS v4.0	ISO/IEC 27001:2022	Comment
Envoyer les événements hors du nœud dès leur écriture	10.3.3	A.8.15	Alloy (ou Fluent Bit, Vector, l'OpenTelemetry Collector) avec un tampon sur disque
Rétention inaltérable, en écriture unique	10.3.2, 10.3.3	A.8.15	Une copie en stockage objet avec verrouillage d'objet en mode conformité ; Loki seul ne suffit pas
12 mois, dont les 3 derniers immédiatement disponibles	10.5.1	A.5.33, A.8.15	Bucket verrouillé 400 jours ; Loki garde le flux d'audit 400 jours en production
Accès en lecture restreint	10.3.1	A.8.15, A.5.15	Politique du bucket, tenant Loki ou équipe Grafana dédiés au flux d'audit
Horloges synchronisées	10.6.1 to 10.6.3	A.8.17	NTP sur les nœuds ; alertes node-exporter en cas de dérive
Détecter les trous	10.7.1, 10.7.2	A.8.15, A.8.16	Les alertes d'audit ci-dessus, et les compteurs propres au collecteur
Revue quotidienne	10.4.1	A.8.16	Un SIEM alimenté depuis le bucket ou le collecteur ; le tableau de bord Grafana

Loki offre une piste d'audit consultable, pas une archive inaltérable : quiconque administre le cluster peut écrire dans son stockage.

Optionnel : openstack-exporter

L'exporteur utilisé par Kolla

monitoring.openstackExporter.enabled: true déploie openstack-exporter 1.7.0. Toutes les 2 minutes, il liste les ressources de chaque API (serveurs, réseaux, volumes, images, Placement, agents) : les tableaux de bord OpenStack de la communauté fonctionnent tels quels.

Désactivé par défaut, activé avec CloudKitty

Il appelle chaque API avec un jeton admin : sa charge croît avec le cloud
Il écrit ses propres événements d'audit CADF
Il répète ce que montrent déjà les signaux des services et la piste d'audit
okadm l'active quand CloudKitty est installé : le fichier de métriques de CloudKitty valorise ses séries openstack_*

Les autres lecteurs de Prometheus

Le Prometheus de la pile est aussi une source de données pour OpenKeel lui-même : okadm y oriente ces services quand --grafana est actif.

Lecteur	Ce qu'il lit	Pour
CloudKitty (collecteur)	Séries d'openstack-exporter par projet (`tenant_id`) : instances, capacité des volumes, taille des images	Valorisation horaire, page FinOps / GreenOps de Skyline
openkeel-skyline (`GET /extension/server_metrics`)	Séries KubeVirt `kubevirt_vmi_*` du namespace du projet, VM choisies par le label `openkeel.io/project-id`	La page Metrics : CPU, mémoire (pilote balloon), utilisation disque (agent invité QEMU) et E/S disque des VM
openkeel-skyline (Prometheus queries)	Les requêtes des pages de supervision de la console	Vues administrateur de Skyline amont

Voir FinOps / GreenOps et CloudKitty et les ajouts à Skyline.