Lire le trafic et la consommation

Guide d'exploitation : configurer, déployer et observer la passerelle. Ce que fait la fonctionnalité côté produit : guide produit ; l'appeler : guide développeur.

Les écrans eux-mêmes sont décrits dans Lire avec la 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.