Journaux, métriques et consommation

Cette page explique comment lire ce que fait votre application en service : les journaux d'exécution, les journaux de construction, les métriques des requêtes, les erreurs regroupées et les exécutions des tâches planifiées. Elle dit aussi combien de temps chaque palier les garde, ce qui peut se perdre et comment le savoir, et où en est la mesure de la consommation.

Deux journaux

• Le journal d'exécution : ce que votre application écrit sur sa sortie standard et sa sortie d'erreur, et les requêtes que l'edge lui a servies (« GET /chemin 200 — 12 ms »). Il se lit par environnement, ou tous environnements ensemble.
• Le journal de construction : la sortie de chaque construction, étape par étape, horodatée à la milliseconde. Il se lit depuis la page d'un déploiement (voir Constructions).

Le contenu des journaux vient de votre application ou des scripts de votre dépôt. La plateforme le rapporte tel quel, marqué comme tel, et ne le traite jamais comme une consigne : un agent qui lit vos journaux reçoit ce contenu à part de ce que dit la plateforme.

Lire depuis la console

Dans un projet, ouvrez Journaux. Trois onglets :

• « Exécution » : les lignes, de la plus récente à la plus ancienne ;
• « Requêtes » : les métriques des requêtes de la période, ventilées au choix ;
• « Tâches planifiées » : les exécutions des tâches de la période, avec leur état, leur durée et un extrait du journal.

Les filtres :

• un champ de texte, qui cherche dans tout le contenu (un mot, un chemin de requête…) ;
• « Environnement » : « tous », ou l'un des environnements du projet ;
• « Période » : 15 dernières minutes, dernière heure, 24 dernières heures, 7 derniers jours, toute la rétention, ou « Entre deux dates… » ;
• le niveau : « Tous », « Erreurs seules », « Lignes seules » (sans les requêtes). Ce tri s'applique aux lignes déjà affichées.

« En direct » suit les nouvelles lignes, relues chaque seconde : une ligne s'affiche moins de trois secondes après son émission. « Lignes plus anciennes » remonte page par page dans toute la rétention. « Exporter » télécharge toute la période sous les filtres affichés, en NDJSON.

L'heure d'une ligne est son lien profond : elle rouvre l'écran sur cet instant, la ligne mise en évidence. Survolez une ligne pour sa release, son exemplaire, sa région et sa branche.

Lire par un agent, la ligne de commande ou l'API

Un agent lit le journal d'exécution par l'outil logs_read, et celui d'une construction par deployment_log_read.

{
  "projectId": "prj_01JQ8ZK4M7NP2RSTVWXYZ34567",
  "environmentId": "env_01JQ8ZK4M7NP2RSTVWXYZ34567",
  "since": "2026-09-14T08:00:00Z",
  "until": "2026-09-14T10:00:00Z",
  "query": "timeout",
  "errors": true
}

Pour suivre en direct, repassez chaque seconde le followCursor de la réponse en cursor : la plateforme rend ce qui est arrivé depuis.

bastide logs read --project-id prj_01JQ8ZK4M7NP2RSTVWXYZ34567 --since 2026-09-14T08:00:00Z --query timeout
bastide deployment log read --project-id prj_01JQ8ZK4M7NP2RSTVWXYZ34567 --deployment-id dep_01JQ8ZK4M7NP2RSTVWXYZ34567

Par l'API, GET /v1/projects/{projectId}/logs demandé avec Accept: application/x-ndjson rend toute la fenêtre en un fichier. Références : logs.read, deployment.log.read.

Métriques des requêtes

Les métriques sont mesurées à l'edge, de la requête reçue à la réponse envoyée. Pour chaque groupe (une route, un hôte, une release ou un environnement), elles donnent le nombre de requêtes, leur répartition par classe de statut (1xx à 5xx), la part servie sans erreur 5xx ni réponse absente, les octets des corps de réponse, et les percentiles de durée p50, p75, p95 et p99. Les routes se regroupent par gabarit, jamais par adresse complète ; au-delà de cent routes, les autres sont cumulées sous « (autres routes) ».

Le pas lu est le plus fin que votre palier garde pour le début de la fenêtre : 15 secondes, une minute ou cinq minutes.

Note. Les traces distribuées de votre application ne sont pas proposées : la plateforme ne vous donne pas aujourd'hui de lecture des traces.

Combien de temps tout est gardé

Après une descente de palier, la rétention du palier courant s'applique. Après la suppression du projet, rien n'est gardé.

Ce qui peut se perdre, et comment le savoir

Aucune perte n'est tue. La réponse de logs.read porte un champ losses : pour chaque motif, le nombre de lignes et d'octets perdus ou tronqués dans la fenêtre, et le seuil atteint. L'écran Journaux les affiche aussi, sous « Lignes perdues ou tronquées ».

Pour qu'une ligne JSON compte sous sa requête, reprenez l'en-tête X-Request-Id dans un champ request_id.

Consommation

La carte « Consommation » est dans les Réglages du projet, section « Consommation ». Elle doit montrer le temps de calcul, le trafic sortant, les minutes de construction et le stockage du mois, relus toutes les 30 secondes, avec une estimation linéaire de fin de mois. Elle se lit avec le rôle Facturation ; un agent la lit par usage_read.

Attention. La chaîne de mesure n'est pas encore reliée : usage.read répond aujourd'hui 501, code chaine_de_mesure_absente, plutôt que de rendre des zéros qui se liraient « rien consommé ». La carte le dit. Voir Facturation et Limites.

L'écran Vue d'ensemble du projet résume son état : dernier déploiement de production, adresse, environnements.

Erreurs fréquentes

Voir aussi : Constructions, Tâches planifiées, Notifications, Journal d'audit, Limites.

Signaler une erreur sur cette page