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.