Как вы выстроите подход к диагностике перемежающихся (intermittent) сетевых проблем в продакшене, которые невозможно воспроизвести по требованию, с учётом компромиссов между постоянным сбором диагностических данных и его стоимостью/нагрузкой?

Короткий ответ

Единого готового рецепта нет: баланс между объёмом постоянно собираемых диагностических данных (трейсинг, сэмплированные дампы трафика, детальные метрики соединений) и их стоимостью (нагрузка на CPU/диск/сеть, объём хранения) зависит от критичности сервиса, частоты проблемы и готовности организации инвестировать в постоянно работающую диагностическую инфраструктуру ради проблем, которые проявляются редко и непредсказуемо.

Как это работает подробнее

Проблема, которую нельзя воспроизвести по требованию, требует перехода от реактивной диагностики (запустить tcpdump после того, как проблема уже случилась) к проактивному постоянному сбору сигналов низкой стоимости, которые можно детализировать после факта: агрегированные метрики по соединениям (ss-статистика, счётчики ретрансмиссий TCP из /proc/net/snmp или netstat -s), распределённый трейсинг запросов с таймингами на каждом хопе, и опционально — постоянно работающий сэмплированный захват трафика (например, только заголовки, с ротацией) на критичных сегментах сети.

Пример кода

commands.shКопировать

# постоянный лёгкий мониторинг ретрансмиссий
nstat -az TcpRetransSegs TcpExtTCPLostRetransmit
# точечное включение детального дампа при срабатывании алерта
timeout 300 tcpdump -i eth0 host 203.0.113.10 -w incident_$(date +%s).pcap -C 50

Что использовать на практике

• Практика. выстраивают многоуровневую систему: лёгкие постоянные метрики (retransmits, connection resets, latency percentiles) с алертами на аномалии как первый уровень обнаружения; при срабатывании алерта или появлении паттерна — временное включение более тяжёлой диагностики (детальный tcpdump с фильтром, профилирование) именно в момент или сразу после воспроизведения; корреляция сетевых метрик с метриками приложения и инфраструктуры (деплои, изменения конфигурации, скачки нагрузки) по единой временной шкале, чтобы находить совпадения по времени даже без прямого воспроизведения.
• Компромисс. nstat на постоянной основе покажет рост счётчика TcpRetransSegs, коррелирующий по времени с жалобами пользователей, что даёт основание включить точечный, ограниченный по времени и размеру tcpdump именно на подозрительном хосте для детального разбора следующего эпизода.

Подводные камни

• Риск. включать постоянный полный захват трафика 'на всякий случай' без ограничения объёма и ротации, создавая дополнительную нагрузку и риск заполнения диска; полагаться только на логи приложения без сетевых метрик низкого уровня, упуская проблемы вроде ретрансмиссий или MTU, не видимые на прикладном уровне; не сохранять историю изменений конфигурации/деплоев рядом с метриками, из-за чего невозможно сопоставить начало аномалии с конкретным изменением.