← Back to notes

Network Observability: Prometheus,
OpenTelemetry, Hubble

2026-02-21

#observability#prometheus#opentelemetry#cilium

Теория

Network Observability

Цель — отвечать на три вопроса в инциденте: что сломалось, где (node / namespace / service / route), почему (drops, timeouts, saturation, policy deny). Многослойные сигналы:

  • метрики — Prometheus (счётчики, histogram'ы);
  • трейсы и логи — OpenTelemetry;
  • сетевые потоки L3-L7 — eBPF (Cilium/Hubble, Pixie).

Prometheus

Минимальный набор сигналов по Four Golden Signals:

  • traffic — requests/sec, bytes/sec;
  • errors — 4xx/5xx, conntrack drops;
  • latency — p50/p95/p99 через histogram_quantile() над bucket-метриками;
  • saturation — queue depth, node_softnet_dropped_total, conntrack utilization, sysctl nf_conntrack_count vs _max.

Histogram'ы предпочтительнее summary при aggregation между инстансами (prometheus.io/docs/practices/histograms). Контролируйте кардинальность лейблов — path и user_id в label убивают TSDB.

OpenTelemetry

OTel — vendor-neutral спецификация и SDK для traces, metrics, logs (RFC-style, opentelemetry.io/docs/specs). Ключевое:

  • OTLP — единый wire-protocol (gRPC или HTTP/protobuf);
  • Collector — pipeline receivers → processors → exporters;
  • Semantic Conventions — стандартные имена атрибутов (http.request.method, net.peer.name).

Traces связывают span'ы между сервисами через W3C Trace Context (traceparent header).

Hubble (Cilium)

Hubble — observability-плоскость поверх eBPF-данных Cilium. Показывает:

  • идентичности source/destination (Pod, namespace, ServiceAccount);
  • результат NetworkPolicy (allow / deny / audit);
  • L7-метрики для HTTP/gRPC/Kafka/DNS при включённом L7-policy;
  • drops с причиной (policy_denied, unsupported_l3, invalid_source_ip).

CLI hubble observe и Hubble UI работают через unix-socket агента или Hubble Relay в кластере.

Практика

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