Cockpit : observer un incident sans rien provisionner

Cockpit collecte déjà les métriques de votre projet, vous ne l'avez pas activé, et cela ne vous coûte rien. Ce sont les trois faits que cette leçon établit, avant d'en tirer le plus utile : les données survivent aux ressources, si bien qu'on peut retrouver un incident dans un cluster détruit depuis. Vous allez lire ce que le projet produit, distinguer ce qui est gratuit de ce qui est facturé, interroger les métriques avec un jeton au moindre privilège, et lire un incident réel dans la courbe. Aucune ressource facturée n'est créée.

Ce que vous allez apprendre

• Constater que Cockpit s'active seul, et depuis quand
• Distinguer les données Scaleway, gratuites, des données custom, facturées
• Interroger les métriques par l'API, avec un jeton en lecture seule
• Retrouver un incident dans les métriques de ressources détruites
• Reconnaître le piège qui transforme une donnée gratuite en donnée facturée

Prérequis

• scw 2.62.0 ou plus récent, jq et curl
• Un projet ayant hébergé au moins une ressource intégrée à Cockpit
• Aucun budget : cette leçon ne provisionne rien

Qui a activé Cockpit sur ce projet ?

Personne. Cockpit est rattaché au projet et s'active automatiquement dès qu'une ressource intégrée existe. La preuve tient en une commande.

scw cockpit data-source list region=fr-par -o json \
  | jq -r '.[] | "\(.type)\trétention \(.retention_days) j\torigine \(.origin)\tcréée \(.created_at[0:10])"'

Relevé le 2026-09-12 sur un projet de lab :

metrics   rétention 31 j   origine scaleway   créée 2026-09-11
logs      rétention 7 j    origine scaleway   créée 2026-09-12

Les deux dates ne sont pas les mêmes, et elles racontent quelque chose : la source de métriques est née le jour où la première ressource est apparue, celle des journaux le lendemain, avec la première ressource qui en produit. Aucune des deux n'a été créée à la main.

Les rétentions par défaut sont 31 jours pour les métriques et 7 jours pour les journaux. Le maximum est de 5 ans pour toute source, mais le minimum n'est pas le même partout : 1 jour pour les journaux et pour les sources custom, 31 jours pour les métriques Scaleway, qui ne descendent pas sous leur défaut. C'est au delà de ces durées que la facturation commence.

Qu'est-ce qui est gratuit, et qu'est-ce qui est facturé ?

La ligne de partage n'est pas le produit, c'est le chemin qu'emprunte la donnée. La documentation officielle est nette : « Scaleway data is collected and available in Cockpit for free ».

Donnée	Origine	Coût
Scaleway	collectée par la plateforme, sans agent de votre part	gratuite, rétention par défaut comprise
Custom	poussée par vous, depuis un agent ou un script	facturée à l'ingestion

Glissez pour voir

Les tarifs de l'ingestion custom, relevés sur la page officielle validée le 2026-01-20 : 0,15 EUR par million d'échantillons de métriques, 0,35 EUR par Go de journaux, 0,35 EUR par Go de traces. Les métriques bénéficient de six paliers de remise au volume, le dernier descendant à 0,08 EUR par million au delà de 200 milliards d'échantillons mensuels.

Votre projet vous dit où il se situe.

scw cockpit usage-overview get region=fr-par -o json \
  | jq -r 'to_entries[] | "\(.key)\t\(.value.quantity_over_interval) \(.value.unit)"'

Sur le projet de lab, relevé le 2026-09-12. Attention à la fenêtre : l'interval renvoyé ne mesure pas la durée de collecte, il couvre le mois en cours. Ici il vaut environ 11,7 jours alors que la source de métriques n'existe que depuis la veille.

scaleway_metrics_usage    34536 samples
scaleway_logs_usage       110263 bytes
external_metrics_usage    0 samples
external_logs_usage       0 bytes
external_traces_usage     0 bytes

