MCP d'observabilité Cloudflare: Prouver un résultat zéro log

Une réponse vide du serveur MCP Cloudflare Observability n'est pas une preuve qu'un travailleur est en bonne santé. C'est la preuve qu'une requête n'a pas répondu à des lignes. Avant de transformer cela en un verdict, prouvez que la requête a utilisé le compte Cloudflare prévu, Worker, fenêtre de temps, configuration de journaux et ensemble de champset que le même champ peut récupérer une invocation de contrôle connue. Le défaut raisonnable est strict: appeler un résultat de rangée zéro filtré healthy empty uniquement lorsque les journaux de travail et les journaux d'invocation sont activés, le taux d'échantillonnage de tête est 1 , la fenêtre est à l'intérieur de la rétention, la découverte de champ réussit, la requête est complète, et une requête plus large trouve une invocation connue dans le même compte, Worker, et fenêtre. Si un reçu est manquant, conservez l'état inconnu ou enroulez la défaillance de configuration spécifique. Cela importe parce que l'échange à distance de MCP peut réussir alors que la couche de preuve est incomplète. Le résultat du protocole répond a t il rendu l'outil? L'opérateur doit toujours répondre a t il couvert cette requête les événements nécessaires à cette décision? Une requête MCP réussie peut toujours être un échec des preuves Cloudflare répertorie un serveur d'observabilité géré pour débogage des journaux et des analyses d'applications. Le Catalogue du serveur MCP Cloudflare actuel fournit son extrémité distante, dit que les nouvelles connexions utilisent Streamable HTTP, et explique que l'autorisation est gérée par Cloudflare OAuth. Le Référentiel des PCM sur l'observabilité des travailleurs documente trois outils: query worker observability effectue des requêtes sur les journaux et les indicateurs des travailleurs; observability keys détecte les métadonnées, les champs spécifiques au travailleur et les champs personnalisés; observability values trouve les valeurs disponibles pour un champ sélectionné. Ces outils sont suffisants pour enquêter sur de nombreux incidents, mais leur succès ne prouve pas leur couverture. Le référentiel indique également que chaque demande reçoit une nouvelle autorisation et un contexte de compte. Par conséquent, ne présumez pas que, comme la demande précédente a utilisé le bon compte, la demande suivante l'a nécessairement fait. Enregistrez une référence non secrète au compte et une référence au travailleur avec chaque reçu de requête. Il existe plusieurs façons d'obtenir un résultat vide qui semble convaincant: 1. OAuth complété, mais le compte sélectionné n'est pas le compte de production. 2. Le filtre du nom ou de l'environnement du travailleur ne résulte en rien. 3. Les journaux des travailleurs sont désactivés pour ce déploiement. 4. Les journaux d'invocation sont explicitement désactivés. 5. L'échantillonnage de la tête a omis l'invocation que vous attendez de trouver. 6. La fenêtre demandée est plus ancienne que les données conservées. 7. Le filtre utilise un champ ou une valeur qui est absent du schéma actuel. 8. Le résultat filtré est vraiment vide. Seul le dernier État ne prend en charge aucun incident correspondant, et même alors seulement pour la portée et la fenêtre limitées. L'effondrement de la liste en success rejette les preuves exactes dont un opérateur a besoin. Prouver l' ensemble de données avant d' interpréter le filtre Commencez par la collecte, pas par la requête d'incident. Le Travailleurs Logs de documentation actuel de Cloudflare indique qu'un travailleur doit avoir l'observabilité permettant d'écrire dans les journaux des travailleurs. Il documente également un réglage séparé de invocation logs = false . Un travailleur peut donc courir avec succès alors que la preuve d'invocation dont vous vous attendez à l'audit est délibérément absente. Le prélèvement d'échantillons est une autre limite difficile. head sampling rate va de 0 à 1 ; à 0.01 , seule une demande sur cent est enregistrée. Une requête d'erreur de ligne zéro sur les données échantillonnées peut être utile pour l'estimation de la tendance, mais elle ne peut pas éliminer déterministiquement une demande connue. La même documentation indique que le service peut appliquer un échantillon de 1% après qu'un compte dépasse sa limite journalière. Enregistrer la politique effective d'échantillonnage, pas seulement la configuration prévue. La rétention rend une vieille fenêtre inconnue. Le maximum documenté est de trois jours sur Workers Free et de sept jours sur Workers Paid. Si une fenêtre d'incident s'est terminée avant la limite de rétention, elle doit être classée window expired . L'expansion ou la réécriture de la requête ne peut pas récupérer les données qui ne sont plus stockées. Utilisez cette ordonnance pour chaque enquête: 1. P dans la portée. Capture des références opaques et non secrètes pour le compte autorisé, le travailleur et l'environnement. Ne conservez pas un jeton OAuth, ne demandez pas l'URL, le corps du journal ou l'identifiant du client dans le reçu de santé. 2. Collection. Confirm Workers Logs est activé pour l'environnement déployé et si les journaux d'invocation sont activés. 3. Recordez les limites de couverture. Capturez le taux effectif d'échantillonnage des têtes, les jours de rétention et les timestamps de démarrage et de fin demandés. 4. Discover avant filtration. Utilisez observability keys pour confirmer l'existence des champs requis, puis observability values pour confirmer la présence de la valeur Worker ou de l'environnement. Cela empêche un champ mal orthographié ou obsolète d'avoir l'air d'un résultat propre. 5. Run une requête de contrôle. Requête assez large pour trouver une invocation connue émise à l'intérieur du même compte, Worker et fenêtre. Utilisez un marqueur de requête haché détenu localement si vous avez besoin d'une corrélation; ne téléchargez jamais le marqueur brut sur un enregistrement de surveillance. 6. Run le filtre d'incident. Ce n'est qu'après l'apparition de la commande qu'un filtre d'erreur à rang nul devrait être considéré comme candidat à healthy empty . Un reçu compact peut préserver la décision sans préserver le contenu du journal: Les références du compte et du travailleur sont des clés de corrélation, pas des identifiants secrets. Le reçu exclut délibérément les invites, les messages de journaux, les en têtes, les adresses URL des demandes, les arguments des outils et le matériel OAuth. Route neuf états au lieu de rendre un résultat vert Le matériel inspectable qui accompagne cet article renvoie neuf cas sans contenu. Sa règle de priorité est intentionnellement conservatrice: État Les preuves Action de l'opérateur needs auth Le serveur distant n' est pas autorisé Route vers le propriétaire du compte; ne pas étiqueter le travailleur inaccessible scope unresolved Compte ou référence au travailleur manque Résolvez le compte exact, le déploiement et l'environnement collection disabled Les journaux ou les journaux d' invocation sont désactivés Décider de permettre la collecte et le redéploiement window expired La fenêtre précède les données conservées Marquez le verdict historique non disponible query failed Découverte de schéma, timestamps ou exécution de requête est invalidée Réparer la requête avant d'interpréter le nombre de lignes sampled unknown Zéro rangées avec échantillonnage de tête inférieur à 1 Traiter l'absence comme non déterministe coverage unknown Zéro rangées et l'invocation de contrôle connue est manquante Enquêter sur la portée, le filtre, l'ingestion ou le retard de collecte incident found La requête filtrée renvoie une ou plusieurs lignes correspondantes Enquêter sur les preuves retournées healthy empty Zéro rangées filtrées plus une couverture complète et un contrôle trouvé Nettoyez uniquement ce filtre, la portée et la fenêtre de temps Le classificateur vérifie les conditions préalables avant d'examiner le filteredRows . Cet ordre empêche le faux vert le plus courant: voir zéro et s'arrêter avant de demander s'il y avait un ensemble de données valide à rechercher. Exécutez le dispositif localement: Les neuf appareils ont produit un cas dans chaque état et les trois essais ont été passés: La partie falsifiable est simple. Prenez l'appareil sain et vide et retirez le reçu de contrôle: son état devient coverage unknown . Réduction de l'échantillonnage de 1 à 0.1 : il devient sampled unknown . Ajouter trois lignes filtrées: il devient incident found . Le nombre de lignes n'a de signification qu'après l'établissement du chemin des preuves. Une fenêtre de journal vide vérifiée n' est toujours pas un résultat d' agent Le healthy empty est délibérément étroit. Cela signifie que le filtre de journaux Cloudflare Workers sélectionné n'a pas renvoyé de lignes correspondantes dans une fenêtre couverte. Cela ne signifie pas que le travailleur a produit la réponse correcte, qu'une écriture en aval a été effectuée une fois, qu'un travail prévu a livré son artefact ou que la tâche d'agent plus large de l'utilisateur a réussi. Le Vue d'ensemble de l'observabilité des travailleurs de Cloudflare sépare les journaux, les traces, les mesures, l'analyse et la télémétrie exportée. Chaque surface répond à une question différente. Un filtre d'erreur propre peut coexister avec un mauvais résultat commercial. Un journal d'invocation réussi peut coexister avec un enregistrement de destination manquant. Une demande de contrôle connue peut prouver la couverture des requêtes tout en ne disant rien sur un consommateur de file d'attente non lié. Ajouter un reçu de résultat en dehors de la requête de journal lorsque l'incident implique un effet visible à l'utilisateur: un hash de fichier, une version de base de données, une réponse publique, une confirmation de file d'attente ou un autre contrôle déterministe de destination. Si l'effet a pu se produire mais que le reçu n'est pas disponible, ne réessayez pas automatiquement à la limite des effets secondaires. Réconcilier d'abord. Il y a aussi des limites à la vie privée. Une sonde de contrôle doit être synthétique, limitée et facile à identifier sans mettre un secret dans les journaux. Le reçu de santé doit contenir des hashes et des états, et non des corps. Les documents Cloudflare indiquent que les journaux de grande taille peuvent être tronqués; une ligne actuelle n'est pas la preuve que tous les champs attendus ont survécu. Inspectez la limite de $cloudflare.truncated lorsque le diagnostic dépend du contenu du journal. Le serveur MCP Cloudflare Observability est documenté comme un travail en cours, de sorte que les noms des outils et le comportement peuvent changer. Réinitialiser la découverte de champ, saisir la date de la preuve dans les rapports d'incidents, et traiter les hypothèses d'outils obsolètes comme un échec de requête plutôt qu'un résultat sain. Sidewisp est actuellement en préversion privée. Ses adaptateurs de surveillance de la production et ses systèmes de récupération ne sont généralement pas expédiés. La méthode ici est un modèle d'exploitation local, pas une affirmation selon laquelle Sidewisp se connecte actuellement à des comptes Cloudflare, interroge les travailleurs en direct ou résout des incidents. La règle utile est plus petite: ne jamais promouvoir zero rows à healthy jusqu'à ce qu'un événement connu prouve que l'ensemble de données exact, la portée, la fenêtre et la politique de collecte étaient capables de renvoyer des preuves. Cela transforme une réponse du PCM en une décision vérifiable sans prétendre que les journaux seuls prouvent le résultat.