Как вести мониторинг производительности сервера и сети с помощью анализа трафика Wireshark?

При возникновении проблем в работе приложений и сервисов очень сложно определить истинную причину торможения. И самый распространенный ответ — это сеть работает медленно, каналы узкие, операторы связи не обеспечивают SLA. Ведь никому не интересно просматривать тысячи пакетов с анализатора протоколов (сниффера). Но очень часто проблема оказывается именно в работе самого приложения или сервера, на котором оно развернуто. Почему анализ и выявление проблем с производительностью серверов достаточно сложная задача?

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

Мониторинг производительности начинается с пользователя

Идем к пользователю и начинаем захват трафика на его стороне. Часто проблема уже прошла, и ждать ее возникновения вновь приходится долго. Бедный пользователь делает те же самые действия, но система работает стабильно. Негатив со стороны ИТ-специалиста и лестные слова в душе в сторону пользователя обеспечены. Выход можно поставить захват трафика на стороне сервера, запустив dumpcap на длительное время с сохранением трафика на USB диск. Но давайте попробуем посмотреть файл с захваченным трафиком.

Оценим время подключения пользователя к серверу

Ищем в файле DNS запрос к серверу, на котором работает приложение. Оцениваем время отклика DNS сервера и убеждаемся, что оно приемлемое для вашей сети, используя колонку Time в Wireshark (обычно время отклика не должно быть более 150 мс). Если пользователь часто обращается к этому серверу, то ищем пакет запросом на установление TCP сессии (TCP SYN).

Примечание: Когда мы анализируем время отклика приложений, будьте уверены, что анализатор настроен корректно и использует дельту во времени между пакетами. Это можно проверить в настройках Wireshark меню View.

Для анализа скорости установления сессии с сервером необходимо воспользоваться фильтром TCP Stream для выборки пакетов, которые относятся к данной TCP сессии (правый клик мыши на любом пакете в TCP сессии и выбираем TCP Stream фильтр). Основная цель наших действий это сравнить время передачи по сети (network roundtrip time) со временем отклика приложения (server response time).

Как только фильтр настроен, и мы видим пакеты, относящиеся к сессии, оцените временную дельту между пакетом пользователя с TCP SYN и пакетом с TCP SYN-ACK отправленным сервером пользователю. Это время можно использовать как отправную точку для поиска источника проблемы. На скриншоте ниже время отображается в пакете номер 7 и составляем 134 мс.

Анализ времени отклика приложения

Как только пользователь установил TCP соединение, он запросит необходимые данные. В примере выше клиент отправил запрос к Web серверу HTTP GET. Обращаемся к колонке дельта и видим, что сервер ответил через 125 мс. с TCP ACK, что подтверждает получение сервером запроса, но не сам ответ. И затем сервер потратил 4,85 секунд на отправку пакета с требуемыми данными и затем быстро передал оставшиеся пакеты на скорости канала (сеть летает). Сравнивая время 4.85 секунды с временем установления соединения – 134 мс. мы явно можем сделать вывод – что время отклика сервера очень большое.

Сервер, пользователь или сеть – кто виноват, и что делать?

Основываясь на данной информации очень просто понять, что делать дальше. Если время отклика сервера существенно выше времени установления соединения (connection setup time) и нет повторных передач (TCP retransmissions), то проблема на стороне сервера. Сеть в данном примере ни при чем.

Если задержек в данной транзакции не обнаружено, то нужно перемещаться к другому запросу, внимательно отслеживая количество времени, которое было затрачено сервером на ответ пользователя. Постепенно получив опыт захвата трафика на стороне клиента, можно переходить к анализу трафика на стороне сервера, так как этот анализ позволит понять, чем был занят сервер, отвечая на запрос нашего пользователя в течение 4,38 секунд.

Выводы

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

Всегда на связи, Игорь Панов.

Делитесь нашими статьями в соцсетях и задавайте вопросы в комментариях!

См. также:

• 5 недостатков Wireshark: в чём бесплатный сниффер проигрывает коммерческим аналогам?
• Как настроить фильтры для захвата трафика в WireShark? Примеры!
• Диагностика сети и приложений с помощью OptiView XG