kb/observability

Observability Linux: Prometheus, OpenTelemetry, eBPF profiling

Observability как третья опора надёжности после тестирования и code review: метрики через Prometheus, распределённые трассы через OpenTelemetry, логи через Loki/Vector, continuous profiling через eBPF/Pyroscope. Не теория, а реальные пайплайны и подводные камни production-deploy: cardinality-explosion, SLO и error budgets, alerting без шума.

10 статей в категории

§ статьи

alerting-rules-alertmanagerAlertmanager: route tree, inhibit, dedup, on-callAlertmanager - принимает alerts от Prometheus, дедупит, группирует, роутит по route tree в PagerDuty/Slack/email. Inhibit suppress'ит зависимые alerts при upstream-падении. Silence на время maintenance. Шум убивает on-call.
cardinality-explosionCardinality explosion: как убить Prometheus и как чинитьCardinality = uniq(metric × labels). Каждый series ≈ 3 KB RAM, 10M series = 30 GB RAM, Prom OOM-цикл. Source: user_id-labels, пути с ID, dynamic version. Diag - topk по __name__. Cure - drop labels через relabel или нормализация в коде.
pyroscope-continuous-profilingContinuous profiling: Pyroscope, eBPF, flame graphs в продеContinuous profiling - always-on CPU/memory profiler в проде через eBPF. 1-2% overhead. Flame graphs показывают hot path. Pyroscope (Grafana), Parca, Polar Signals. Замена ad-hoc perf для production debug.
tracing-basicsDistributed tracing: span, context propagation, samplingTracing - граф spans (parent-child) одного логического запроса через сервисы. Context передаётся HTTP-header traceparent (W3C). Sampling: head (на edge, дёшево) или tail (в Collector, точнее). Backend: Jaeger, Tempo, Zipkin.
loki-grafana-loggingLoki: label-based логи, LogQL, Promtail/Vector pipelineLoki - log aggregation с label-based индексом (не full-text как Elastic). Дёшево на S3-storage. Promtail/Vector как агенты. LogQL похож на PromQL: фильтр + parse + aggregation. Cardinality - враг.
opentelemetryOpenTelemetry: signals, OTLP, Collector pipelineOpenTelemetry - CNCF-стандарт для metrics+traces+logs в одном SDK. OTLP протокол (gRPC или HTTP). Collector принимает, фильтрует, роутит в Prom/Tempo/Loki/Jaeger. Auto-instrumentation без code change.
prometheus-basicsPrometheus: scrape, TSDB, PromQL и production-pitfallsPrometheus - сервер мониторинга: сам опрашивает приложения по HTTP, собирает числовые метрики, хранит во встроенной БД ~15 дней. По ним строят графики в Grafana и алерты через Alertmanager. Стандарт de-facto в Kubernetes.
service-discovery-prometheusService discovery в Prometheus: k8s, Consul, file_sd, relabelProm discoverит targets через k8s API, Consul, file_sd (static). relabel_configs - до scrape (filter+rewrite labels). metric_relabel - после scrape (drop bad metrics). Без relabel - cardinality из k8s взрывается.
sli-slo-error-budgetSLI / SLO / error budget: SRE-метрики без шумаSLI - метрика для пользователя (availability, p99 latency). SLO - цель за период (99.9% за 30d). Error budget = 1-SLO, расходуется на инциденты+релизы. Multi-window burn rate alerting заменяет threshold-алерты, меньше шума.
metric-typesТипы метрик: counter, gauge, histogram, summary4 типа метрик: counter (только вверх), gauge (любое значение), histogram (buckets для p99), summary (quantile в клиенте). Native histogram (Prom 2.40+) - sparse buckets, аккуратнее по памяти. Exemplars связывают метрику с trace_id.

← вернуться ко всем категориям базы знаний