Observabilité Scaleway : la carte du volet

Cockpit collecte tout seul, mais il n'alerte pas tout seul. C'est la dissymétrie qui organise ce volet, et elle surprend : les sources de données apparaissent sans qu'on les demande, tandis que le gestionnaire d'alertes reste éteint jusqu'à ce que quelqu'un l'active. Cette carte pose les briques du volet, sépare ce qui est gratuit de ce qui se facture, nomme la seule décision irréversible de l'observabilité, et dit ce qu'il faut avoir décidé avant l'incident. Aucune ressource n'est créée ici : tous les relevés sont en lecture seule.

Ce que vous allez apprendre

• Distinguer ce que Cockpit fait seul de ce qu'il faut activer
• Citer les briques du volet et le rôle de chacune
• Nommer la décision irréversible de l'observabilité
• Savoir ce que coûte la collecte, et à partir de quand
• Repérer les commandes dépréciées et celles qui sont encore vides

Prérequis

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

De quoi le volet observabilité est-il fait ?

Le binaire expose douze briques, et elles ne jouent pas toutes dans la même catégorie.

scw cockpit -h | sed -n '/AVAILABLE COMMANDS/,/^$/p'

Relevé le 2026-09-12 avec scw 2.62.0, elles se rangent en quatre familles.

Famille	Briques	Ce qu'elles décident
Ce qui stocke	data-source, plan	où vont les données, combien de temps, à quel prix
Ce qui donne accès	token, grafana, grafana-user	qui lit, qui écrit, avec quelle portée
Ce qui alerte	alert-manager, contact-point, managed-alerts, test-alert	ce qui vous réveille, et qui est prévenu
Ce qui montre	product-dashboards	les tableaux fournis, par produit
Ce qui mesure	usage-overview, config	ce que vous consommez, et ce que vous payez

Glissez pour voir

Deux briques à ne pas bâtir dessus

grafana-user est déprécié, et les quatre sous-commandes portent la même mention de fin de vie, le 20 janvier 2026. La gestion des accès passe désormais par l'IAM de la plateforme, comme pour le reste du catalogue.

managed-alerts n'expose aucune sous-commande en 2.62.0 : le groupe existe, il est vide. L'activation des alertes gérées passe par alert-manager, dont le relevé porte le champ managed_alerts_enabled.

Une commande dépréciée et une commande vide dans le même produit, c'est le signe d'un volet en mouvement : vérifiez la version que vous avez avant de recopier une procédure trouvée ailleurs.

Qu'est-ce que Cockpit fait sans qu'on le demande ?

Il collecte, et rien d'autre. Le relevé tient en deux commandes, et leur contraste est tout le propos de ce volet.

scw cockpit data-source list region=fr-par -o json | jq 'length'

scw cockpit alert-manager get region=fr-par -o json \
  | jq '{alert_manager_enabled, managed_alerts_enabled}'

Sur un projet qui a hébergé des ressources, la première renvoie 2 : une source de métriques et une source de journaux, créées seules. La seconde renvoie :

{"alert_manager_enabled": false, "managed_alerts_enabled": false}

Personne ne sera prévenu de quoi que ce soit. La plateforme a rangé onze jours de données sans qu'on lève le petit doigt, et elle n'enverra aucun message le jour où quelque chose tombera. C'est cohérent, une alerte engage un destinataire et un canal, mais c'est exactement l'inverse de ce qu'on suppose quand on découvre que la collecte s'est faite toute seule.

Un alert manager éteint le dit d'ailleurs franchement dès qu'on l'interroge.

scw cockpit contact-point list region=fr-par -o json

La sortie n'est pas une liste vide, c'est une erreur :

{"message": "cannot find resource 'alertmanager' with ID <votre-project-id>"}

Le message désigne l'objet manquant, pas une absence de points de contact. Le lire comme « je n'ai pas encore créé de contact » ferait chercher au mauvais endroit.

Que coûte l'observabilité, et à partir de quand ?

Un seul plan existe, il est gratuit, et il porte pourtant des prix.

