Диагностика инцидента

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

HTTP-ответ, тело и заголовки

Доступно только при HTTP/HTTPS проверках.

Анализ HTTP-ответов позволяет определить тип отказа и возможные причины:

• Коды 4xx свидетельствуют о проблемах на стороне клиента (например, некорректные запросы, ошибки аутентификации, блокировки доступа);
• Коды 5xx указывают на сбои серверного программного обеспечения (перегрузка, ошибки конфигурации, сбои в обработке запросов);
• Тело ответа может включать специфические диагностические сообщения от серверных компонентов, например, об ошибках в работе базы данных или превышении лимита запросов;
• Заголовки ответа содержат критически важную метаинформацию: идентификацию серверного ПО, параметры кэширования, политики безопасности (CSP, CORS) и сжатия трафика.

Скриншот состояния сайта

Доступно только при HTTP/HTTPS проверках.

Фиксация визуального состояния страницы на момент сбоя помогает верифицировать:

• некорректный рендеринг контента;
• загрузку частичных элементов или ресурсов (например, ошибки при получении CSS или JavaScript);
• сообщения об ошибках, отображаемые фронтенд-приложением.

Тайминги

Доступно только при HTTP/HTTPS проверках.

Анализ временных характеристик сетевого запроса помогает выявить, на каком этапе соединение испытывает задержки. Разберём основные параметры:

Фактический URL (effective_url) — итоговый URL после всех перенаправлений;

Число перенаправлений (redirect_count) — количество выполненных редиректов;

Время разрешения имени (name_lookup_time) — время, затраченное на разрешение доменного имени в IP-адрес;

Время установления соединения (connect_time) — время установления TCP-соединения;

Время установления соединения с приложением (app_connect_time) — время, затраченное на установку защищённого соединения (TLS handshake);

Время до начала передачи (pre_transfer_time) — время от начала запроса до момента готовности к передаче данных;

Время начала передачи (start_transfer_time) — время от начала запроса до получения первого байта ответа;

Суммарное время перенаправления (redirect_time) — общее время, потраченное на редиректы;

Полное время запроса (total_time) — общее время выполнения запроса;

Код HTTP-ответа (response_code) — HTTP-код ответа сервера.

Эти параметры помогают локализовать источник задержек: например, длительное время разрешения имени может указывать на проблемы с DNS, а высокая время начала передачи — на перегрузку серверной инфраструктуры.

Зарезолвленные IP-адреса

Анализ IP-адресов, возвращаемых DNS-серверами, позволяет выявить:

• расхождения в конфигурации DNS-записей (например, разное разрешение IP в разных географических регионах);
• случаи попадания IP-адреса в чёрные списки или ошибочную маршрутизацию;
• проблемы с кешированием устаревших DNS-записей.

Трассировка маршрута (Traceroute)

Используется для диагностики маршрутизации пакетов, позволяет выявить:

• сегменты сети с высокими задержками;
• сбои в промежуточных узлах, приводящие к потере пакетов;
• возможные блокировки трафика на границах автономных систем (AS).

Гибридный анализ маршрутизации (MTR)

MTR выполняет множественные измерения и фиксирует динамические изменения в маршрутах сети:

• процент потерь пакетов на каждом узле;
• вариативность задержек в реальном времени;
• изменение маршрутов в зависимости от нагрузки на сеть.

Валидация TLS-сертификатов (OpenSSL)

Диагностика HTTPS-соединений с использованием OpenSSL позволяет определить:

• истечение срока действия сертификата;
• корректность цепочки доверия и проблемы с корневыми центрами сертификации;
• устаревшие или небезопасные криптографические протоколы (например, использование SSL 3.0 или слабых шифров AES128).

Диагностика сетевой доступности (Ping)

Только при проверках Ping.

Используется для оценки доступности хоста и стабильности соединения:

• отсутствие ответа может свидетельствовать о блокировке ICMP-пакетов или полной недоступности узла;
• высокий уровень потерь пакетов указывает на проблемы с маршрутизацией;
• увеличение задержек сигнализирует о перегрузке сети.

Анализ портов (Netcat)

Позволяет тестировать доступность конкретных сервисов на сервере:

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