Les trois compteurs external_* sont les seuls qui facturent l'ingestion, et ici ils valent zéro : rien de ce qui a été collecté, cinq clusters Kubernetes compris, n'a coûté à l'entrée.

« À l'ingestion » n'est pas « en tout ». La rétention étendue se facture séparément, y compris sur une source Scaleway, et elle n'apparaît pas dans ce relevé, qui ne mesure que le volume ingéré. Un projet peut donc afficher des external_* à zéro et payer quand même, s'il a poussé sa rétention au delà de 31 ou 7 jours.

Dernière précaution sur ce chiffre : ce n'est pas un compteur cumulatif. Relu à quelques minutes d'intervalle, scaleway_metrics_usage décroît, la fenêtre glissant avec l'heure. Il se lit comme un ordre de grandeur, pas comme une valeur à rejouer à l'identique.

Le piège qui rend payante une donnée gratuite

La documentation le dit sans ambiguïté : « any data that you push yourself is considered as "custom" and is billed, even if you collect that data from Scaleway products ».

Autrement dit, installer un agent pour récupérer les métriques de vos propres Instances Scaleway et les renvoyer vers Cockpit transforme une donnée gratuite en donnée facturée.

Et le résultat n'est pas le même objet. Les sources Scaleway sont en lecture seule : une donnée poussée n'y entre jamais. Il faut créer une source custom, les points d'écriture ne fonctionnant qu'avec elle. Vous obtenez donc une donnée comparable, dans une source séparée, hors des tableaux de bord préconfigurés qui lisent la source Scaleway, et sous des noms de métriques différents de ceux que la plateforme produit. Vous payez pour une copie qui ne se superpose pas à l'originale.

La discipline est simple : avant d'installer un agent, vérifier dans la table d'intégration si le produit est déjà collecté. Le réflexe inverse, « je collecte tout moi-même pour être homogène », est l'un des moyens les plus rapides de faire monter une facture d'observabilité.

Quels produits alimentent Cockpit, et lesquels restent muets ?

La table officielle d'intégration, validée le 2025-11-24, réserve des surprises. Les absences comptent autant que les présences.

Produit	Métriques	Journaux
Kubernetes Kapsule et Kosmos	oui	oui
Managed Database PostgreSQL et MySQL	oui	oui
Load Balancers, Public Gateways, Edge Services	oui	oui
Object Storage	oui	oui
Instances CPU et GPU	oui	non
Block Storage, VPC, Secret Manager	oui	non
Container Registry	non	non
Elastic Metal, Apple silicon	non	non
Key Manager, IAM, Audit Trail	non	non
Data Warehouse for ClickHouse	prévu	non

Glissez pour voir

Trois asymétries méritent d'être retenues. Container Registry n'est pas intégré alors que Kapsule l'est : la chaîne qui va du registre au cluster a donc un angle mort à son premier maillon. Secret Manager envoie des métriques, Key Manager non, alors que ce sont deux produits voisins du même volet sécurité. Et Audit Trail n'est pas intégré : le produit qui trace les actions n'alimente pas celui qui les observe.

Comment interroger les métriques sans passer par Grafana ?

Par l'API, avec un jeton dont la portée est réduite à la lecture.

URL_M=$(scw cockpit data-source list region=fr-par -o json \
  | jq -r '.[] | select(.type=="metrics") | .url')

TOK=$(scw cockpit token create name=lecture-metriques \
  token-scopes.0=read_only_metrics region=fr-par -o json)
SECRET=$(echo "${TOK}" | jq -r '.secret_key')

Le champ token-scopes accepte neuf portées utilisables, dont read_only_metrics, write_only_metrics, read_only_logs et full_access_alert_manager ; l'aide en liste dix, mais la première, unknown_scope, est la valeur par défaut de l'énumération et non une permission. Un jeton d'écriture n'a rien à faire dans un script de lecture : c'est le moindre privilège appliqué à l'observabilité, et c'est d'autant plus important qu'un jeton d'écriture permet d'ingérer dans une source custom, donc de faire dépenser dès qu'une telle source existe.

