← Back to blog

Network Observability: Prometheus, OpenTelemetry, Hubble

Feb, 21, 2026

#networking#observability#prometheus#opentelemetry#cilium

⚙️ Теория

🔭 Что такое Network Observability

Наблюдаемость сети это способность объяснить:

  • что сломалось;
  • где именно (node/namespace/service/route);
  • почему это случилось (дропы, таймауты, saturation, policy deny).

Практически нужен многослойный набор сигналов:

  • метрики (Prometheus),
  • телеметрия/трейсы (OpenTelemetry),
  • потоковые данные eBPF/L3-L7 (например, Hubble в Cilium).

📈 Prometheus: метрики и latency профиль

Для сетевого и сервисного трафика полезны:

  • throughput (requests/sec, bytes/sec);
  • ошибки (4xx/5xx, drops);
  • latency (p50/p95/p99);
  • saturation (очереди, active connections, CPU softirq pressure).

Типы метрик и практики инструментирования описаны в документации Prometheus.

🧩 OpenTelemetry: корреляция сигналов

OpenTelemetry дает единый pipeline для telemetry-data:

  • Collector собирает/обогащает/маршрутизирует данные;
  • traces связывают hop-ы между сервисами;
  • можно объединять метрики/логи/трейсы для incident analysis.

Ключевая ценность: меньше "слепых зон" между приложением и сетью.

🌐 Hubble (Cilium): видимость L3-L7 потоков

Hubble использует eBPF-данные Cilium и показывает:

  • кто с кем общался (source/destination identity);
  • какие policy permit/deny сработали;
  • где появились drops/latency anomalies.

Это особенно полезно при разборе "network policy сломала сервис" и межnamespace-инцидентов.

❓ Что нужно уметь объяснить

Почему одних "красивых дашбордов" недостаточно?

Потому что без корректной модели сигналов и SLO дашборд не дает ответа "почему и где сломалось".
Нужны метрики, которые привязаны к архитектурным гипотезам и runbook.

Почему p95/p99 важнее среднего latency?

Среднее скрывает хвосты распределения.
p95/p99 лучше показывает пользовательский опыт в деградации и перегрузке.

Где типичный источник ложных выводов?

  • несогласованные label/атрибуты;
  • высококардинальные метрики без контроля;
  • отсутствие связи между metric spike и реальным трафик-путем.

🧪 Практика

1. Проверить метрики Prometheus

curl -s http://prometheus:9090/api/v1/label/__name__/values | head

Убедитесь, что есть ключевые latency/error/traffic метрики по ingress/proxy/service.

2. OpenTelemetry Collector: базовый health-check

kubectl get pods -n observability
kubectl logs -n observability deploy/otel-collector --tail=100

Проверьте ошибки экспорта, очередь и backpressure.

3. Hubble: быстрый потоковый анализ

hubble status
hubble observe --since 5m --protocol http

Смотрите deny/drop и аномалии latency по namespace/service.

4. Минимальный SLO-набор

  • availability (успешные запросы);
  • latency (p95/p99 для критичных путей);
  • error budget burn rate;
  • network drops/denies как отдельный инцидентный сигнал.

🧾 Вывод

Сильная network observability строится на корреляции, а не на отдельном инструменте.
Комбинация Prometheus + OpenTelemetry + Hubble дает достаточный уровень детализации для production-разборов, если заранее заданы SLO и стандарты метрик.

📚 Ссылки

✅ Проверка источников

Network Observability: Prometheus, OpenTelemetry, Hubble | Aleksandr Suprun