MCP de Observabilidade Cloudflare: Prove um Resultado de Registro Zero

Uma resposta vazia do servidor Cloudflare Observability MCP não é prova de que um Trabalhador esteja saudável. É evidência de que uma consulta não devolveu linhas. Antes de transformar isso em um veredicto, comprova que a consulta usou a conta Cloudflare pretendida, Worker, janela de tempo, configuração de log e conjunto de campose que o mesmo escopo pode recuperar uma invocação de controle conhecida. O padrão razoável é rigoroso: chamar um resultado de linha zero filtrado healthy empty somente quando os Registros de Trabalhadores e os registros de invocação estão habilitados, a taxa de amostragem de cabeças é 1 , a janela está dentro da retenção, a descoberta de campo é bem sucedida, a consulta é concluída e uma consulta mais ampla encontra uma invocação conhecida na mesma conta, Worker e janela. Caso falte algum recibo, mantenha o estado desconhecido ou encaminhe a falha de configuração específica. Isto é importante porque a troca remota de MCP pode ser bem sucedida enquanto a camada de evidências é incompleta. O resultado do protocolo responde ou a ferramenta retornar? O operador ainda tem que responder ou esta consulta cobrir os eventos necessários para esta decisão? Uma consulta de MCP bem sucedida pode ainda ser uma falha de evidências O Cloudflare lista um servidor de observabilidade gerenciado para depurar os registros de aplicativos e análises. O Catálogo de servidores Cloudflare MCP atual fornece seu endpoint remoto, diz que novas conexões usam Streamable HTTP, e explica que a autorização é manuseada através do Cloudflare OAuth. A Repositório de MCP de Observabilidade dos Trabalhadores documenta três ferramentas: query worker observability consultas Registros e métricas dos trabalhadores; O observability keys descobre metadados, campos específicos do trabalhador e campos personalizados; O observability values encontra valores disponíveis para um campo selecionado. Estas ferramentas são suficientes para investigar muitos incidentes, mas os seus envelopes de sucesso não provam cobertura. O repositório também diz que cada solicitação recebe uma autorização e conteúdo de conta frescos. Por conseguinte, não se presume que, dado que o pedido anterior utilizou a conta correta, o pedido seguinte necessariamente o fez. Regista uma referência de conta não secreta e referência de Trabalhador com cada recibo de consulta. Existem várias maneiras de obter um resultado vazio de aparência convincente: 1. OAuth completado, mas a conta selecionada não é a conta de produção. 2. O filtro de nome ou ambiente do Trabalhador não resolve nada. 3. O Registo de Trabalhadores está desativado para essa implantação. 4. Os registos de invocações são explícitamente desativados. 5. A amostragem da cabeça omitiu a invocação que esperava encontrar. 6. A janela solicitada é mais antiga do que os dados conservados. 7. O filtro usa um campo ou valor que está ausente do esquema atual. 8. O resultado filtrado é genuinamente vazio. Só o último estado suporta nenhum incidente correspondente, e mesmo assim apenas para o escopo e a janela limitados. A colisão da lista em success descartará as provas exatas necessárias ao operador. Prova o conjunto de dados antes de interpretar o filtro Comece com a coleta, não com a consulta do incidente. O Trabalhadores Registros de documentação atual do Cloudflare diz que um Trabalhador deve ter observabilidade habilitada para escrever em Registros de Trabalhadores. Também documenta uma configuração invocation logs = false separada. Um trabalhador pode, portanto, executar com êxito enquanto a prova de invocação que a sua auditoria espera estiver deliberadamente ausente. A amostragem é outro limite difícil. O head sampling rate varia de 0 a 1 ; no 0.01 , apenas um em cada cem pedidos é registrado. Uma consulta de erro de linha zero sobre os dados recolhidos na amostra pode ser útil para estimar a tendência, mas não pode eliminar deterministicamente uma solicitação conhecida. A mesma documentação observa que o serviço pode aplicar uma amostra de 1% após uma conta exceder o seu limite diário de registro. Registrar a política efetiva de amostragem, não apenas a configuração prevista. A retenção torna uma janela velha desconhecível. O máximo documentado é de três dias em Workers Free e sete dias em Workers Paid. Se uma janela de incidente terminar antes do limite de retenção, classifique a como window expired . Expandir ou reformulação da consulta não pode recuperar dados que não estão mais armazenados. Use esta ordem para cada investigação: 1. Pin scope. Capturar referências opacas e não secretas para a conta autorizada, o trabalhador e o ambiente. Não armazenar um token OAuth, solicitar URL, corpo de registro ou identificador do cliente no recibo de saúde. 2. Check collection. Confirm Workers Logs está habilitado para o ambiente implementado e se os registos de invocação estão habilitados. 3. Record limits of coverage. Capture the effective head sampling rate, retention days, and requested start/end timestamps. 4. Descobrir antes da filtragem. Usar observability keys para confirmar a existência dos campos necessários, em seguida, observability values para confirmar o valor de Trabalhador ou ambiente está presente. Isto impede que um campo errado ou antiquado pareça um resultado limpo. 5. Run uma consulta de controle. Query amplamente o suficiente para encontrar uma invocação conhecida emitida dentro da mesma conta, Trabalhador e janela. Use um marcador de solicitação hash localmente mantido se precisar de correlação; nunca carregue o marcador bruto para um registro de monitoramento. 6. Run o filtro incidente. Só após o controlo aparecer deve ser considerado um filtro de erro de linha zero um candidato para o healthy empty . Um recibo compacto pode preservar a decisão sem preservar o conteúdo do registro: A conta e as referências do Trabalhador são chaves de correlação, não identificadores secretos. O recibo deliberadamente exclui instruções, mensagens de registro, cabeçalhos, URLs de solicitações, argumentos de ferramentas e material OAuth. Route nove estados em vez de dar um resultado verde O artefacto inspeccionável que acompanha este artigo reproduz nove casos sem conteúdo. A sua regra de prioridade é intencionalmente conservadora: Estado Evidências Ação do operador needs auth O servidor remoto não está autorizado Route para o titular da conta; não etiquetar o Trabalhador inacessível scope unresolved Falta a referência de conta ou de trabalhador Resolver a conta exata, a implantação e o ambiente collection disabled Trabalhadores Registros ou registros de invocações estão desligados Decidir se permitir a recolha e a redistribuição window expired A janela é anterior aos dados armazenados Marque o veredicto histórico indisponível query failed Descoberta de esquema, timestamps ou execução de consulta é inválida Repare a consulta antes de interpretar o conteúdo da linha sampled unknown 0 filas com amostragem de cabeça abaixo do 1 Tratar a ausência como não determinista coverage unknown 0 linhas e a invocação de controlo conhecida está faltando Investigar o escopo, o filtro, a ingestão ou o atraso na recolha incident found A consulta filtrada retorna uma ou mais linhas correspondentes Investigar as provas devolvidas healthy empty 0 filas filtradas mais cobertura completa e controlo encontrado Limpar apenas este filtro, escopo e janela de tempo O classificador verifica as condições prévias antes de analisar o filteredRows . Essa ordem impede o falso verde mais comum: ver zero e parar antes de perguntar se havia algum conjunto de dados válido para pesquisar. Execute o dispositivo localmente: Os nove aparelhos produziram uma caixa em cada estado e passaram os três testes: A parte falsificável é simples. Tome o dispositivo saudável e vazio e retire o recibo de controlo: o seu estado torna se coverage unknown . A amostragem inferior de 1 para 0.1 : torna se sampled unknown . Adicionar três linhas filtradas: torna se incident found . A contagem de filas só tem significado após o estabelecimento do caminho da evidência. Uma janela de registro vazia verificada ainda não é um resultado de agente A healthy empty é deliberadamente estreita. Significa que o filtro de registro Cloudflare Workers selecionado não retornou linhas correspondentes em uma janela coberta. Isso não significa que o Trabalhador tenha produzido a resposta correta, que uma redacção posterior tenha sido realizada uma vez, que um trabalho programado tenha entregado o seu artefato ou que a tarefa de agente mais ampla do usuário tenha sido bem sucedida. O Visão geral da observabilidade dos trabalhadores da Cloudflare separa registros, rastreamentos, métricas, análises e telemetria exportada. Cada superfície responde a uma pergunta diferente. Um filtro de erro limpo pode coexistir com um resultado de negócios errado. Um registro de invocação bem sucedido pode coexistir com um registro de destino faltante. Um pedido de controle conhecido pode provar a cobertura da consulta sem dizer nada sobre um consumidor de fila não relacionado. Adicionar um recibo de resultado fora da consulta de registro quando o incidente envolve um efeito visível ao usuário: um hash de arquivo, versão de banco de dados, resposta pública, confirmação de fila ou outra verificação determinista de destino. Se o efeito tiver ocorrido, mas o recibo estiver ausente, não tente novamente automaticamente em um limite de efeitos colaterais. Reconciliem se primeiro. Há também limites de privacidade. Uma sonda de controle deve ser sintética, limitada e fácil de identificar sem colocar segredo em troncos. O recibo de saúde deve conter hashes e estados, não requerer corpos. O Cloudflare documenta que os registros de tamanho excessivo podem ser truncados; uma linha atual não é prova de que todos os campos esperados sobreviveram. Inspeccionar o limite do $cloudflare.truncated quando o diagnóstico depender do conteúdo do registro. O servidor MCP Cloudflare Observability é documentado como um trabalho em andamento, por isso os nomes e o comportamento das ferramentas podem mudar. Re exercer a descoberta de campo, fixar a data da evidência nos relatórios de incidentes e tratar as suposições obsoletas de ferramentas como um fracasso da consulta em vez de um resultado saudável. A Sidewisp está atualmente em prévia privada. Os seus adaptadores de monitorização da produção e sistemas de recuperação não são geralmente enviados. O método aqui é um padrão de operação local, não uma alegação de que o Sidewisp atualmente se conecta a contas do Cloudflare, faz consultas ao vivo aos trabalhadores ou corrige incidentes. A regra útil é menor: nunca promovam as linhas zero para saudable até que um evento conhecido comprova que o conjunto de dados exato, alcance, janela e política de coleta foram capazes de retornar evidências. Isso transforma uma resposta do MCP numa decisão auditável sem fingir que os registos só provam o resultado.