Le secret n'apparaît qu'à la création. Il reste en mémoire, jamais dans un fichier.

L'endpoint est compatible Prometheus, ce qui rend la suite familière.

curl -s -H "Authorization: Bearer ${SECRET}" \
  "${URL_M}/prometheus/api/v1/label/__name__/values" \
  | jq -r '.data[]' | sed 's/_.*//' | sort | uniq -c | sort -rn

Sur le projet de lab, 8 familles apparaissent :

  25 kubernetes
  22 load
  20 instance
  14 rdb
   9 observability
   2 vpc
   2 sbs
   2 environmental

La dernière est inattendue : environmental_footprint_usage_impact_co2 et ..._water exposent une estimation d'empreinte carbone et de consommation d'eau. Elles ne servent pas à diagnostiquer une panne, mais elles existent, et elles sont gratuites comme les autres.

Côté base de données, les 14 métriques rdb_instance_postgresql_* couvrent le nœud et le moteur : processeur, disque, système de fichiers, mémoire, mais aussi pg_replication_lag, pg_stat_activity_count et pg_settings_max_connections. Le rapport entre les deux dernières est la mesure qui prévient la saturation des connexions.

Peut-on retrouver un incident sur une ressource détruite ?

Oui, et c'est l'intérêt principal de cette leçon. Les métriques restent le temps de la rétention de leur source, 31 jours par défaut, que la ressource existe encore ou non.

DEBUT=$(date -u -d '36 hours ago' +%s)
FIN=$(date -u +%s)

curl -s -H "Authorization: Bearer ${SECRET}" \
  --data-urlencode 'query=kubernetes_cluster_k8s_shoot_nodes' \
  --data-urlencode "start=${DEBUT}" --data-urlencode "end=${FIN}" \
  --data-urlencode 'step=600' \
  "${URL_M}/prometheus/api/v1/query_range" \
  | jq -r '.data.result[] | "\(.metric.resource_name) autohealing=\(.metric.autohealing)",
             (.values[] | "  \(.[0] | tonumber | strftime("%m-%d %H:%M"))  \(.[1]) nœud(s)")'

La sortie, relevée le 2026-09-12, contient cinq clusters qui n'existent plus. L'un d'eux porte l'incident :

lab4-kapsule autohealing=false
  09-12 08:53  2 nœud(s)
  09-12 09:03  1 nœud(s)

Un nœud a disparu entre 08:53 et 09:03, et la courbe le dit sans qu'aucun journal n'ait été conservé, sans agent, et sans que le cluster existe encore.

C'est exactement ce qu'on cherche lors d'un post-mortem, et c'est ce qui distingue une observabilité utile d'un tableau de bord décoratif. Un incident se raconte toujours après coup, quand la ressource fautive a été remplacée, redéployée ou détruite, et que plus personne ne peut l'inspecter. Ce qui reste, ce sont les séries temporelles collectées pendant qu'elle vivait. Sur Cockpit, elles tiennent pendant la rétention de leur source, trente et un jours par défaut pour les métriques, sept pour les journaux, et cette asymétrie décide de ce que vous pourrez reconstituer. Une enquête menée le lendemain dispose des deux ; la même enquête menée trois semaines plus tard ne dispose plus que des métriques. C'est une raison suffisante pour décider la rétention avant l'incident, et non pendant.

Un changement d'étiquette crée une série neuve

Le même relevé montre lab2-kapsule deux fois, une série avec autohealing=false, une autre avec autohealing=true. Ce n'est pas un doublon : l'autoréparation a été activée pendant la vie du cluster, et comme cette valeur est une étiquette, sa modification a produit une série distincte.

Conséquence pratique, et elle mord au pire moment : une requête qui agrège sans précaution comptera deux clusters là où il n'y en a qu'un, et une alerte fondée sur la continuité d'une série se déclenchera à l'instant du changement d'étiquette, sans qu'aucune panne ne soit survenue.

Nettoyer