scw cockpit plan get -o json | jq '{name, monthly_price, sample_ingestion_price,
  logs_ingestion_price, traces_ingestion_price}'

Relevé le 2026-09-12 :

{"name": "free", "monthly_price": 0, "sample_ingestion_price": 15,
 "logs_ingestion_price": 35, "traces_ingestion_price": 35}

Deux choses méritent qu'on s'y arrête. Les prix sont en centimes, et ils correspondent aux tarifs publiés, 0,15 EUR par million d'échantillons et 0,35 EUR par Go. Et surtout, le CLI porte ici les prix, ce que rdb node-type list ne fait pas : selon le produit, le binaire sait ou ne sait pas chiffrer, et il ne faut donc pas généraliser depuis un seul.

Le plan à zéro euro n'est pas une offre d'appel : la collecte Scaleway est gratuite, et ce sont l'ingestion de données que vous poussez et la rétention au-delà du défaut qui se facturent.

Mais le plan ne porte pas tous les postes, et deux d'entre eux touchent précisément ce que cette carte vous demande d'activer. La grille tarifaire publique en compte cinq, relevée le 2026-09-12 :

Poste	Tarif	Ce qui le déclenche
Données Scaleway, rétention par défaut	inclus	rien, c'est l'état de départ
Ingestion custom	0,15 € par million d'échantillons, 0,35 € par Go de journaux ou de traces	tout ce que vous poussez vous-même
Rétention étendue	0,0002 € par 10 millions d'échantillons et par jour, 0,002 € par Go et par jour	dépasser 31 jours de métriques ou 7 jours de journaux
Règle d'alerte active	0,015 € par jour et par règle, préconfigurée ou non	activer l'alerting, ce que la suite du volet fait
Export de données	0,15 € par Go de journaux, 0,07 € par million d'échantillons de métriques	depuis le 1er avril 2026, fin de la gratuité de bêta

Glissez pour voir

Deux points méritent d'être retenus tout de suite. Une règle d'alerte se facture qu'elle se déclenche ou non : c'est son existence qui compte, et Scaleway recommande explicitement de désactiver les règles inutiles. Trente règles oubliées coûtent 13,50 € par mois sans avoir jamais servi. Et l'export n'est plus gratuit : la page tarifaire l'applique depuis le 1er avril 2026, alors que la documentation produit, validée le 20 janvier 2026, le dit encore « free of charge during the beta period ». Quand la grille et la doc divergent, la grille facture.

Ces deux commandes ignorent la région

scw cockpit plan get et scw cockpit product-dashboards list refusent l'argument region : unknown argument 'region', avec pour seuls arguments valides project-id et, pour la seconde, des étiquettes.

Ce n'est pas un oubli. Un plan et un catalogue de tableaux de bord sont rattachés au projet, pas à une région, là où les sources de données sont bien régionales. Dans un même produit, les objets n'ont donc pas tous la même portée, et l'argument accepté est le meilleur indice dont vous disposiez.

Qu'est-ce qui est fourni, et pour quels produits ?

Cinquante-six tableaux de bord sont livrés sans rien construire.

scw cockpit product-dashboards list -o json \
  | jq -r 'length as $n | "\($n) tableaux", (.[] | .tags[]?)' \
  | tail -n +2 | sort | uniq -c | sort -rn | head -10

Le classement par étiquette dit où l'effort de la plateforme s'est porté :

56 scw          6 network      5 kubernetes    4 logs
 3 serverless-containers       3 messaging     3 hpc      3 cockpit

Les 56 portent l'étiquette scw : ce sont tous des tableaux de la plateforme, aucun n'est à vous. Le réseau et Kubernetes sont les mieux servis, ce qui recoupe la table d'intégration : les produits qui envoient métriques et journaux sont ceux qui ont des tableaux prêts. Un produit non intégré n'a évidemment pas de tableau, et c'est le premier endroit où vérifier avant de promettre une visualisation à une équipe.

Quelle décision ne pourrez-vous plus reprendre ?

