Cloudflare Status API - какой компонент проверять на наличие проблем?

Question

РЕЗЮМЕ: API-интерфейс Cloudflare Status возвращает информацию о сотнях компонентов, которая сообщает мне, если есть реальная проблема?

ДЕТАЛИ (если вы хотите / нуждаетесь в этом): мы предоставляем наш статический контент с assets.mydomainname.co.uk, который указывает на Cloudflare. Когда Cloudflare выходит из строя, мы теряем этот контент и должны вернуться к его обслуживанию с www.mydomainname.co.uk (в данный момент вручную).

После двух недавних отключений Cloudflare я разрабатываю компонент для проверки API Cloudflare Status каждые 5 минут через cron, и если будет обнаружена проблема, которая повлияет на способность CF предоставлять мой контент, то мой сайт переключится на обслуживание контент с моих собственных серверов. Это чертовски больно из-за того, что я проснулся в 4 часа утра и вынужден был переключиться на местную подачу вручную.

API Cloudflare Status является тривиальным для доступа и включает в себя сводный индикатор, который может сказать «нет», «второстепенный», «основной» или «критический». Если есть серьезная или критическая проблема, я переключусь на местную подачу. Если он возвращает «нет», то я знаю, что я хорошо продолжаю служить от CF. Однако, если он незначителен, то это может указывать на то, что (например, на данный момент) есть только проблема с очисткой кэша, которая на самом деле не повлияет на CF, обслуживающий мой статический контент для меня ... ИЛИ это может означать небольшая проблема, которая затрагивает мой сайт, и мне нужно переключиться на локальное обслуживание.

Проблема в том, что API статуса возвращает лот информации о компонентах. Их сотни. Который я проверяю?

(Альтернатива, конечно, просто проверить несколько URL-адресов Cloudflare и посмотреть, возвращают ли они код 2 ** или 3 ** вместо кода 4 ** или 5 **, но это кажется неточным и не элегантным когда есть специальный API для использования).

Answer 1

Компоненты описывают регион, в котором работает Cloudflare (Африка, Азия и т. Д.), Отдельные PoP (точки присутствия / центры обработки данных) в регионе, а также фактические сайты и службы Cloudflare в Cloudflare (биллинг, DNS, панель мониторинга, аналитика и т. д.).

Если вы в основном используете Cloudflare для DNS и кэшируете только статические ресурсы, я полагаю, что вы, возможно, захотите взглянуть на службы, связанные с DNS, а также на точки доступа или регионы, откуда поступает большая часть вашего трафика.

Отключение в глобальном масштабе происходит редко, но если это то, что вы ищете, то вы можете проверить все компоненты.

Техническое обслуживание и инциденты с большей вероятностью происходят в меньших масштабах, воздействуя на конкретные центры обработки данных или службы. Если трафик из Сингапура был перенаправлен в Гонконг, например, из-за обрыва оптоволоконного кабеля или проблемы маршрутизации в Сингапуре, ваши посетители в Сингапуре будут испытывать небольшую задержку, поскольку вместо этого кэш будет обслуживаться из Гонконга. Если ваш сайт не зависит от сети с низкой задержкой (например, глобальная финансовая торговля или высокопроизводительные игры), он не должен оказывать такого огромного влияния на ваш бизнес.

Однако, если вы работаете на этом уровне с низкой задержкой, рассмотрите возможность обновления до корпоративного плана, потому что они действительно отдают приоритет своим корпоративным клиентам, когда ресурсы становятся дефицитными, и без колебаний направляют трафик бесплатного и более низкого уровня плана. в другие центры обработки данных.