Le seul objet créé par cette leçon est le jeton.

scw cockpit token delete "$(echo "${TOK}" | jq -r '.id')" region=fr-par

Les sources Scaleway, elles, ne se suppriment pas du tout : la documentation les déclare en lecture seule et non supprimables. Seule une source custom se supprime. Ce qui efface l'historique d'une source Scaleway, c'est de réduire sa rétention, et l'opération est irréversible : les données au delà de la nouvelle fenêtre sont détruites définitivement.

La vérification de sortie de cette leçon consiste donc à relire usage-overview et à constater que les compteurs external_* valent toujours zéro.

Ce que ce lab a prouvé

Ce lab a la particularité de n'avoir rien construit : tout ce qu'il établit était déjà là.

Ce qui a été prouvé	Mesure
Cockpit s'active sans intervention	sources créées les 2026-09-11 et 2026-09-12, par personne
La collecte Scaleway ne facture pas l'ingestion	external_metrics, external_logs, external_traces à zéro
Les métriques survivent à la ressource	5 clusters détruits, toujours interrogeables
Un incident passé se relit dans la courbe	lab4-kapsule : 2 nœuds à 08:53, 1 à 09:03
Un changement d'étiquette casse une agrégation	lab2-kapsule présent deux fois, autohealing false puis true

Glissez pour voir

Ce qui a résisté : le compteur d'usage lui-même. Sa fenêtre couvre le mois en cours, pas la durée de collecte, et sa valeur décroît d'une lecture à l'autre. Le prendre pour un cumul conduirait à des conclusions fausses sur le volume produit.

Ce qu'il faut retenir de l'absence de construction : l'observabilité utile ne se décide pas pendant l'incident. Ce lab n'a rien pu inventer, il n'a lu que ce qui avait été collecté avant qu'on en ait besoin.

Dépendances de destruction : il n'y en a qu'une.

Objet	À détruire	Pourquoi
Jeton de lecture	oui	il porte un secret, et rien ne l'expire
Sources de données Scaleway	non, impossible	en lecture seule et non supprimables

Glissez pour voir

Coût de la session : zéro. Aucune ressource facturée n'a été créée.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

Limites, quotas et plafonds

• Rétention par défaut : 31 jours pour les métriques, 7 jours pour les journaux et les traces. Maximum 5 ans ; minimum 1 jour pour les journaux et les sources custom, mais 31 jours pour les métriques Scaleway.
• Au delà du défaut, le stockage est facturé : 0,0002 EUR par 10 millions d'échantillons et par jour pour les métriques, 0,002 EUR par Go et par jour pour les journaux et les traces.
• Exemple chiffré officiel : 2 Go de journaux par jour conservés 90 jours coûtent 9,96 EUR par mois, contre 0,36 EUR pour une rétention de 10 jours.
• Les données Scaleway sont liées à leur région : « you cannot configure a different region for where this automatically collected data is stored ». Un Grafana unique interroge en revanche toutes les régions.
• Six paliers de remise au volume sur les métriques custom, de 0,15 à 0,08 EUR par million d'échantillons.

Dépannage

Symptôme	Cause probable	Solution
data-source list renvoie []	aucune ressource intégrée n'a encore existé dans ce projet	créer une ressource intégrée, la source apparaît seule
unknown_scope accepté à la création du jeton, puis requête refusée	unknown_scope est la valeur par défaut de l'énumération, pas une permission	nommer explicitement read_only_metrics
La requête ne renvoie rien, corps vide	jeton absent ou invalide	relancer avec curl -w '%{http_code}' : 401 sans en-tête, 403 avec un jeton invalide
Un tableau de bord préconfiguré reste vide	la région sélectionnée en haut du tableau ne correspond pas à celle de la ressource	changer la région dans le menu déroulant du tableau
Un cluster apparaît en double dans une agrégation	une étiquette a changé en cours de vie, créant une seconde série	agréger sans l'étiquette instable, ou fixer la fenêtre
La facture d'observabilité monte sans nouvelle ressource	un agent pousse des données déjà collectées gratuitement	vérifier la table d'intégration avant d'installer un agent