Il n'y en a qu'une, et elle détruit des données.

Décision	Réversible ?	La raison
Réduire la rétention d'une source	non	« Reducing the retention period will permanently delete all observability data beyond the selected timeframe. This deletion is irreversible »
Augmenter la rétention	oui	mais le stockage au-delà du défaut se facture chaque jour
Activer l'alert manager	oui	il se désactive
Créer un jeton	oui	il se supprime, et rien ne l'expire
Supprimer une source Scaleway	sans objet	elles sont en lecture seule et non supprimables

Glissez pour voir

La première ligne est la seule qui compte vraiment. Baisser une rétention pour économiser quelques euros efface l'historique qui aurait servi au prochain post-mortem, et l'opération ne se rejoue pas. C'est la décision à prendre à froid, en sachant sur quelle profondeur d'enquête on accepte de renoncer.

Que faut-il avoir décidé avant l'incident ?

Ce tableau part du besoin, pas du réglage. Il se lit de gauche à droite.

Votre besoin	Quand le décider	Pourquoi pas plus tard
Savoir qu'un service est tombé	avant : activer l'alert manager et poser un point de contact	un alert manager éteint n'envoie rien, et ne rattrape pas le passé
Enquêter sur un incident d'hier	avant : vérifier que le produit est intégré	une métrique jamais collectée ne se reconstitue pas
Enquêter sur un incident d'il y a trois semaines	avant : porter la rétention des journaux au-delà de 7 jours	les journaux du défaut ont déjà disparu
Contenir la facture d'observabilité	avant : décider si un agent est nécessaire	ce que vous poussez est facturé, même venant d'un produit Scaleway

Glissez pour voir

La colonne du milieu ne contient qu'un mot, et c'est voulu.

L'observabilité est le seul domaine de ce parcours où tout se décide en amont, et cette particularité mérite d'être comprise plutôt que retenue. Partout ailleurs, une erreur de configuration se rattrape : un réseau se refait, une base se restaure, un cluster se reconstruit, et l'on peut réparer après coup ce qu'on avait mal posé. Une métrique manquante, elle, ne se reconstitue pas. Un journal effacé par une rétention trop courte ne revient pas. Une alerte non configurée ne rattrape pas la panne qu'elle aurait dû signaler. Le jour de l'incident, vous ne disposez que de ce que la plateforme avait déjà collecté, avec la profondeur que vous aviez déjà choisie, et vous n'êtes prévenu que si quelqu'un l'avait décidé avant. C'est la raison pour laquelle une carte d'observabilité se lit au début d'un projet, et non quand le premier incident survient.

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 pour toute source ; minimum 1 jour pour les journaux et les sources custom, mais 31 jours pour les métriques Scaleway, qui ne descendent pas sous leur défaut.
• Ingestion custom : 0,15 EUR par million d'échantillons, 0,35 EUR par Go de journaux ou de traces, avec six paliers de remise au volume.
• Stockage au-delà du défaut : 0,0002 EUR par 10 millions d'échantillons et par jour, 0,002 EUR par Go et par jour.
• 56 tableaux de bord fournis, tous côté plateforme.
• Les données Scaleway sont liées à leur région et ne peuvent pas être déplacées ; un seul Grafana les interroge toutes.

Dépannage

Ces quatre blocages arrivent avant toute construction. Trois viennent de la même cause : une brique rattachée au projet interrogée comme si elle était régionale, ou l'inverse.

Symptôme	Cause probable	Solution
unknown argument 'region' sur plan get	le plan est rattaché au projet, pas à une région	retirer region, passer project-id si besoin
cannot find resource 'alertmanager' with ID …	l'alert manager n'est pas activé sur ce projet	l'activer avant de lister ou créer un point de contact
data-source list renvoie []	aucune ressource intégrée n'a encore existé	créer une ressource intégrée, les sources apparaissent seules
Une sous-commande grafana-user avertit d'une fin de vie	la brique est dépréciée depuis le 2026-01-20	passer par l'IAM de la plateforme

Glissez pour voir

