MCP de observabilidad de Cloudflare: demuestra un resultado de registro cero

Una respuesta vacía del servidor MCP Cloudflare Observability no es evidencia de que un trabajador esté sano. Es evidencia de que una consulta no devolvió filas. Antes de convertir eso en un veredicto, demuestre que la consulta utilizó la cuenta de Cloudflare prevista, Worker, ventana de tiempo, configuración de registro y conjunto de camposy que el mismo alcance puede recuperar una invocación de control conocida. El defecto razonable es estricto: llamar a un resultado de fila cero filtrado healthy empty sólo cuando los registros de trabajadores y los registros de invocación están habilitados, la tasa de muestreo de cabezas es 1 , la ventana está dentro de la retención, el descubrimiento de campo tiene éxito, la consulta se completa y una consulta más amplia encuentra una invocación conocida en la misma cuenta, trabajador y ventana. Si falta algún recibo, mantenga el estado desconocido o envía el error de configuración específico. Esto es importante porque el intercambio remoto de MCP puede tener éxito mientras la capa de pruebas es incompleta. El resultado del protocolo responde ¿Ha regresado la herramienta? El operador todavía tiene que responder ¿Esta consulta cubre los eventos necesarios para esta decisión? Una consulta exitosa de MCP puede ser un fracaso de la evidencia Cloudflare enumera un servidor de Observabilidad administrado para el depuración de registros de aplicaciones y análisis. El Catálogo de servidores MCP de Cloudflare actual proporciona su punto final remoto, dice que las nuevas conexiones utilizan Streamable HTTP, y explica que la autorización se maneja a través de Cloudflare OAuth. La Repositorio de MCP de observabilidad de los trabajadores documenta tres herramientas: query worker observability consulta Registros y métricas de los trabajadores; observability keys descubre metadatos, campos específicos de los trabajadores y campos personalizados; observability values encuentra los valores disponibles para un campo seleccionado. Esas herramientas son suficientes para investigar muchos incidentes, pero sus sobres de éxito no demuestran cobertura. El repositorio también dice que cada solicitud obtiene una nueva autorización y contexto de cuenta. Por lo tanto, no asuma que, debido a que la solicitud anterior utilizó la cuenta correcta, la siguiente solicitud lo hizo necesariamente. Registra una referencia de cuenta no secreta y una referencia de trabajador con cada recibo de consulta. Hay varias maneras de obtener un resultado vacío que parezca convincente: 1. OAuth completado, pero la cuenta seleccionada no es la cuenta de producción. 2. El filtro del nombre del trabajador o del entorno no resuelve nada. 3. Los registros de trabajadores están desactivados para ese despliegue. 4. Los registros de invocaciones están explícitamente desactivados. 5. La muestra de cabeza omitió la invocación que esperaba encontrar. 6. La ventana solicitada es más antigua que los datos retenidos. 7. El filtro utiliza un campo o valor que está ausente del esquema actual. 8. El resultado filtrado es genuinamente vacío. Sólo el último estado admite no coincide incidente, e incluso entonces sólo para el alcance limitado y ventana. El desmantelamiento de la lista en success elimina la evidencia exacta que un operador necesita. Prueba el conjunto de datos antes de interpretar el filtro Comience con la recopilación, no con la consulta del incidente. El Trabajadores Registros de documentación actual de Cloudflare dice que un trabajador debe tener observabilidad habilitada para escribir en los registros de trabajadores. También documenta una configuración separada de invocation logs = false . Por lo tanto, un trabajador puede ejecutar con éxito mientras la evidencia de invocación que espera su auditoría esté deliberadamente ausente. El muestreo es otro límite difícil. head sampling rate oscila desde 0 hasta 1 ; en 0.01 , solo se registra una de cada cien solicitudes. Una consulta de error de fila cero sobre los datos recogidos en la muestra puede ser útil para la estimación de la tendencia, pero no puede eliminar deterministicamente una solicitud conocida. La misma documentación señala que el servicio puede aplicar una muestra del 1% después de que una cuenta exceda su límite diario de registro. Registrar la política efectiva de muestreo, no sólo la configuración prevista. La retención hace que una vieja ventana sea desconocida. El máximo documentado es de tres días en Workers Free y siete días en Workers Paid. Si una ventana de incidencia terminó antes del límite de retención, clasificarla en window expired . La expansión o reformulación de la consulta no puede recuperar datos que ya no se almacenan. Utilice esta orden para cada investigación: 1. Pin scope. Captura referencias opacas y no secretas para la cuenta autorizada, el trabajador y el entorno. No almacene un token OAuth, solicite la URL, el cuerpo del registro o el identificador del cliente en el recibo de salud. 2. Control collection. Confirm Workers Logs está habilitado para el entorno implementado y si están habilitados los registros de invocaciones. 3. Record límites de cobertura. Recopilar la tasa efectiva de muestreo de cabeza, los días de retención y los sellos de tiempo de inicio/finales solicitados. 4. Descubre antes de filtrar. Utilice observability keys para confirmar la existencia de los campos requeridos, luego observability values para confirmar la presencia del valor de trabajador o ambiente. Esto evita que un campo erróneo o anticuado parezca un resultado limpio. 5. Run una consulta de control. Cuestión lo suficientemente amplia como para encontrar una invocación conocida emitida dentro de la misma cuenta, trabajador y ventana. Utilice un marcador de solicitud hashado localmente guardado si necesita correlación; nunca cargue el marcador crudo a un registro de monitoreo. 6. Run el filtro incidente. Sólo después de que aparezca el control se debe considerar un filtro de error de fila cero candidato para healthy empty . Un recibo compacto puede preservar la decisión sin conservar el contenido del registro: Las referencias de la cuenta y del trabajador son claves de correlación, no identificadores secretos. El recibo excluye deliberadamente las instrucciones, los mensajes de registro, los encabezados, las direcciones URL de la solicitud, los argumentos de la herramienta y el material OAuth. La ruta nueve estados en lugar de dar un resultado verde El artefacto inspectable que acompaña a este artículo reproduce nueve casos libres de contenido. Su regla de prioridad es intencionalmente conservadora: El Estado Pruebas Acción del operador needs auth El servidor remoto no está autorizado Ruta al titular de la cuenta; no etiquete al trabajador inaccesible scope unresolved Cuenta o referencia del trabajador falta Resolver la cuenta exacta, el despliegue y el entorno collection disabled Trabajadores Los registros o registros de invocaciones están apagados Decidir si se permite la recogida y la redistribución window expired La ventana es anterior a los datos retenidos Marque el veredicto histórico no disponible query failed Descubrimiento de esquemas, timestamps o ejecución de consultas no es válida Repara la consulta antes de interpretar el recuento de filas sampled unknown Las filas cero con muestreo de cabeza por debajo de 1 Tratar la ausencia como no determinista coverage unknown Cero filas y la llamada de control conocida falta Investigar el alcance, el filtro, la ingestión o el retraso en la recogida incident found La consulta filtrada devuelve una o más filas correspondientes Investigar las pruebas devueltas healthy empty Cero filas filtradas más cobertura completa y un control encontrado Sólo limpie este filtro, alcance y ventana de tiempo El clasificador comprueba las condiciones previas antes de analizar filteredRows . Ese orden evita el falso verde más común: ver cero y detenerse antes de preguntar si había algún conjunto de datos válido para buscar. Ejecutar el dispositivo localmente: Los nueve aparatos produjeron una caja en cada estado y pasaron las tres pruebas: La parte falsificable es simple. Tome el dispositivo sano vacío y retire el recibo de control: su estado se convierte en coverage unknown . La reducción de la muestreo de 1 a 0.1 : se convierte en sampled unknown . Añadir tres filas filtradas: se convierte en incident found . El recuento de filas tiene significado sólo después de que se establezca la ruta de la evidencia. Una ventana de registro vacía verificada todavía no es un resultado de agente healthy empty es deliberadamente estrecho. Significa que el filtro de registro de Cloudflare Workers seleccionado no devolvió filas coincidentes en una ventana cubierta. Esto no significa que el trabajador haya producido la respuesta correcta, que haya escrito una vez, que un trabajo programado haya entregado su artefacto o que la tarea de agente más amplia del usuario haya tenido éxito. El Visión general de la observabilidad de los trabajadores de Cloudflare separa registros, rastros, métricas, análisis y telemetría exportada. Cada superficie responde a una pregunta diferente. Un filtro de error limpio puede coexistir con un resultado de negocio equivocado. Un registro de invocación exitoso puede coexistir con un registro de destino faltante. Una solicitud de control conocida puede probar la cobertura de la consulta sin decir nada sobre un consumidor de cola no relacionado. Añadir un recibo de resultado fuera de la consulta de registro cuando el incidente involucra un efecto visible para el usuario: un hash de archivo, versión de base de datos, respuesta pública, confirmación de cola u otra verificación determinista de destino. Si el efecto pudo haber ocurrido pero el recibo no está presente, no vuelva a intentarlo automáticamente en un límite de efectos secundarios. Conciliar primero. También hay límites a la privacidad. Una sonda de control debe ser sintética, limitada y fácil de identificar sin poner un secreto en los troncos. El recibo de salud debe conservar hashes y estados, no solicitar cuerpos. Cloudflare documenta que los registros de gran tamaño pueden ser truncados; una fila presente no es prueba de que todos los campos esperados sobrevivieron. Inspeccione el límite de $cloudflare.truncated cuando el diagnóstico dependa del contenido del registro. El servidor MCP Cloudflare Observability está documentado como un trabajo en curso, por lo que los nombres de las herramientas y el comportamiento pueden cambiar. Re ejecutar el descubrimiento de campo, fijar la fecha de la evidencia en los informes de incidentes, y tratar las suposiciones obsoletas de la herramienta como un fracaso de la consulta en lugar de un resultado saludable. Sidewisp se encuentra actualmente en versión preliminar privada. Por lo general, no se envían sus adaptadores de monitoreo de producción y sus sistemas de recuperación. El método aquí es un patrón operativo local, no una afirmación de que Sidewisp actualmente se conecta a cuentas de Cloudflare, consulta en vivo a los trabajadores o corrige incidentes. La regla útil es más pequeña: nunca promueva las filas cero a sanas hasta que un evento conocido demuestre que el conjunto de datos exacto, el alcance, la ventana y la política de recopilación eran capaces de devolver evidencia. Eso convierte una respuesta de MCP en una decisión auditable sin pretender que los registros por sí solos prueban el resultado.