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