Cloud/AI Governance/Trafic des Connecteurs
Trafic des Connecteurs
Le côté Connectors du fil : quels MCP servers transportent votre trafic, quand la demande atteint son pic, où vont les millisecondes et quel serveur est sur le point de devenir un problème, avec classement et score de santé.
Agent Activity a montré les acteurs ; Server Traffic montre la scène : chaque Connector (MCP server) qui sert votre flotte, classé par trafic, avec sa latence répartie entre le temps pris par l'API upstream et ce qu'ajoute Vinkius, et un score de santé sur chaque ligne. La promesse de la console elle-même : "Spot the server that is about to become a problem before your users do. Fleet health, latency trends, and traffic hotspots in one read."
Server Traffic
Spot the server that is about to become a problem before your users do. Fleet health, latency trends, and traffic hotspots in one read.
Traffic Distribution
Requests by day of week × hourRequest Volume by Server
Total calls · color = latency health| MCP Server | Total Calls | API | Health |
|---|---|---|---|
| GitHubHigh Volume | 4,187 | 61ms | Healthy |
| SlackHigh Volume | 2,934 | 78ms | Healthy |
| NotionHigh Volume | 2,178 | 92ms | Healthy |
| Jira | 1,842 | 171ms | Moderate |
| Stripe | 1,264 | 55ms | Healthy |
| Linear | 986 | 71ms | Healthy |
| HubSpot | 743 | 198ms | Moderate |
| Vercel | 512 | 48ms | Healthy |
| Supabase | 387 | 122ms | Healthy |
| Asana | 214 | 702ms | Slow |
Le mockup s'exécute sur le Sample Data de la console. Sur un plan payant, le même écran affiche vos Connectors en direct, par organisation, avec votre trafic réel.
Les quatre compteurs
- Active Servers. Combien de Connectors ont transporté du trafic sur la période : la taille réelle de votre flotte, pas la taille installée.
- Total Requests. Tout ce qui a traversé le proxy, sur tous les Connectors.
- Avg Latency avec une barre fractionnée : la part émeraude est le temps de l'API upstream elle-même et la part ambre est le overhead de Vinkius, des millisecondes par conception. C'est la preuve que la couche de contrôle ne coûte presque rien.
- Peak Hour. La fenêtre au trafic le plus élevé, calculée à partir de la période que vous consultez. La planification de capacité commence ici.
Deux graphiques : quand la flotte travaille, et qui porte la charge
Traffic Distribution est une punchcard des requests par jour de la semaine × heure. Elle montre quand vos agents travaillent réellement : les points chauds sont votre rythme d'exploitation. Une cellule lumineuse à une heure inattendue est une histoire qui mérite d'être ouverte, car quelqu'un ou quelque chose s'est exécuté quand personne ne s'y attendait.
Request Volume by Server classe les Connectors par total d'appels, et la couleur de la barre est la santé de latence : vert pour les serveurs rapides, ambre pour modéré, rouge pour lent. Le serveur le plus sollicité et le serveur le plus lent sont deux conversations différentes, et ce graphique les sépare.
Le tableau des serveurs : la santé, pas l'espoir
Chaque ligne est un Connector, et la console le note au lieu de deviner :
- MCP Server, avec un badge High Volume dès qu'un serveur dépasse 2,000 appels sur la période, pour que les plus gourmands se signalent d'eux-mêmes.
- Total Calls par serveur.
- La latence répartie en trois colonnes : API (le temps de l'upstream lui-même), Overhead (ce que Vinkius ajoute) et Total, avec le même code couleur partout : vert sous 200ms, ambre sous 800ms, rouge au-delà.
- Req/Day, le rythme quotidien de ce serveur.
- Health comme verdict explicite : Healthy sous 200ms, Moderate sous 1s, Slow au-delà, avec un point coloré que vous balayez du regard en une seconde.
Cliquer sur une ligne ouvre le détail de ce Connector. L'état vide est celui de la console elle-même : "No MCP servers recorded in this period."
Les deux faces de chaque request
Agent Activity et Server Traffic sont le même trafic vu des deux bouts : le client qui a demandé et le serveur qui a répondu. Quand Mission Control signale un schéma de latence ou d'échec, un écran vous dit qui a demandé et celui-ci vous dit ce qui a répondu. Les étapes suivantes naturelles sont Tool Reliability (outil par outil) et Request Failures (quand les réponses tournent mal).