Antipatterns à éviter

Ces quatre erreurs partagent la même racine : elles confondent collecter et surveiller.

Antipattern	Conséquence	Discipline
Conclure que « tout est surveillé » parce que les données arrivent	personne n'est prévenu le jour de la panne	vérifier alert_manager_enabled avant de le croire
Baisser une rétention pour économiser	l'historique est détruit définitivement	traiter la baisse de rétention comme une suppression
Installer un agent pour uniformiser la collecte	une donnée gratuite devient facturée	lire la table d'intégration avant d'installer
Promettre un tableau de bord sur un produit non intégré	il n'y a rien à afficher, et on le découvre en réunion	vérifier l'intégration du produit d'abord

Glissez pour voir

L'observabilité sous l'angle Well-Architected

Excellence opérationnelle

Question clé : que saurez-vous, et par quel canal l'apprendrez-vous ? Les deux ne vont pas ensemble sur cette plateforme : la collecte est automatique, la notification ne l'est pas. La discipline consiste à traiter l'activation de l'alerte comme une étape de mise en production, au même titre que le déploiement, et non comme un réglage qu'on fera « quand on aura le temps ».

Optimisation des coûts

Question clé : par quel chemin vos données arrivent-elles ? Ce que la plateforme collecte est gratuit, ce que vous poussez est facturé, y compris quand cela vient d'un produit Scaleway. La discipline est de considérer tout agent installé comme une dépense nouvelle, et de vérifier l'intégration avant de le poser. La rétention est le second levier, et le seul qui se paie chaque jour.

Sécurité

Question clé : qui peut lire vos métriques, et qui peut en écrire ? Un jeton d'observabilité sépare les deux, et l'écriture permet d'ingérer, donc de faire dépenser dès qu'une source custom existe. La discipline est une portée par usage et un jeton qui meurt avec le script qui l'a créé, d'autant que rien n'expire un jeton Cockpit.

À retenir

• Cockpit collecte seul, mais n'alerte pas seul : alert_manager_enabled vaut false tant que personne ne l'active.
• Un alert manager éteint répond par une erreur de ressource introuvable, pas par une liste vide.
• Un seul plan existe, free, à 0 EUR par mois, mais il ne porte pas tous les postes : la grille en compte cinq, dont deux que le CLI ignore.
• Une règle d'alerte active coûte 0,015 EUR par jour, qu'elle se déclenche ou non : c'est le prix de ce que la suite du volet va activer.
• L'export de données n'est plus gratuit depuis le 1er avril 2026, alors que la documentation produit l'annonce encore en bêta gratuite.
• plan et product-dashboards sont des objets de projet : ils refusent l'argument region, que data-source exige.
• 56 tableaux de bord sont fournis, tous côté plateforme ; réseau et Kubernetes sont les mieux servis.
• Réduire une rétention détruit définitivement les données au-delà de la nouvelle fenêtre. C'est la seule décision irréversible du volet.
• grafana-user est déprécié depuis le 2026-01-20, et managed-alerts n'a aucune sous-commande en 2.62.0.
• Tout se décide avant l'incident : le jour venu, on ne lit que ce qui a été collecté.

Pour aller plus loin

• PromQL : le langage de requête Prometheus : le langage dans lequel s'écrivent les requêtes et les règles d'alerte que cette carte vous fait décider.
• Grafana : créer des dashboards et configurer l'alerting : ce que les cinquante-six tableaux fournis ne couvrent pas, et comment poser les vôtres.

Ressources externes

• Cockpit product integration : la table produit par produit des métriques et journaux collectés, à lire avant de promettre un tableau de bord.
• Cockpit pricing information : les tarifs d'ingestion, les six paliers de remise et le coût de la rétention étendue.
• How to change data retention : la procédure, et l'avertissement sur le caractère irréversible d'une baisse.
• Grille tarifaire Cockpit : le seul endroit qui publie le coût d'une règle d'alerte et celui de l'export, tous deux absents de la page de documentation tarifaire.

×

📖 Voir la documentation →