- Как посмотреть количество подключений к серверу
- Мониторинг сетевого стека linux
- Netlink
- Считаем соединения
- Разбивка по IP
- Детализация рулит
- TCP backlog
- Счетчики и ошибки протоколов
- TCP ретрансмиты
- Conntrack
- Вместо заключения
- Утилита ss в Linux
- Общая информация
- Опции утилиты ss
- Примеры использования
- Мониторинг сетевых подключений
- Просмотр статистики статистики сетевых подключений
- Фильтрация по протоколу
- Фильтрация по состоянию соединения
- Фильтрация по адресу и номеру порта
- Выводы
Как посмотреть количество подключений к серверу
Посмотреть количество подключений на Linux VDS сервере можно в консоли при помощи системной утилиты netstat. Ниже представлены наиболее часто используемые варианты использования этой команды. Для получения полноценных результатов рекомендуется выполнять эти команды от имени пользователя root, либо от пользователя, который присутствует в списке sudoers на сервере.
Показать все активные сетевые соединения.
Показать и отсортировать все активные соединения на 80-м порту (порт http).
Показать число полуоткрытых соединений (которые в состоянии SYN RECEIVED). Нормальное количество соединений – до 5. Большие значения таких соединений на сервере могут предвещать наличие происходящей SYN-атаки.
Вывести отсортированный список IP-адресов, с которых пришли SYN-пакеты.
Вывести список уникальных IP-адресов, с которых пришли SYN-пакеты.
Вывести результат подсчета количества соединений к серверу с каждого IP-адреса.
Вывести результат подсчета количества соединений с сервером по TCP или UDP протоколам с каждого IP-адреса.
Вывести результат подсчета количества соединений c сервером с каждого IP-адреса, которые в статусе ESTABLISHED (установленные соединения).
Показать список IP-адресов и количество подключений с них к серверу через порт 80, который по умолчанию используется HTTP-протоколом.
Чтобы получить полную справку по использованию утилиты netstat, используйте в консоли команду:
Источник
Мониторинг сетевого стека linux
Часто мониторинг сетевой подсистемы операционной системы заканчивается на счетчиках пакетов, октетов и ошибок сетевых интерфейсах. Но это только 2й уровень модели OSI!
С одной стороны большинство проблем с сетью возникают как раз на физическом и канальном уровнях, но с другой стороны приложения, работающие с сетью оперируют на уровне TCP сессий и не видят, что происходит на более низких уровнях.
Я расскажу, как достаточно простые метрики TCP/IP стека могут помочь разобраться с различными проблемами в распределенных системах.
Netlink
Почти все знают утилиту netstat в linux, она может показать все текущие TCP соединения и дополнительную информацию по ним. Но при большом количестве соединений netstat может работать достаточно долго и существенно нагрузить систему.
Есть более дешевый способ получить информацию о соединениях — утилита ss из проекта iproute2.
Ускорение достигается за счет использования протола netlink для запросов информации о соединениях у ядра. Наш агент использует netlink напрямую.
Считаем соединения
Disclaimer: для иллюстрации работы с метриками в разных срезах я буду показывать наш интерфейс (dsl) работы с метриками, но это можно сделать и на opensource хранилищах.
В первую очередь мы разделяем все соединения на входящие (inbound) и исходящие (outbound) по отношению к серверу.
Каждое TCP соединения в определенный момент времени находится в одном из состояний, разбивку по которым мы тоже сохраняем (это иногда может оказаться полезным):
По этому графику можно оценить общее количество входящих соединений, распределение соединений по состояниям.
Здесь так же видно резкое падение общего количества соединений незадолго до 11 Jun, попробуем посмотреть на соединения в разрезе listen портов:
На этом графике видно, что самое значительное падение было на порту 8014, посмотрим только 8014 (у нас в интерфейсе можно просто нажать на нужном элементе легенды):
Попробуем посмотреть, изменилось ли количество входящий соединений по всем серверам?
Выбираем серверы по маске “srv10*”:
Теперь мы видим, что количество соединений на порт 8014 не изменилось, попробуем найти на какой сервер они мигрировали:
Мы ограничили выборку только портом 8014 и сделали группировку не по порту, а по серверам.
Теперь понятно, что соединения с сервера srv101 перешли на srv102.
Разбивка по IP
Часто бывает необходимо посмотреть, сколько было соединений с различных IP адресов. Наш агент снимает количество TCP соединений не только с разбивкой по listen портам и состояниям, но и по удаленному IP, если данный IP находится в том же сегменте сети (для всех остальный адресов метрики суммируются и вместо IP мы показываем “
Рассмотрим тот же период времени, что и в предыдущих случаях:
Здесь видно, что соединений с 192.168.100.1 стало сильно меньше и в это же время появились соединения с 192.168.100.2.
Детализация рулит
На самом деле мы работали с одной метрикой, просто она была сильно детализирована, индентификатор каждого экземпляра выглядит примерно так:
Например, у одно из клиентов на нагруженном сервере-фронтенде снимается
700 экземпляров этой метрики
TCP backlog
По метрикам TCP соединений можно не только диагностировать работу сети, но и определять проблемы в работе сервисов.
Например, если какой-то сервис, обслуживающий клиентов по сети, не справляется с нагрузкой и перестает обрабатывать новые соединения, они ставятся в очередь (backlog).
На самом деле очереди две:
- SYN queue — очередь неустановленных соединений (получен пакет SYN, SYN-ACK еще не отправлен), размер ограничен согласно sysctl net.ipv4.tcp_max_syn_backlog;
- Accept queue — очередь соединений, для которых получен пакет ACK (в рамках «тройного рукопожатия»), но не был выполнен accept приложением (очередь ограничивается приложением)
При достижении лимита accept queue ACK пакет удаленного хоста просто отбрасывается или отправляется RST (в зависимости от значения переменной sysctl net.ipv4.tcp_abort_on_overflow).
Наш агент снимает текущее и максимальное значение accept queue для всех listen сокетов на сервере.
Для этих метрик есть график и преднастроенный триггер, который уведомит, если backlog любого сервиса использован более чем на 90%:
Счетчики и ошибки протоколов
Однажды сайт одного из наших клиентов подвергся DDOS атаке, в мониторинге было видно только увеличение трафика на сетевом интерфейсе, но мы не показывали абсолютно никаких метрик по содержанию этого трафика.
В данный момент однозначного ответа на этот вопрос окметр дать по-прежнему не может, так как сниффинг мы только начали осваивать, но мы немного продвинулись в этом вопросе.
Попробуем что-то понять про эти выбросы входящего трафика:
Теперь мы видим, что это входящий UDP трафик, но здесь не видно первых из трех выбросов.
Дело в том, что счетчики пакетов по протоколам в linux увеличиваются только в случае успешной обработки пакета.
Попробуем посмотреть на ошибки:
А вот и наш первый пик — ошибки UDP:NoPorts (количество датаграмм, пришедших на UPD порты, которые никто не слушает)
Данный пример мы эмулировали с помощью iperf, и в первый заход не включили на сервер-приемщик пакетов на нужном порту.
TCP ретрансмиты
Отдельно мы показываем количество TCP ретрансмитов (повторных отправок TCP сегментов).
Само по себе наличие ретрансмитов не означает, что в вашей сети есть потери пакетов.
Повторная передача сегмента осуществляется, если передающий узел не получил от принимающего подтверждение (ACK) в течении определенного времени (RTO).
Данный таймаут расчитывается динамически на основе замеров времени передачи данных между конкретными хостами (RTT) для того, чтобы обеспечивать гарантированную передачу данных при сохранении минимальных задержек.
На практике количество ретрансмитов обычно коррелирует с нагрузкой на серверы и важно смотреть не на абсолютное значение, а на различные аномалии:
На данном графике мы видим 2 выброса ретрансмитов, в это же время процессы postgres утилизировали CPU данного сервера:
Cчетчики протоколов мы получаем из /proc/net/snmp.
Conntrack
Еще одна распространенная проблема — переполнение таблицы ip_conntrack в linux (используется iptables), в этом случае linux начинает просто отбрасывать пакеты.
Это видно по сообщению в dmesg:
Агент автоматически снимает текущий размер данной таблицы и лимит с серверов, использующих ip_conntrack.
В окметре так же есть автоматический триггер, который уведомит, если таблица ip_conntrack заполнена более чем на 90%:
На данном графике видно, что таблица переполнялась, лимит подняли и больше он не достигался.
Вместо заключения
Примеры наших стандартных графиков можно посмотреть в нашем демо-проекте.
Там же можно постмотреть графики Netstat.
Источник
Утилита ss в Linux
Иногда бывает необходимо посмотреть какие сетевые подключения Linux открыты, какие IP адреса используются или какие порты прослушиваются. Раньше для таких целей использовалась утилита netstat. Её, без сомнения, знают все системные администраторы и специалисты по безопасности. Но она больше не поставляется по умолчанию в новых дистрибутивах. Вместо неё используется новая утилита под названием ss.
Netstat сканирует директорию /proc для получения необходимой информации, но в новых версиях ядра была реализована специальная подсистема для мониторинга сети в Linux. Её и использует ss, с помощью этой утилиты вы можете получить больше информации о сетевых подключениях и работает она гораздо быстрее.
Как вы уже поняли в этой статье мы рассмотрим мониторинг сетевых подключений в Linux с помощью утилиты из пакета iproute — ss linux. Начнем, как обычно, с синтаксиса и основных опций.
Общая информация
Как уже было сказано работает утилита ss в Linux на основе подсистемы ядра. Синтаксис очень простой — сама команда и ее опции:
$ ss опции [ фильтр_состояния] [фильтр_адреса]
Для удобства вывод команды ss можно фильтровать с помощью grep:
$ ss опции | grep шаблон
Опции указывает различные параметры отображения и фильтрации информации. Фильтры по состоянию и адресу очень интересная вещь, они позволяют выполнять мониторинг сетевых подключений в Linux, только тех что нужно. Например, только открытых, закрытых или находящихся на этапе подключения. Подробнее мы рассмотрим это в конце статьи.
Опции утилиты ss
Для сетевых подключений в Linux с помощью утилиты ss можно использовать такие опции:
- -V — Version показать версию утилиты.
- -n — Numeric не определять имена служб.
- -r — Resolve определять сетевые имена адресов с помощью DNS.
- -a — All отобразить все сокеты (открытые соединения).
- -l — Listening показать только прослушиваемые сокеты.
- -o — Options показать информацию таймера.
- -e — Extended выводить расширенную информацию о сокете.
- -p — Processes, показать процессы, использующие сокет.
- -i — Internal, посмотреть внутреннюю информацию TCP.
- -s — Summary, статистика использования сокета.
- -D — экспортировать текущее состояние TCP сокетов в файл.
- -F — работать с информацией, взятой из файла.
Кроме того, можно вывести сокеты только нужного протокола:
- -4, —ipv4 — только сокеты протокола IP версии 4.
- -6 —ipv6 — только сокеты протокола IP версии 6.
- -0, —packet — только PACKET сокеты.
- -t, —tcp — TCP сокеты.
- -u, —udp — UDP сокеты.
- -d, —dhcp — DHCP сокеты.
- -r, —raw — RAW сокеты.
- -x, —unix — UNIX сокеты.
Для фильтрации протоколов можно использовать не только эти опции, но и универсальную опцию -f, передав ей в параметре название протокола. Здесь собраны самые основные опции, если вам нужно больше информации — смотрите справку команды.
Примеры использования
А теперь давайте рассмотрим примеры использования утилиты ss Linux. Возможно, из описания опций вы мало что поняли, но с примерами все встанет на свои места.
Мониторинг сетевых подключений
Сначала смотрим все сетевые подключения:
Посмотрим только TCP соединения:
Теперь только Unix:
Для отображения UDP сокетов используйте опцию u. По умолчанию будут показаны только подключенные соединения. Если хотите получить все, нужно использовать опцию a. Поскольку UDP, это протокол без постоянного соединения, то без опции -a мы ничего не увидим:
По умолчанию утилита не пытается определять имена хостов через dns, но можно ее попросить делать это опцией -r:
Обратная опция -n, не будет выполняться не только dns резолвинг, но и определение протоколов портов, зато мониторинг сети в Linux работать будет быстрее:
Теперь просмотрим только прослушиваемые tcp сокеты.
Здесь мы видим только имена служб, это не всегда удобно, указав опцию n, мы получим номера портов. Так же само можно посмотреть прослушиваемые udp сокеты:
Также мы можем попытаться узнать название и PID процесса, использующего сокет:
Просмотр статистики статистики сетевых подключений
Для просмотра статистики по использованию сетевых подключений наберите:
С помощью опции -о можно посмотреть информацию о таймере и состоянии подключения.
Фильтрация по протоколу
Мы можем отображать только нужный нам протокол. Например только ipv4:
sudo ss -tl -f inet4
Так же само можно отобразить только соединения ipv6:
Фильтрация по состоянию соединения
В синтаксисе команды мы описали два дополнительных параметра. Фильтрация состояния и фильтрация по адресу. Рассмотрим теперь как ими пользоваться. Сокет TCP может находиться в одном из нескольких состояний. Например, так утилита ss linux выведет только подключенные сокеты.
ss -t4 state established
Или сокеты в состоянии ожидания:
sudo ss -t4 state time-wait
В параметр state можно передать одно из следующих значений:
- established
- syn-sent
- syn-recv
- fin-wait-1
- fin-wait-2
- time-wait
- closed
- close-wait
- last-ack
- closing
- all — все состояния
- connected — все кроме прослушиваемых и закрытых
- synchronized — все кроме syn-sent
- bucket — time-wait и syn-recv
- big — все кроме bucket
Не все состояния подключений можно увидеть просто выполнив команду. Например, syn-sent и syn-recv вряд ли получиться словить, потому что соединения находятся в этом состоянии очень короткое время. Для их отображения удобно использовать команду watch:
watch -n 1 «ss -t4 state syn-sent»
После запуска команды откройте любой сайт в браузере. Вы увидите как появится одно или несколько соединений на несколько секунд.
Фильтрация по адресу и номеру порта
Кроме фильтрации по состоянию, tcp сокеты можно фильтровать по адресам или портам соединений.
Например, отберем все сетевые подключения linux с портом источником или приемником ssh, то есть все входящие и исходящие соединения ssh:
ss -at ‘( dport = :ssh or sport = :ssh )’
Или сокеты с портом назначения 80 или 443:
ss -nt ‘( dst :443 or dst :80 )’
Такой синтаксис тоже будет работать:
ss -nt dst :443 or dst :80
Еще несколько примеров фильтрации:
Фильтрация по адресу:
ss -nt dst 74.125.236.178
Фильтрация по адресу и подсети:
ss -nt dst 74.125.236.178/16
И по адресу и порту:
ss -nt dst 74.125.236.178:80
Если вы хотите фильтровать сетевые соединения по порту, перед портом ставьте двоеточие:
ss -nt dport = :80
Можно использовать такие операторы сравнения:
- = или ge — больше или ровно порту.
- == или eq — точное соответствие.
- != или ne — не равно.
- или lt — больше.
Выводы
Вот и всё. Основную информацию о том, как выполнять мониторинг сети в Linux с помощью утилиты ss рассмотрели. Если вам нужно больше информации и примеров смотрите документацию по утилитам набора iproute.
Источник