Glissez pour voir

Antipatterns à éviter

Ces quatre erreurs ont la même racine : elles traitent Cockpit comme une solution à installer, alors qu'il est déjà là.

Antipattern	Conséquence	Discipline
Installer un agent « pour tout homogénéiser »	des données gratuites deviennent facturées, à l'identique	lire la table d'intégration avant d'installer quoi que ce soit
Monter la rétention « au cas où »	le stockage au delà du défaut se facture chaque jour	choisir la rétention sur un besoin d'enquête réel, pas par confort
Créer un jeton à portée large pour un script de lecture	un jeton d'écriture permet d'ingérer dans une source custom, donc de faire dépenser	une portée par usage, read_only_metrics pour lire
Attendre l'incident pour découvrir ce qui est collecté	on cherche une métrique qui n'a jamais existé, au pire moment	inventorier les familles disponibles avant d'en avoir besoin

Glissez pour voir

Cockpit sous l'angle Well-Architected

Excellence opérationnelle

Question clé : que saurez-vous d'un incident une fois la ressource disparue ? Les métriques restent 31 jours après la destruction, ce qui rend un post-mortem possible sur une infrastructure déjà reconstruite. La discipline consiste à inventorier les familles disponibles avant l'incident, parce qu'une métrique absente ne se rattrape pas après coup : ce qui n'a pas été collecté n'existe pas.

Optimisation des coûts

Question clé : quelle part de votre observabilité passe par un chemin facturé ? Les trois compteurs external_* donnent l'ingestion, et elle seule : la rétention étendue se lit ailleurs, sur la facture. La discipline est de les surveiller comme une ligne de facture, et de considérer tout agent installé comme une dépense nouvelle, y compris quand il collecte des données que la plateforme fournit déjà gratuitement.

Sécurité

Question clé : que peut faire le jeton qui traîne dans votre script ? Les portées d'un jeton Cockpit séparent la lecture de l'écriture, et l'écriture permet d'ingérer dans une source custom. Un jeton trop large n'expose donc pas seulement des données, il expose un levier de dépense. La discipline est une portée par usage, et un jeton qui meurt avec le script qui l'a créé.

À retenir

• Cockpit est rattaché au projet et s'active seul, dès la première ressource intégrée.
• Les données Scaleway sont gratuites, rétention par défaut comprise : 31 jours de métriques, 7 jours de journaux.
• Seuls les compteurs external_* facturent l'ingestion. La rétention étendue se facture à part, y compris sur une source Scaleway, et n'apparaît pas dans ce relevé.
• Pousser soi-même une donnée Scaleway la rend facturée, et la range dans une source custom séparée, hors des tableaux préconfigurés.
• Container Registry, Elastic Metal, Key Manager et Audit Trail ne sont pas intégrés ; Kapsule, les bases managées et les Load Balancers le sont pour les métriques et les journaux.
• L'endpoint est compatible Prometheus : query_range suffit à relire un incident.
• Les métriques survivent à la ressource, pendant la rétention de leur source, 31 jours par défaut.
• Un changement d'étiquette crée une série neuve, ce qui fait compter deux fois une même ressource.

Pour aller plus loin

• PromQL : le langage de requête Prometheus : l'endpoint de Cockpit étant compatible Prometheus, tout ce que vous apprendrez là s'y applique directement.
• Grafana : créer des dashboards et configurer l'alerting : l'outil que Cockpit expose, vu de l'intérieur, pour dépasser les tableaux préconfigurés.

Ressources externes

• Cockpit pricing information : les tarifs d'ingestion, les six paliers de remise et les exemples chiffrés de rétention étendue.
• Cockpit product integration : la table produit par produit des métriques et journaux collectés, à lire avant d'installer un agent.
• Cockpit FAQ : la distinction entre données Scaleway et custom, et la règle de stockage par région.

×

📖 Voir la documentation →