MCP наблюдения Cloudflare: Докажите результат с нулевым логином

Пустой ответ сервера MCP Cloudflare Observability не является доказательством того, что работник здоров. Это свидетельство того, что один запрос не ответил ни на ряд. Прежде чем превратить это в вердикт, докажите, что запрос использовал предполагаемую учетную запись Cloudflare, Worker, окно времени, конфигурацию журналов и набор полей и что тот же объем может получить известное вызов управления. Разумный дефолт строгий: называть фильтрованный результат нулевой строки healthy empty только тогда, когда включены журналы рабочих и журналы призывов, скорость выборки голов является 1 , окно находится внутри хранения, обнаружение поля удается, запрос завершается, а более широкий запрос находит известное призвание в той же учетной записи, рабочий и окно. Если отсутствует какой либо квитанция, сохранить состояние неизвестным или маршрутизировать конкретную ошибку конфигурации. Это имеет значение, потому что удаленный обмен MCP может быть успешным, пока слой доказательств не является полным. Результат протокола отвечает Дайла ли инструмент? Оператор все еще должен ответить Дайла ли этот запрос события, необходимые для принятия этого решения? Успешный запрос MCP все равно может быть провалом доказательств Cloudflare перечисляет управляемый сервер Observability для отладки журналов приложений и аналитики. Нынешний Каталог серверов Cloudflare MCP предоставляет свою удаленную конечную точку, говорит, что новые подключения используют Streamable HTTP, и объясняет, что авторизация обрабатывается через Cloudflare OAuth. Репозиторий МПК "Рабочие наблюдения" документирует три инструмента: Запросы query worker observability Запросы рабочие журналы и показатели; observability keys обнаруживает метаданные, поля, специфические для работников, и пользовательские поля; observability values находит доступные значения для выбранного поля. Таких инструментов достаточно для расследования многих инцидентов, но их успешные конверты не доказывают, что они могут быть охвачены. Репозиторий также говорит, что каждый запрос получает свежие, запросованные разрешения и контекст учетной записи. Следовательно, не следует предполагать, что, поскольку предыдущий запрос использовал правильный счет, следующий запрос обязательно использовал правильный счет. Зарегистрируйте ссылку на несекретную учетную запись и ссылку на работника при каждом получении запроса. Существует несколько способов получить убедительный пустой результат: 1. OAuth завершен, но выбранная учетная запись не является учетной записью производства. 2. Фильтр имени работника или окружающей среды не работает. 3. Рабочие журналы отключены для этого развертывания. 4. Журналы вызовов явно отключены. 5. Пробы головы пропустили призыв, который вы ожидали найти. 6. Запрашиваемое окно более старое, чем сохраненные данные. 7. Фильтр использует поле или значение, которое отсутствует в текущей схеме. 8. Фильтрованный результат действительно пустой. Только последнее государство не поддерживает совпадение, и даже тогда только для ограниченного масштаба и окна. Свержение списка на success исключает точные доказательства, необходимые оператору. Доказать набор данных перед интерпретацией фильтра Начинайте с сбора, а не с запроса о происшествии. В текущем Рабочие Журнал документации Cloudflare говорится, что рабочий должен иметь возможность наблюдения, чтобы писать в журналы рабочих. В нем также документируется отдельная установка invocation logs = false . Таким образом, рабочий может успешно работать, пока доказательства взыскания, которые вы ожидаете от аудита, намеренно отсутствуют. Образец это еще одна жесткая граница. head sampling rate варьируется от 0 до 1 ; на 0.01 записывается только один из ста запросов. Запрос ошибки нулевого ряда по выбранным данным может быть полезен для оценки тенденции, но он не может детерминистически очистить одно известное запрос. В той же документации отмечается, что служба может применять 1% ный образец после того, как учетная запись превысит ее ежедневный лимит. Зарегистрируйте эффективную политику отбора образцов, а не только предполагаемую конфигурацию. Задержание делает старый окно неизвестным. Документированный максимальный срок три дня на Workers Free и семь дней на Workers Paid. Если окно инцидента заканчивается до границы хранения, классифицируйте его в window expired . Расширение или переформулирование запроса не может восстановить данные, которые больше не хранятся. Используйте этот приказ для каждого расследования: 1. Pin scope. Захватить непрозрачные, несекретные ссылки на авторизованный счет, работника и окружающую среду. Не храните токен OAuth, не запрашивайте URL адрес, тело журнала или идентификатор клиента в медицинском квитанции. 2. Check collection. Confirm Workers Logs включен для развернутой среды и того, включены ли журналы запросов. 3. Зарегистрируйте пределы охвата. Запишите эффективный показатель выборки головки, дни хранения и запрошенные временные марки начала и окончания. 4. Discover before filtering. Используйте observability keys для подтверждения наличия требуемых полей, затем observability values для подтверждения наличия значения Worker или окружающей среды. Это предотвращает, чтобы неправильно написанное или устаревшее поле выглядело как чистый результат. 5. Run контрольный запрос. Запрос достаточно широкий, чтобы найти один известный запрос, выданный внутри той же учетной записи, Рабочий, и окна. Используйте локальный хэшированный маркер запроса, если вам нужна корреляция; никогда не загружайте сырой маркер в запись мониторинга. 6. Run инцидентный фильтр. Только после появления элемента управления фильтр ошибки с нулевой строкой должен считаться кандидатом на healthy empty . Комплексная квитанция может сохранить решение без сохранения содержания дневника: Счет и ссылки на работников это ключи корреляции, а не секретные идентификаторы. Квитанция сознательно исключает запросы, сообщения о журнале, заголовки, URL адреса запроса, аргументы инструмента и материал OAuth. Маршрут девять штатов вместо того , чтобы дать один зеленый результат Проверяемый артефакт, сопровождающий данную статью, представляет собой девять случаев без содержания. Его правило преимущества намеренно консервативно: Государство Доказательства Действие оператора needs auth Дистанционный сервер не авторизован Путешествие к владельцу счета; не помещайте на маркировку "Рабочий недоступен" scope unresolved Отсутствует ссылка на счет или работника Решить точный учет, развертывание и окружающую среду collection disabled Рабочие Журналы или журналы призывов отключены Решение о том, разрешить ли сбор и перераспределение window expired Окно предшествует сохраненным данным Отметьте исторический вердикт недоступен . query failed Открытие схемы, часовые марки или выполнение запроса недействительны Ремонт запроса перед интерпретацией числа строков sampled unknown нулевые ряды с выборкой голов ниже 1 Оценить отсутствие как недетерминистическое coverage unknown Нулевые строки и известное контрольное вызов отсутствует Исследование объема, фильтрации, приема или задержки сбора incident found Фильтрованный запрос возвращает один или несколько соответствующих рядов Расследовать возвращенные доказательства healthy empty Нулевые фильтрованные ряды плюс полный охват и обнаруженный контроллер Прочистить только этот фильтр, область и окно времени Классификатор проверяет предпосылки, прежде чем рассматривать filteredRows . Этот порядок предотвращает наиболее распространенное ложное зеленое: видение нуля и остановка перед тем, как спросить, есть ли какие либо действительные наборы данных для поиска. Запустить устройство локально: Девять приборов выпустили один корпус в каждом штате и прошли все три испытания: Фальсифицируемая часть проста. Возьмите здоровый пустой приспособление и удалите контрольный квитанция: его состояние становится coverage unknown . Снижение выборки с 1 до 0.1 : она становится sampled unknown . Добавьте три фильтрованных ряда: это становится incident found . Счет рядов имеет значение только после установления пути доказательств. Проверенное пустое окно журналов все еще не является результатом агента healthy empty намеренно узкий. Это означает, что выбранный фильтр журналов Cloudflare Workers не возвращает соответствующих рядов в закрытом окне. Это не означает, что работник произвел правильный ответ, один раз совершил запись вниз по течению, запланированная работа доставила свой артефакт или более широкая задача агента пользователя была успешной. Обзор наблюдаемости работников Cloudflare разделяет журналы, следы, метрики, аналитику и экспортируемую телеметрию. Каждая поверхность отвечает на другой вопрос. Чистый фильтр ошибок может сосуществовать с неправильным бизнес результом. Успешный журнал призыва может сосуществовать с отсутствующим записью о назначении. Известный запрос контроля может доказать охват запроса, не говоря ничего о не связанном потребителе очереди. Добавьте получение результатов за пределами запроса журнала, когда инцидент включает в себя видимый для пользователя эффект: хэш файла, версия базы данных, общественный ответ, подтверждение очереди или другой детерминистический контроль назначения. Если эффект мог возникнуть, но квитанция отсутствует, не пытайтесь автоматически перепробовать на границе побочных эффектов. Сначала примирись. Также есть ограничения на конфиденциальность. Контрольный зонд должен быть синтетическим, ограниченным и легко идентифицируемым, не помещая секрета в журналы. В медицинском квитанции должны быть напечатаны хэши и штаты, а не органы. Cloudflare документирует, что переизбыточные журналы могут быть сокращены; настоящий ряд не является доказательством того, что все ожидаемые поля сохранились. Проверьте границу $cloudflare.truncated , когда диагноз зависит от содержания дневника. Сервер Cloudflare Observability MCP документирован как работа в процессе, поэтому имена инструментов и поведение могут меняться. Возобновить обнаружение поля, записывать дату доказательств в отчетах о происшествиях и рассматривать устаревшие предположения инструмента как неудачу запроса, а не здоровый результат. Sidewisp сейчас находится на этапе закрытого предварительного доступа. Его адаптеры мониторинга производства и системы восстановления обычно не отправляются. Метод здесь это локальный образец работы, а не утверждение о том, что Sidewisp в настоящее время подключается к счетам Cloudflare, запрашивает живых рабочих или исправляет инциденты. Полезное правило меньше: никогда не продвигайте zero rows на healthy до тех пор, пока известное событие не докажет, что точный набор данных, охват, окно и политика сбора были способны возвращать доказательства. Это превращает ответ MCP в проверяемое решение, не делая вид, что только журналы доказывают результат.