Cloud/AI Governance/Tráfego de Conectores
Tráfego de Conectores
O lado dos Connectors do fio: quais MCP servers carregam seu tráfego, quando a demanda pica, para onde vão os milissegundos e qual servidor está prestes a virar problema, ranqueado e com nota de saúde.
Agent Activity mostrou os atores; Server Traffic mostra o palco: todo Connector (MCP server) servindo sua frota, ranqueado por tráfego, com a latência dividida entre o que a API upstream leva e o que a Vinkius adiciona, e uma nota de saúde em cada linha. A promessa do próprio console: "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 |
O mockup roda com o Sample Data do console. Num plano pago a mesma tela mostra os seus Connectors ao vivo, por organização, com o seu tráfego real.
Os quatro contadores
- Active Servers. Quantos Connectors carregaram tráfego no período: o tamanho vivo da sua frota, não o tamanho instalado.
- Total Requests. Tudo o que cruzou o proxy, em todos os Connectors.
- Avg Latency com barra dividida: a fatia verde é o tempo da própria API upstream e a fatia âmbar é o overhead da Vinkius, milissegundos de propósito. É o recibo de que a camada de controle custa quase nada.
- Peak Hour. A janela de tráfego mais alto, calculada do período que você está vendo. Planejamento de capacidade começa aqui.
Dois gráficos: quando a frota trabalha, e quem carrega a carga
Traffic Distribution é um punchcard de requests por dia da semana × hora. Ele mostra quando seus agentes realmente trabalham: os pontos quentes são o seu ritmo de operação. Uma célula acesa numa hora inesperada é uma história que merece ser aberta, porque alguém ou algo rodou quando ninguém esperava.
Request Volume by Server ordena os Connectors por total de chamadas, e a cor da barra é a saúde de latência: verde para servidores rápidos, âmbar para moderados, vermelho para lentos. O servidor mais ocupado e o servidor mais lento são conversas diferentes, e este gráfico mantém as duas separadas.
A tabela de servidores: saúde, não esperança
Cada linha é um Connector, e o console dá nota em vez de achismo:
- MCP Server, com selo High Volume quando um servidor passa de 2.000 chamadas no período, então os pesadões se identificam sozinhos.
- Total Calls por servidor.
- A divisão de latência em três colunas: API (o tempo da própria upstream), Overhead (o que a Vinkius adiciona) e Total, com cor nas mesmas limiares de sempre: verde abaixo de 200ms, âmbar abaixo de 800ms, vermelho depois.
- Req/Day, o ritmo por dia daquele servidor.
- Health como veredito explícito: Healthy abaixo de 200ms, Moderate abaixo de 1s, Slow depois disso, com uma bolinha colorida que você varre na coluna em um segundo.
Clicar numa linha abre o detalhe daquele Connector. O estado vazio é o do próprio console: "No MCP servers recorded in this period."
Os dois lados de cada request
Agent Activity e Server Traffic são o mesmo tráfego visto das duas pontas: o cliente que perguntou e o servidor que respondeu. Quando o Mission Control aponta um padrão de latência ou falha, uma tela diz quem perguntou e esta diz o que respondeu. Os próximos passos naturais são Tool Reliability (ferramenta por ferramenta) e Request Failures (quando as respostas dão errado).