Какие существуют метрики работы сети в Linux

Ключевые метрики работы сети в Linux

В Linux для мониторинга и диагностики сетевых проблем используется широкий спектр метрик, охватывающих разные уровни — от физического интерфейса до состояния соединений и производительности приложений. Как DevOps-инженер с более чем 10-летним опытом, я разделяю эти метрики на несколько ключевых категорий.

1. Метрики интерфейсов (Interface Statistics)

Это базовые метрики, которые отражают состояние физических и логических сетевых интерфейсов. Их можно получить через /proc/net/dev, ip -s link, или ifconfig.

$ ip -s link show eth0
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 00:16:3e:5e:6c:00 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped  missed  mcast
    1234567890  1234567  0       12       0       456
    TX: bytes  packets  errors  dropped  carrier collsns
    987654321   876543   0       0        0       0

Ключевые показатели:

• Пакеты/байты (RX/TX): объём входящего и исходящего трафика.
• Ошибки (errors): пакеты с повреждениями (например, CRC-ошибки).
• Отброшено (dropped): пакеты, которые ядро не смогло обработать из-за нехватки ресурсов (буферов, CPU). Высокое значение — явный признак проблем.
• Потеряно (missed): пакеты, которые не попали даже в драйвер из-за переполнения буфера сетевой карты.
• Коллизии (collisions) и Carrier losses: актуально для старых Ethernet-сетей, указывает на проблемы в физической среде.

2. Метрики подключений и портов (Connection and Socket Metrics)

Эти метрики показывают состояние сетевых соединений на уровне сокетов.

• Статистика протоколов (TCP/UDP): содержится в /proc/net/snmp, /proc/net/netstat. Ключевые TCP-метрики:

    *   **Active/Passive Opens**: количество установленных соединений.
    *   **Retransmitted Segments**: число ретрансмиттов. Резкий рост указывает на проблемы с сетью (потери, перегрузки).
    *   **Listen Overflows**: случаи, когда соединение было отброшено из-за переполнения очереди `listen()` (параметр **`net.core.somaxconn`**).

• Количество соединений по состояниям: Используется команда ss или netstat.

# Получить статистику по состояниям TCP-соединений
$ ss -tan | awk 'NR>1 {print $1}' | sort | uniq -c
   10 LISTEN
  150 ESTAB
    5 TIME-WAIT
    2 CLOSE-WAIT

3. Метрики производительности сети (Network Performance Metrics)

Эти метрики измеряются инструментами вроде ping, iperf3, nicstat, или мониторинговыми системами (Prometheus + node_exporter).

• Задержка (Latency): Время прохождения пакета туда и обратно (RTT). Измеряется ping.
• Потеря пакетов (Packet Loss): Процент пакетов, не дошедших до адресата.
• Пропускная способность (Throughput): Фактический объём данных, передаваемый за единицу времени. Часто ограничена самым медленным звеном (ширина канала, окна TCP, состояние CPU).
• Использование сетевых ресурсов (Utilization): Процент от максимальной пропускной способности канала.
• Перегрузка (Congestion): Проявляется в росте показателей Retransmits, TCPLostRetransmit, срабатывании алгоритмов контроля перегрузки (например, TCPRenoRecovery в /proc/net/netstat).

4. Метрики уровня очередей и планировщиков (Queueing & QoS)

В современных ядрах (особенно с tc и fq_codel) важно следить за буферами.

• Длина очереди (Queue Length/Backlog): Накопленные, но ещё не обработанные пакеты. Большая очередь увеличивает задержку (bufferbloat).
• Dropped/Overlimits (в выводе tc -s qdisc): Показывает, сколько пакетов отброшено политикой управления трафиком (tc).

# Показать статистику для очереди QDisc на интерфейсе eth0
$ tc -s qdisc show dev eth0
qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
 Sent 12345678 bytes 87654 pkt (dropped 120, overlimits 0 requeues 15)

5. Метрики системных ресурсов, влияющих на сеть

Сеть — это не только сетевая карта. Критически важны:

• Использование CPU, особенно в состояниях softirq: Обработка сетевых пакетов происходит в softirq (прерывания). Высокая нагрузка здесь может вызывать dropped пакеты.
• Использование памяти, особенно skbuff: Память под буферы сокетов. Просмотр лимитов: sysctl net.core.rmem_max, net.ipv4.tcp_rmem.
• Количество файловых дескрипторов: Каждое соединение использует дескриптор. Нехватка (Too many open files) обрушит сервис.

Инструменты сбора и анализа

На практике в DevOps мы не смотрим эти метрики вручную, а настраиваем их сбор и визуализацию:

• Prometheus + node_exporter: Собирает большинство метрик из /proc и /sys (сеть, CPU, память).
• Grafana: Визуализация на дашбордах.
• Специализированные экспортеры: snmp_exporter для сетевого оборудования, blackbox_exporter для проверки доступности и задержек извне.
• Трассировка (Tracing): tcpdump, wireshark для глубокого анализа проблем, eBPF-инструменты (bpftrace, BCC) для анализа производительности ядра в реальном времени.

Заключение: Для эффективного мониторинга в DevOps-среде необходимо собирать метрики всех перечисленных типов. Базовые метрики интерфейсов (dropped, errors) и TCP (retransmits) являются каноническими индикаторами проблем. Их аномальные значения служат триггером для более глубокого анализа с помощью метрик производительности и инструментов трассировки, чтобы локализовать причину: будь то сетевая инфраструктура, нехватка системных ресурсов или некорректная настройка приложения.