Для проверки Yandex Cloud CDN или любого другого CDN не выбирайте URL «на глаз». Сначала сформулируйте вопрос. Статический файл отвечает, может ли CDN отдать конкретный кэшируемый объект. Health endpoint отвечает, проходит ли запрос через CDN к приложению и возвращает ли оно ожидаемый результат. Для рабочей диагностики обычно нужны оба URL, а не компромиссный единственный.
Если разрешена только одна проверка, выбирайте URL по критичному пользовательскому сценарию. Для сайта, где основная ценность — раздача изображений, сборок или документов, разумнее статический объект. Для API или динамического сервиса — отдельный лёгкий endpoint через тот же CDN-домен.
Почему главная страница — плохой URL по умолчанию
/ кажется очевидным выбором, но часто смешивает слишком много причин ошибки: редиректы, персонализацию, cookies, SSR, базу данных, сторонние виджеты, WAF и A/B-тесты. При сбое вы узнаете, что «что-то не так», но не поймёте, CDN ли это.
Хороший контрольный URL имеет явный контракт:
- постоянный публичный адрес;
- ожидаемый HTTP-код;
- предсказуемый тип и небольшой размер ответа;
- стабильную контрольную строку или хеш;
- понятную политику кэширования;
- отсутствие авторизации, персональных данных и дорогих вычислений;
- путь через тот же hostname, DNS, TLS и CDN, который используют посетители.
Провайдер здесь вторичен. У Yandex Cloud CDN, Cloudflare, CloudFront, Fastly или другого сервиса меняются названия заголовков и панелей, но вопрос выбора ресурса остаётся тем же.
Вариант 1: статический файл
Создайте небольшой объект вроде:
https://cdn.example.ru/monitoring/cdn-probe-v1.txtСодержимое может быть таким:
cdn-probe:v1Объект должен быть реальным производственным ресурсом CDN, а не файлом на отдельном техническом домене. Установите понятный Content-Type, разрешите кэширование и не меняйте содержимое по тому же URL без необходимости. Если версия меняется, лучше выпустить cdn-probe-v2.txt, чем незаметно заменить контракт.
Что доказывает успешная проверка
- DNS имени разрешается из точки мониторинга;
- TLS-соединение с CDN-доменом устанавливается;
- edge принимает запрос;
- CDN способен вернуть нужный объект с ожидаемым телом.
Это сильный тест пути раздачи статики. Но он не доказывает, что origin сейчас здоров. По модели HTTP-кэширования свежий сохранённый ответ может повторно использоваться без обращения к источнику. Именно ради этого кэш и существует.
Что проверять
Проверяйте методом GET, а не полагайтесь только на HEAD: вам нужно сравнить тело. Минимальный контракт:
status = 200
content-type = text/plain
body contains = cdn-probe:v1
max response time = ваш эксплуатационный порогЗаголовки кэша (Age и vendor-specific признаки hit/miss) полезны как диагностика, но не делайте универсальное правило по одному названию: оно зависит от CDN и конфигурации. Age показывает оценённое время с момента генерации или валидации ответа в кэше, но его отсутствие само по себе не доказывает обход CDN.
Вариант 2: health endpoint
Для динамического пути используйте, например:
https://www.example.ru/health/publicОтвет:
{"status":"ok","contract":"v1"}Endpoint должен проходить через пользовательский CDN-hostname, но обычно не должен кэшироваться как обычная статика. Его задача — подтвердить, что edge может обратиться к приложению и получить корректный минимальный ответ.
Что включать в health
Публичный endpoint безопаснее делать «неглубоким»: процесс приложения готов обслуживать запрос и критичная конфигурация загружена. Проверка каждой таблицы, очереди и стороннего API при каждом запросе создаёт ложные тревоги и сама становится нагрузкой. Глубокие зависимости лучше контролировать отдельными внутренними проверками.
Не возвращайте в публичном теле:
- версии серверов и библиотек;
- имена узлов и внутренние адреса;
- строки подключения;
- тексты исключений;
- состояние пользовательских данных;
- токены и служебные идентификаторы.
Ограничение health endpoint
Если endpoint закэшировался вопреки замыслу, мониторинг может видеть старое ok, пока origin уже недоступен. Поэтому проверьте фактические заголовки ответа и правила CDN. Не добавляйте случайный query-параметр к каждому запросу как универсальное лечение: он может породить множество cache keys и искусственно увеличить обращения к источнику.
Как выбрать: таблица решения
| Задача | Лучший URL | Что останется неизвестным | |---|---|---| | Проверить раздачу CSS, JS, изображений, файлов | Небольшой статический объект | Текущее состояние origin | | Проверить путь CDN → приложение | Некэшируемый public health | Исправность всех бизнес-функций | | Проверить конкретную пользовательскую функцию | Лёгкий синтетический запрос к этой функции | Общая доступность других функций | | Быстро отличить edge от origin | Два URL: static + health | Причина внутри приложения без дополнительных метрик | | Проверить только origin | Внутренняя прямая проверка | Публичные DNS, TLS и edge CDN |
Практический минимум для большинства систем — пара cdn-probe-v1.txt и /health/public. Результаты образуют простую матрицу:
- static OK, health OK — контрольные пути работают;
- static OK, health FAIL — edge отдаёт кэш, но динамический путь или origin требует проверки;
- static FAIL, health OK — проблема может быть в объекте, кэш-правиле или отдельном hostname;
- оба FAIL — исследуйте DNS, TLS, CDN, маршрутизацию и масштабный сбой; совпадение ещё не указывает единственную причину.
Настройка URL по шагам
Шаг 1. Выберите пользовательский hostname
Проверяйте адрес, который реально указан в HTML, API-клиенте или ссылках на файлы. Проверка сервисного origin-имени провайдера обходит ваш DNS, сертификат и часть конфигурации.
Шаг 2. Зафиксируйте смысл проверки
Запишите одним предложением: «этот URL подтверждает выдачу кэшированного статического объекта» или «этот URL подтверждает соединение CDN с приложением». Если предложение содержит пять разных целей, разделите проверку.
Шаг 3. Задайте проверяемый ответ
Не ограничивайтесь 200. Сверяйте Content-Type и короткое содержимое. Иначе страница ошибки, HTML challenge или заглушка могут пройти как успех.
Шаг 4. Проверьте кэширование экспериментально
Сделайте несколько GET с интервалом, сохраните заголовки и тело. Сверьте поведение с настроенными TTL и правилами провайдера. Для статического объекта ожидайте повторное использование кэша; для health endpoint — подтверждённое отсутствие нежелательного сохранения.
Шаг 5. Не смешивайте регион и ресурс
CDN распределён, поэтому одна точка не показывает картину для всех посетителей. Начните минимум с двух географически или сетево независимых точек, если аудитория распределена. Алерт должен хранить точку, время, URL, код и причину несоответствия.
Шаг 6. Определите правила тревоги
Один краткий тайм-аут может быть сетевым шумом. Используйте подтверждающий запрос и, при необходимости, кворум из нескольких точек. Но не задерживайте критичный сигнал длинной серией повторов. Порог зависит от допустимого времени обнаружения и цены ложного алерта.
Типичные ошибки
Файл существует только ради проверки, но не идёт через CDN. Тогда вы тестируете origin или другой прокси.
URL содержит изменяемое имя без контроля версии. Старый объект на edge и новый на origin дают неоднозначные результаты.
Проверяется случайный большой файл. Это расходует трафик, медленнее отвечает и хуже подходит для частых запросов.
Ожидается только код ответа. 200 с HTML-заглушкой не подтверждает нужный ресурс.
Health зависит от всех интеграций. Необязательный внешний сервис превращается в ложное «сайт недоступен».
Cache busting включён постоянно. Такая проверка измеряет принудительный поход к origin, а не обычную доставку из CDN.
Граница результата
Ни static probe, ни health endpoint не заменяют проверку реальной страницы или API-операции. Они нужны для локализации: быстро понять, на каком участке искать проблему. После сигнала проверяйте пользовательский сценарий, DNS/TLS, заголовки CDN и состояние origin.
Создайте два коротких URL с разными контрактами и добавьте их как отдельные проверки в Web‑Puls. Названия проверок сразу сформулируйте по смыслу — «CDN: статический объект» и «CDN: путь до приложения». Тогда алерт подскажет первый диагностический шаг, а не просто сообщит, что неизвестный URL не ответил.