Trafic (E/S réseau)

Vue d’ensemble — à quoi sert cet écran

Infrastructure ▸ Connectivité et trafic ▸ Trafic (/infra/traffic/net) est une console en lecture seule qui trace le débit d’E/S réseau de chaque serveur (octets et paquets entrants et sortants) sous la forme d’une courbe ECharts par carte de serveur.

La source est la table héritée server_traffic (≈1,6 million de lignes, connexion legacy_glory), alimentée par le collecteur hérité check_tx.js. Cette table accumule, par fenêtre, les deltas d’octets et de paquets pour chaque serveur × direction (entrant/sortant), mais l’ancienne interface stats-design n’a jamais affiché que le traffic-out de server_status (un unique delta de paquets sortants). Cet écran est le premier à exposer le jeu de données complet entrée/sortie × octets/paquets.

Les trois écrans frères (Connexions de ports, Connexions IP, Trafic) partagent le même TrafficController et le même SessionQueryService, mais seul l’onglet Trafic lit la série temporelle de débit de server_traffic plutôt que l’instantané de sessions (traffic_session_ct). C’est pourquoi il utilise une fenêtre de plage (1h/6h/24h) au lieu du minuteur (1/5/60 min) employé par les deux autres.

Quand l’utiliser

• Pour retracer dans le temps les pics ou montées de bande passante sur un serveur donné (transferts de sauvegarde nocturnes, téléchargements volumineux, afflux DDoS).
• Pour lire le caractère d’un serveur d’après son rapport entrée:sortie (les serveurs web penchent vers le sortant ; les récepteurs de sauvegardes vers l’entrant).
• Comme écran de première approche pour les nœuds dont les paquets/octets sortants s’envolent soudainement, avant d’approfondir dans Sécurité ▸ Menaces ou dans la fenêtre d’investigation d’IP.
• Pour repérer d’un coup d’œil les serveurs obsolètes (collecte en retard) grâce au KPI de fraîcheur.

Disposition

Bandeau (barre supérieure)

Bandeau de KPI (enchaînement : entrée · sortie · paquets · rapport → point chaud → fraîcheur)

Légende des couleurs d’échelle + échelle de l’axe Y

La couleur de la courbe et de l’aire code la magnitude de la valeur (visualMap par paliers d’ECharts). Lorsqu’une valeur franchit un seuil, la couleur change : vous ressentez l’ordre de grandeur par la couleur.

• La direction est codée par la forme du trait : sortant = trait plein + aire plus dense, entrant = trait pointillé + aire claire. Les flèches de l’en-tête (↓ entrant / ↑ sortant) et l’infobulle les distinguent également.
• Bascule d’échelle de l’axe Y : linear (par défaut, minimum épinglé à 0 → aire honnête) | log (comprime le Ko–Mo sur un seul axe afin que l’entrant et le sortant restent tous deux visibles). La sélection est conservée dans localStorage.

Cartes de trafic par serveur

Chaque carte = un serveur. L’en-tête affiche le nom d’hôte ainsi que les octets entrants/sortants courants ; le corps est une courbe <metric-chart> de 200 px (ECharts, import dynamique).

• Réorganisation par glisser : utilisez la poignée (⋮) pour réordonner les cartes ; l’ordre est conservé sous infr:order:traffic-net.
• Disposition en maçonnerie + 12 cartes par page.
• Axe temporel fixe : chaque carte épingle son axe X sur win.since ~ win.until (une fenêtre partagée). Les serveurs en retard de collecte sont rendus honnêtement sous forme de moignon à gauche, ce qui évite une fausse courbe étirée sur toute la largeur à partir d’une poignée de points.

Comment l’utiliser

1. Choisissez une plage — 1h pour traquer les pics, 24h pour les motifs quotidiens.
2. Changez de métrique — bytes pour la charge de bande passante, packets pour le caractère des connexions/PPS.
3. Axe logarithmique — pour les serveurs présentant un fort écart entrée/sortie (nœuds web où le sortant ≫ l’entrant), log conserve les deux courbes visibles.
4. Réordonnez les cartes — faites glisser en tête les serveurs qui vous intéressent (enregistré dans le navigateur).
5. Traquez un point chaud — lorsque vous repérez le serveur Top du KPI ou une courbe crit (rouge), rendez-vous dans Connexions de ports / Connexions IP pour déterminer quelle IP ou quel port en est à l’origine.

L’infobulle affiche un en-tête HH:MM ainsi que la valeur de chaque série (entrant/sortant). Même sur des cartes étroites, les étiquettes de l’axe temporel se masquent automatiquement pour éviter les chevauchements (hideOverlap).

Sources de données

server_traffic (legacy_glory · lecture seule)

