Бесплатная диагностика работоспособности и задержки веб-сайта

Понимание синтетического аудита работоспособности и диагностики производительности

Синтетический мониторинг работоспособности включает в себя выполнение автоматических запланированных запросов протокола HTTP/HTTPS от удаленных тестовых серверов для проверки того, что целевые веб-приложения, API и сетевая инфраструктура остаются работоспособными, доступными и отзывчивыми.

В то время как традиционные инструменты мониторинга полагаются на внутренние показатели агента сервера (например, использование ЦП или дисковый ввод-вывод), синтетические внешние проверки оценивают доступность с точки зрения конечного пользователя в общедоступном Интернете.Эта перспектива с несколькими регионами обнаруживает аномалии сетевой маршрутизации, сбои распространения DNS, ошибки пограничного кэширования CDN и тайм-ауты облачного шлюза, которые не учитываются внутренними метриками агента.

Ключевые компоненты сетевой задержки в разобранном виде

Одна веб-проверка HTTP измеряет несколько последовательных фаз сетевого протокола.Понимание этих компонентов помогает командам разработчиков точно определить узкое место при снижении производительности:

• Продолжительность поиска DNS: время, необходимое пробному серверу для запроса преобразователей системы доменных имен (DNS) и преобразования доменного имени в IP-адрес.Высокая задержка DNS указывает на узкие места поставщика DNS или некэшированные настройки TTL.
• TCP-соединение: продолжительность первоначального трехстороннего TCP-квитирования (SYN, SYN-ACK, ACK), устанавливающего сетевой сокет между узлом-зондом и целевым исходным сервером.
• Время согласования TLS: для зашифрованных соединений HTTPS — время, необходимое для выполнения криптографического подтверждения TLS, обмена сертификатами безопасности и установки набора безопасных шифров.
• Время до первого байта (TTFB): время, прошедшее с момента отправки HTTP-запроса GET до получения зондом самого первого байта данных ответа от сервера.Высокий TTFB указывает на медленную обработку внутренних приложений или неиндексированные запросы к базе данных.

Почему межрегиональный консенсус исключает ложноположительные оповещения

Ложноположительные оповещения о сбоях являются основным источником усталости оповещений для DevOps и дежурных инженерных групп.Временный локальный сбой маршрутизации интернет-провайдера или временная перегрузка сети между одним зондирующим узлом и исходным сервером не обязательно являются настоящим сбоем веб-сайта.

SimpleOps устраняет ложные оповещения за счет реализации проверки консенсуса в нескольких регионах.Когда основной узел проверки обнаруживает код состояния HTTP, отличный от 2xx, или тайм-аут соединения, вторичные узлы проверки в соседних географических регионах мгновенно выполняют параллельные проверки.Официальное предупреждение о сбое срабатывает только тогда, когда консенсус в нескольких регионах подтверждает сбой.