Как узнать потребление сети

Мониторинг потребления сетевых ресурсов в инфраструктуре

Потребление сети — это комплексный показатель, включающий объем переданных данных, скорость передачи (throughput), количество соединений, задержки (latency) и потери пакетов. Для DevOps-инженера мониторинг этих метрик критичен для обеспечения SLA, оптимизации производительности и контроля затрат. Методы и инструменты зависят от уровня наблюдения: от отдельных контейнеров до всей инфраструктуры.

Уровень операционной системы (хоста)

Наиболее базовый способ — использование встроенных утилит Linux.

• iftop: Показывает текущую полосу пропускания в реальном времени в табличном формате, аналогично top.

  sudo iftop -i eth0
  

• nload: Визуализирует входящий и исходящий трафик в виде графиков.

  nload eth0
  

• vnstat: Удобен для сбора и отображения долгосрочной статистики (за час, день, месяц).

  vnstat -l # live
  vnstat -d # daily
  

• ip и /proc: Низкоуровневый доступ к счетчикам.

  ip -s link show eth0
  cat /proc/net/dev
  

Уровень контейнеров и оркестратора

В современных средах мониторинг изолируется на уровень рабочей нагрузки.

• Docker: Статистику можно получить через docker stats или API.

  docker stats --format "table {{.Name}}\t{{.NetIO}}"
  

• Kubernetes:

    *   **Метрики cAdvisor**: Встроенный в kubelet агент собирает метрики сети для каждого пода. Они доступны через **Kubernetes Metrics API**.
    *   **Сторонние инструменты**: `kubectl top pod` показывает потребление CPU и памяти, но не сети. Для детальной сетевой статистики используются **Prometheus** (через **cAdvisor** или **kube-state-metrics**) и **Grafana** для визуализации.

Сетевой уровень (инфраструктура)

Здесь на помощь приходят специализированные системы мониторинга и анализа трафика.

• Пассивный сбор (Flow-based): Анализ обезличенных сетевых потоков.

    *   **sFlow** / **NetFlow** (Cisco) / **IPFIX**: Агенты на коммутаторах или выделенных пробниках отправляют данные о потоках на коллектор (например, **ntopng**, **ElastiFlow**, **PMACCT**). Позволяет увидеть "кто, с кем, какой порт, сколько".

• Активный мониторинг: Измерение доступности и качества сети между точками.

    *   **Smokeping**: Замеряет задержки и потери пакетов.
    *   **iperf3** / **nuttcp**: Бенчмаркинг пропускной способности канала между хостами.

```bash
# На сервере
iperf3 -s
# На клиенте
iperf3 -c <server_ip>
```

Комплексные платформы мониторинга

В DevOps-практике стандартом стал стек Observability, объединяющий метрики, логи и трассировку.

1. Prometheus + Node Exporter + cAdvisor + Grafana: Классический стек.

    *   **node_exporter** предоставляет метрики хоста (`node_network_receive_bytes_total`, `node_network_transmit_bytes_total`).
    *   **cAdvisor** — метрики контейнеров.
    *   **PromQL** запрос для подсчета скорости приема на интерфейсе за 5 минут:

    ```promql
    rate(node_network_receive_bytes_total{device="eth0"}[5m]) * 8
    ```

    Результат в **битах в секунду**.

1. APM и Service Mesh:

    *   **Istio Linkerd**: Сервисные сетки собирают детальнейшую телеметрию на уровне сервисов (RPS, задержки, ошибки) без модификации кода приложения.
    *   **Jaeger**, **Zipkin**: Позволяют отследить путь запроса через микросервисы и выявить сетевые проблемы на уровне конкретных вызовов.

1. Облачные провайдеры:

    *   **AWS CloudWatch** (NetworkIn/Out для EC2, ELB), **GCP Cloud Monitoring**, **Azure Monitor** предоставляют встроенные метрики для своих сетевых сущностей (VPC, Load Balancers, шлюзы). Часто требуют настройки расширенного мониторинга или flow-логов.

Ключевые метрики для анализа

DevOps-инженер должен отслеживать не только объем, но и качество:

• Пропускная способность (Throughput): bps, Mbps. Пиковые и средние значения.
• Задержка (Latency): P50, P95, P99 (перцентили). Рост P99 — частый симптом проблем.
• Потеря пакетов (Packet Loss): Даже 0.5% может критически повлиять на TCP-производительность.
• Количество соединений и ошибок: RST, ретрансмиты (TCP retransmits), ошибки на интерфейсе.

Практический подход

1. Определите базовый уровень (baseline): Какое нормальное потребление для сервиса?
2. Установите алерты: Не на абсолютный объем, а на аномалии (используйте Prometheus Alertmanager с правилами на rate(), прогнозирование) и превышение порогов, влияющих на бизнес-логику.
3. Интегрируйте в пайплайны: Включите нагрузочное тестирование сети (например, с iperf3) в CI/CD для проверки конфигураций.
4. Используйте distributed tracing: Для микросервисных архитектур это незаменимый инструмент для поиска узких мест в сетевом взаимодействии.

Таким образом, ответ на вопрос "как узнать потребление сети" — это не указание одной команды, а построение многоуровневой системы мониторинга, которая агрегирует данные от сетевых интерфейсов, контейнеров, оркестратора и прикладного уровня, предоставляя единую картину для анализа и оперативного реагирования.