La requête source (TrafficRepository::serverTraffic) recourt au liage de paramètres pour ne balayer qu’une fenêtre étroite (aucune valeur en dur, aucune interpolation de chaîne) :

SELECT server_name, server_index, time_window_start, direction,
       delta_packet_count, delta_bytes_count
FROM   server_traffic
WHERE  time_window_start >= :since   -- (dernière fenêtre) − plage
ORDER  BY time_window_start
LIMIT  6000;

Ancre = MAX(time_window_start) (MAX indexé → peu coûteux). since = anchor − range minutes.

Normalisation par tranche d’une minute (correction des dents de scie)

Le collecteur check_tx.js horodate l’entrant et le sortant au moyen d’appels new Date() distincts au sein de sa boucle : au cours d’un même cycle de 5 minutes, les valeurs de time_window_start diffèrent donc de 1 à 2 secondes (par exemple :02 pour l’entrant et :03 pour le sortant). Un regroupement sur l’horodatage exact ne capte qu’une seule des deux directions à chaque instant et laisse l’autre à 0 — d’où un graphique en dents de scie.

Correction : SessionQueryService::reshapeNet arrondit les horodatages dans une tranche d’une minute (round(ts/60)*60), de sorte que l’entrant et le sortant fusionnent en un point unique. L’intervalle de la fenêtre (300 s) étant bien supérieur à la tranche (60 s), des fenêtres adjacentes n’entrent jamais en collision.

Décalage du fuseau horaire d’affichage

Comme l’heure de stockage de la base héritée peut différer de l’heure d’affichage (écart d’environ 9 h constaté), les valeurs sont décalées par OpsPolicy::trafficTzOffsetSec() pour l’affichage uniquement (horodatage, axe temporel, horodatages des séries). Les bornes SQL (min/max) ne sont PAS décalées — la requête utilise l’heure héritée brute.

Cache · interrogation périodique

• Côté serveur, Cache::remember('infr:traffic:net:v1:<range>', 30, …) — cache de 30 secondes.
• Côté client, interrogation automatique toutes les 30 secondes (/infra/traffic/net/live?range=<minutes>).

Accès

• Écran en lecture seule. Aucune écriture, aucun blocage, aucune autre action destructrice.
• Relevant du domaine de rôle Infrastructure, il s’ouvre à partir du user_level 1 minimum (demo=1) ; staff (5) et admin (10) y ont bien entendu accès également.
• La route est protégée par l’intergiciel infr.auth (authentification de session requise).
• Les identifiants de la source proviennent uniquement de config('database.connections.legacy_glory') (c’est-à-dire de .env) — aucun identifiant n’est codé en dur dans le contrôleur ou le service.

Dépannage et FAQ

Q. Je ne vois que « Aucun échantillon de trafic ». Cela signifie que server_traffic ne contient aucune fenêtre récente. Vérifiez que le collecteur check_tx.js fonctionne et que la connexion legacy_glory est valide. Lorsque latestTrafficWindow() (MAX) est nul, les cartes sont vides et les KPI affichent 0.

Q. Un serveur ne dessine qu’un court moignon à gauche. C’est voulu. L’axe temporel étant épinglé à une fenêtre partagée, un serveur en retard de collecte est dessiné honnêtement jusqu’à sa dernière observation, sous forme de moignon à gauche. Il est également compté comme inactif dans le KPI Active servers (son dernier point tombe hors des 15 min précédant la fin de la fenêtre).

Q. La courbe d’une direction ressemble à des dents de scie. La normalisation par tranche d’une minute corrige la plupart des cas, mais si les fenêtres de collecte sont elles-mêmes irrégulières, un reliquat de dents de scie peut subsister. Passer à l’axe log l’adoucit.

Q. Les valeurs sont-elles cumulées ? Non. delta_* = incrément par fenêtre (~5 min). C’est pourquoi le KPI Total packets porte la mention /window. Il ne s’agit pas de compteurs cumulés.

Q. Les heures sont décalées de plusieurs heures. Le fuseau horaire d’affichage est corrigé via le paramètre traffic_tz_offset d’OpsPolicy (voir Politique d’exploitation).

Voir aussi

• Connexions de ports — répartition des états TCP par port et par serveur + principales IP sources
• Connexions IP — IP distantes par serveur × intensité par port + fenêtre d’analyse approfondie d’IP
• Serveurs (série temporelle de charge) — séries temporelles de charge/CPU/mémoire, même motif <metric-chart> d’ECharts
• Santé (santé des nœuds) — anneaux CPU par nœud + pastilles de service
• Politique d’exploitation — réglages globaux tels que traffic_tz_offset et les ports supervisés