Cloud/AI Governance/Fallos de Solicitudes
Fallos de Solicitudes
El registro de incidentes de tu flota: 342 fallos de 12,480 requests en el sample, cada uno atribuido a Agent, Upstream o Vinkius, con el peor servidor y la peor herramienta nombrados y una columna de salud que audita a la propia Vinkius.
Cuando algo se rompe, la mayoría de los dashboards te dicen que se rompió. Request Failures te dice quién: cada request fallido se atribuye a Agent (quien llamó envió algo inválido), Upstream (el proveedor MCP falló) o Vinkius (el propio proxy), y la pantalla nombra al peor infractor de ambos lados. La línea de la propia consola: "Trace every failure back to its source. See the exact combination of server and tool behind the noise, and whether things are getting better or worse."
Request Failures
Trace every failure back to its source. See the exact combination of server and tool behind the noise, and whether things are getting better or worse.
Failure Timeline
Errors (red) · Agent / Upstream / Vinkius ratesTransport Distribution
Connection protocol breakdownErrors by Server
Stacked by Agent / Upstream / VinkiusError Distribution by MCP Server
| MCP Server | Requests | Errors | Rate | Health |
|---|---|---|---|---|
| Notion | 1,842 | 96 | 5.21% | Moderate |
| GitHub | 1,684 | 78 | 4.63% | Moderate |
| Slack | 1,204 | 54 | 4.49% | Moderate |
| Jira | 986 | 47 | 4.77% | Moderate |
| Linear | 842 | 31 | 3.68% | Moderate |
| Stripe | 691 | 18 | 2.6% | Moderate |
| HubSpot | 578 | 12 | 2.08% | Moderate |
| Vercel | 412 | 6 | 1.46% | Healthy |
El mockup se ejecuta con el Sample Data de la consola: 342 fallos en 12,480 requests, una tasa de fallo del 2.74%. En un plan de pago la misma pantalla audita tu tráfico en vivo, por organización.
Los cuatro contadores
- Total Errors con el volumen de requests detrás, en rojo en cuanto existen.
- Failure Rate en una barra con código de color (los mismos umbrales en todo el producto: cero es verde, por debajo del 5% ámbar, más allá rojo) con la división en tres justo debajo: Agent / Upstream / Vinkius. En el sample, 239 fallos fueron culpa del agente que llamó, 86 del proveedor y 17 de la propia Vinkius.
- Worst Server, el Connector con más errores, nombrado.
- Worst Tool, la herramienta con más errores, en monoespaciado, lista para buscar.
Tres gráficos, una historia
El Failure Timeline traza los errores a lo largo del período, así que "¿está mejorando o empeorando?" es una forma, no un debate. El Transport Distribution divide el tráfico por protocolo de conexión (en el sample: streamable-http, sse y stdio), porque un patrón de fallos que solo aparece en un transporte es un problema de protocolo, no de proveedor. Errors by Server apila los fallos de cada Connector en las mismas tres causas, así la barra más grande llega prediagnosticada.
La tabla que audita al auditor
Error Distribution by MCP Server lista cada Connector con sus requests, errores y tasa coloreada. Después viene la columna que distingue a Vinkius: Health califica al servidor solo por los errores que la propia Vinkius causó. Tus errores 4xx y las caídas 5xx del proveedor no cuentan contra el servidor aquí; si esta columna se vuelve ámbar, significa que el proxy del medio contribuyó con errores, y ese es un problema de Vinkius, no tuyo. Un dashboard que califica a su propio operador es algo raro; esto es como se ve "aquí se detiene la pelota" en forma de columna.
El estado vacío es el de la propia consola: "No error data recorded in this period."
El último informe, y lo que cierra el ciclo
Esta es la pantalla final de Reports: con ella, las ocho juntas cubren la flota desde todos los ángulos: qué pasó (Mission Control), quién preguntó (Agent Activity), qué respondió (Server Traffic y Tool Reliability), qué credenciales (Access Tokens), cuánto costó (AI Spend) y cuán protegido estaba (Security Posture). Cuando esta pantalla muestra un servidor fallando, el grupo Settings es la respuesta: Connector Policy para restringirlo, y DLP Protection, FinOps Guard y Circuit Breaker para mantenerlo seguro, barato y vivo.