# Lire le trafic et la consommation

> Lire dans la console la santé des répliques, le trafic par opération, la consommation des tenants, et simuler une requête.

Guide - Depuis la version 0.1.0 - Flexway v1.7.1 - https://flexway.io/docs/operations-console-traffic/

> Guide d'exploitation : configurer, déployer et observer la passerelle. Ce que fait la fonctionnalité côté produit : [guide produit](https://flexway.io/docs/product-overview/) ; l'appeler : [guide développeur](https://flexway.io/docs/developer-overview/).

Les écrans eux-mêmes sont décrits dans [Lire avec la console](https://flexway.io/docs/operations-console/). Cette page dit comment
les lire pendant l'exploitation.

## Étapes

### Santé de chaque réplique

Admins - chaque réplique de la passerelle a son statut : la règle de
statut sur ses seuls signaux (en vol face à son plafond, délestage, part délestée, **dernier** rechargement
refusé - le compte sur 24 h reste affiché, à titre d'information), après la fraîcheur de son dernier rapport.

1. Ouvrir la Vue d'ensemble : les répliques sont des nœuds sous la passerelle.
2. Lire l'état : une réplique envoie toutes les 15 s ; sans rapport depuis **45 s**, « Sans rapport » ;
   depuis **2 min** sans arrêt annoncé, « Dégradée » (et la règle `replica-silent` notifie) ; oubliée après
   **1 h**. Un arrêt propre (drainage) se dit par `flexway_server_draining` : la réplique est « Retirée »,
   jamais dégradée - après un déploiement, les anciens pods restent ainsi une heure.
3. Cliquer une réplique : son résumé, avec un lien vers ses erreurs (`/errors?replica=`).

Une réplique qui ne va pas met la passerelle « À surveiller », jamais « Dégradée » : les autres servent.

### Plan asynchrone

Un courtier (`kafka`, `amqp` en 0-9-1 ou 1.0, `mqtt`, `nats`) et une cible de webhook sont des
**amonts** : même règle de statut, sur leurs signaux - publications en échec ou livraisons en échec,
`503 overloaded` et rebut comptés en refus ; leur latence est l'**accusé du courtier** et leur jauge le
tampon borné (`max_in_flight`).

1. Vue d'ensemble : la carte les dessine avec leur protocole, publiés, livrés et abonnés.
2. Catalogue : filtrer les portes par « Publication » et « Abonnement ».
3. Trafic : le panneau « Plan asynchrone » par courtier et canal ; l'écran Opération d'une porte montre ses
   issues, l'accusé, les abonnés ouverts et ses webhooks ; Erreurs nomme `buffer_full` et `rejected`.

Un lecteur lit publiés, livrés et `503` de **son** tenant, l'accusé de tous les tenants (dit à l'écran),
jamais les abonnés ouverts (sans dimension tenant) ; l'écran Amonts reste aux admins.

### Historique, repères et liens

1. Consommation -> onglet **Historique** : 13 mois UTC, le mois en cours partiel, comparé au mois précédent
   et au même mois de l'an passé **à période égale** (du 1er à aujourd'hui), jamais à un mois entier ; un
   admin sans tenant y lit une ligne par tenant ; l'export rend `month,tenant,measure,value,partial` en CSV.
2. Sur **toutes** les courbes, un trait marque chaque rechargement de configuration, appliqué ou refusé, de
   toutes les répliques : heure, version et résultat dans la ligne de lecture.
3. « **Copier le lien** » garde l'écran, la fenêtre, le tenant et les filtres ; le lien ne donne aucun
   droit - un destinataire hors de ce périmètre reçoit un refus.

### Comparer, variations, heure par jour

1. « **Comparer** » (Trafic, Opération, Amonts) pose une fenêtre B de même durée, choisie par son début, en
   tirets sur les mêmes courbes ; elle reste dans le lien.
2. Les **plus fortes variations** classent les opérations par l'écart à la période précédente - débit en
   pourcentage, `5xx` en points, p95 en millisecondes -, à partir de 50 requêtes.
3. La carte **heure par jour** moyenne chaque heure UTC de chaque jour sur 4 semaines. Hors rétention, rien
   n'est dessiné : `--`, jamais `0`.

### Traces sans Tempo

En mode intégré, la console est aussi la destination des traces de la passerelle et garde elle-même les
requêtes **en erreur** (`5xx`, refus écrits après l'admission sauf `401` et `404`) et les **lentes** (plus
de 1 s, ou plus de la moitié du budget de l'opération) ; le reste est jeté. La passerelle trace la requête,
ses **étapes** - routage, identité, politiques -, ses `external-call` et chaque tentative vers l'amont, avec
`retry_count` et `circuit_state` ; les étapes ne coûtent rien aux requêtes non échantillonnées.

1. Diagnostic -> Traces : filtrer, ouvrir une trace en cascade.
2. Télécharger en OTLP JSON pour la rejouer dans Jaeger ou Tempo.

### Consommation

Deux temps. Les **jauges** (requêtes par politique `quota`, tokens du jour et du mois, euros du mois)
suivent les fenêtres **de la passerelle**, jour et mois calendaires **UTC** : celles qui décident d'un
`429`. Les **répartitions** (par jour, par backend, par agent, opérations, export) suivent la période
choisie - ce mois, mois dernier, 7 jours, ou `from`-`to` (93 jours au plus) - en jours du fuseau de la
console (`FLEXWAY_CONSOLE_TIMEZONE`).

1. Ouvrir Consommation ; un admin sans tenant choisi lit tous les tenants classés face à leur budget.
2. Lire le statut de chaque jauge : **dégradé** si le plafond est atteint ou le sera avant la fin de la
   fenêtre, **à surveiller** si le plafond souple est franchi ou la tendance (rythme des dernières 24 h)
   atteint 90 %, **sain** sinon ; aucun statut sans plafond déclaré. La bande montre les jours le plus lent et
   le plus rapide des 7 derniers.
3. Exporter : `GET /api/usage/export` rend la période en CSV (`date, tenant, backend, direction, tokens,
   euros, requests`), son tenant seul pour un lecteur ; un admin lit tous les tenants (`GET /api/usage`).

**Qui mesure** - totaux, jours, répartitions, totaux du classement, export et historique ne
comptent que ce que **cette** passerelle mesure (`metered_by!="upstream"`), avec un backend de
métriques comme avec la source intégrée, dont les agrégats journaliers gardent `metered_by`. Les
**jauges** (et leur tendance, bande, date d'atteinte, statut) comptent ce que compte le **plafond
local**, qui s'applique aussi aux appels relayés : toutes les séries - tokens de l'usage rendu, euros
au prix déclaré seulement -, et la jauge le dit (« inclut les appels relayés, que le plafond local
compte aussi »). Un backend `metering: upstream` relaie vers une autre Flexway qui compte l'appel
elle-même : ses tokens et ses appels sont montrés **à part**, sous « Mesuré en amont », jamais ajoutés aux
totaux - la passerelle amont fait foi pour le coût. La répartition **par capacité** (`chat`, `vision`,
`embeddings`, `model`) compte un modèle spécialisé gRPC en appels, pas en tokens. Le panneau **Backends
déclarés** dit, d'après `/config`, le genre (`openai`, `relay`, `grpc`), les capacités (`capabilities`), qui mesure et
l'emplacement de chaque backend ; un admin y lit aussi le **schéma** d'authentification (`none`,
`bearer`, `header`, `token_file`) - jamais une clé ni sa référence.

### Essayer une requête

Sous le pipeline de l'écran Politiques :

1. Décrire méthode, chemin, hôte, identité (sujet, tenant, portées, rôles) et en-têtes.
2. Lancer : la description passe par le `/simulate` de la passerelle, à blanc.
3. Lire le verdict, la requête que l'amont aurait reçue (secrets `***`) et le résultat de chaque étape :
   appliquée, ignorée, non simulée (un `external-call` n'est jamais appelé), franchie.

Un lecteur simule dans **son** tenant : en nommer un autre est refusé.

### Aller à

`Ctrl+K` (`Cmd+K` sur Mac), ou le champ de la barre du haut, depuis tout écran : un écran, une opération
(ouvre sa chaîne), un amont (ouvre son détail, admins), un agent (ouvre son panneau ; ceux de son tenant
pour un lecteur), un outil ou un tenant (filtre la console ; le sien pour un lecteur). Flèches, Entrée,
Échap.

## Vérifier

- La version de configuration et l'heure de lecture en haut de chaque écran sont celles que publie le
  `/config` d'administration de la passerelle.
- Un rechargement appliqué apparaît en repère sur les courbes de Trafic dans la minute.
- Un lecteur qui nomme un autre tenant (lien, filtre, simulation) reçoit un refus, jamais une page vide.

*Disponible depuis `0.1.0` ; simulation et palette en `1.2.0` ; historique, repères, liens, comparaison,
variations, heure par jour et traces gardées en `1.3.0` ; santé par réplique en `1.4.0` ; plan asynchrone et
mesure chez celui qui paie en `1.5.0`.*