Предыстория: один из наших серверов Ubuntu случайно (?) Перестает отвечать, т.е. некоторые соединения прерываются, и сервер некоторое время не принимает новые. По крайней мере, это то, что мы видим в логах зависимых сервисов. Проблема длится в лучшем случае несколько минут. Бывает 1-3 раза в день. Мы используем munin для мониторинга этого сервера, но ничто из стандартных графиков для нас не выделяется.
После первоначальной диагностики ничего не произошло, но наш центр обработки данных сообщил нам, что когда это происходит, на их графиках наблюдаются короткие высокие всплески трафика. Больше никакой полезной информации от них. Как определить, что их вызывает? (исходный IP, целевой порт)
Я думал о захвате пакетов с помощью tcpdump, но понятия не имел, какой фильтр можно применить, чтобы избежать создания гигабайт журналов. Может быть, существует инструмент для регистрации всех подключений и печати статистики (длительность подключения, обмен байтами, скорость)? Предполагая, что это не пакеты без установления соединения.
Не предполагайте, что основная причина этих событий - «высокие пики трафика», пока вы не соберете больше данных. Это могут быть самые разные проблемы, обычно относящиеся к категориям использования, насыщения или ошибок. Посмотрите на все показатели, включая время ответа вашего приложения на запросы пользователей. Прочтите свои журналы, включая системный журнал.
Если событие слишком короткое для вашего интервала наблюдения, попробуйте какой-нибудь мониторинг с высоким разрешением. Например, Netdata может собирать широкий спектр показателей с интервалом в 1 секунду..
Может быть, существует инструмент для регистрации всех подключений и печати статистики (длительность подключения, обмен байтами, скорость)?
Естественно, что кто-то для этого собрал скрипты трассировки BPF. Реализация Брендана Грега называется tcplife. Источник в репо bcc.
# ./tcplife -t TIME(s) PID COMM LADDR LPORT RADDR RPORT TX_KB RX_KB MS 0.000000 5973 recordProg 127.0.0.1 47986 127.0.0.1 28527 0 0 0.25 0.000059 3277 redis-serv 127.0.0.1 28527 127.0.0.1 47986 0 0 0.29 1.022454 5996 recordProg 127.0.0.1 47988 127.0.0.1 28527 0 0 0.23 1.022513 3277 redis-serv 127.0.0.1 28527 127.0.0.1 47988 0 0 0.27 2.044868 6019 recordProg 127.0.0.1 47990 127.0.0.1 28527 0 0 0.24 2.044924 3277 redis-serv 127.0.0.1 28527 127.0.0.1 47990 0 0 0.28 3.069136 6042 recordProg 127.0.0.1 47992 127.0.0.1 28527 0 0 0.22 3.069204 3277 redis-serv 127.0.0.1 28527 127.0.0.1 47992 0 0 0.28 This shows that the recordProg process was connecting once per second.
Множество заявлений об отказе от ответственности: Linux 4.4 или новее, закрываются только сеансы TCP, обнаружение PID отрывочно. Но вы можете показывать закрытые TCP-сеансы в реальном времени с микросекундными отметками времени без отслеживания пакетов.
Если события не улавливаются, попробуйте трассировка TCP подключений.