Observability/Начальный ~ 5 мин

Введение в observability

Observability - это способность понять состояние системы по сигналам, которые она сама отдает наружу: логам, метрикам, трейсам, профилям, health/readiness checks и событиям в инфраструктуре.

После модулей про HTTP, архитектуру, инфраструктуру, Kafka, Redis и PostgreSQL у вас уже есть почти production-сервис. Но без observability он остается черным ящиком: пользователи жалуются, pipeline зеленый, контейнер живой, а где деградация - непонятно.

Три главных вопроса

Хорошая наблюдаемость отвечает не на "сколько у нас графиков", а на вопросы:

что сейчас сломано или деградирует;
почему это произошло;
кого это затронуло и насколько сильно.

Если dashboard красивый, но не помогает ответить на эти вопросы, это декор, а не observability.

Сигналы

Сигнал	Для чего нужен	Типичная ошибка
Logs	Детали конкретного события: request failed, retry exhausted, migration started.	Писать шум без request id, user impact и причины.
Metrics	Числа во времени: latency, error rate, queue lag, DB pool usage.	Мерить все подряд без SLI и владельца алерта.
Traces	Путь запроса через сервисы, БД, cache, broker.	Включить tracing, но не прокидывать context.
Profiles	CPU, memory, goroutines, mutex/block contention.	Открывать pprof только после пожара.
Alerts	Сигнал человеку, что нужен action.	Алертить на симптомы без runbook и порога влияния.

Monitoring, observability, debugging

Эти слова часто смешивают, но в production это разные режимы работы:

Режим	Вопрос	Типичный инструмент
Monitoring	"Система сейчас в норме?"	SLI, dashboards, alerts.
Observability	"Почему система ведет себя именно так?"	Logs, metrics, traces, profiles, events.
Debugging	"Как проверить гипотезу о причине?"	Trace drilldown, LogQL/PromQL, pprof, воспроизведение.
Profiling	"Где тратятся CPU, memory, locks, goroutines?"	`go tool pprof`, runtime trace, runtime metrics.

Monitoring первым говорит: "что-то не так". Observability дает данные, чтобы не гадать. Debugging - это дисциплина проверки гипотез. Profiling подключается, когда проблема похожа на CPU, memory, goroutine leak, contention или latency без явной внешней зависимости.

Сквозной сценарий RateDesk

Во всех уроках держим один сервисный путь:

client
  -> POST /convert
  -> HTTP middleware
  -> usecase.Convert
  -> Redis cache
  -> PostgreSQL rates
  -> external provider or Kafka event
  -> response

И один типовой инцидент: после релиза поменялся cache key prefix, Redis hit ratio упал, PostgreSQL получил резкий рост запросов, /convert стал медленным, часть клиентов начала получать timeout.

Шаг	Сигнал	Что ищем
Alert	SLO/burn rate или p95 latency	Есть ли user impact и насколько большой.
Dashboard	RED/USE metrics	Какая route и какая зависимость деградирует.
Trace	OpenTelemetry spans	Где набирается latency: cache miss, DB query, provider call.
Logs	`request_id`, `trace_id`, `event`, `error.kind`	Конкретные события вокруг запроса.
Profile	pprof/runtime metrics	CPU/memory/goroutine проблемы, если зависимости здоровы.
Runbook	Готовые действия	Rollback, stale cache, prewarm, TTL jitter, escalation.

Что появится в репозитории

К концу модуля студент должен собрать сопровождаемый observability-контур:

internal/observability/
  logger.go
  request_id.go
  metrics.go
  tracing.go

infra/
  prometheus.yml
  otel-collector.yml
  grafana/
    provisioning/
    dashboards/
  alloy/ or fluent-bit/
  alerts/

docs/
  runbooks/
  postmortems/

К каждому артефакту нужна проверка: пример JSON log, PromQL-запрос, trace id, dashboard panel, alert rule, runbook step или pprof-команда. Observability без evidence быстро превращается в "кажется, оно работает".

Prerequisites

Перед модулем полезно уверенно понимать:

HTTP middleware и context.Context;
Clean Architecture boundaries: transport, usecase, repository, adapter;
Docker Compose и сетевые имена сервисов;
базовую модель Prometheus: metric name, labels, samples;
latency percentile и отличие p95/p99 от average;
как сервис ходит в PostgreSQL, Redis, Kafka/provider.

Что будет в модуле

Разберем structured logging в Go через slog, pipeline логов в Loki и ELK/EFK, метрики Prometheus, tracing через OpenTelemetry, OpenTelemetry Collector как единый telemetry router, SLI/SLO и alerting, pprof, локальный stack для разработки и incident workflow.

Общая логика:

instrument code -> collect signals -> build dashboards -> alert on symptoms -> debug incidents -> improve runbooks

Как понять, что освоил

Вы освоили модуль, если можете добавить в Go-сервис request id, structured logs, Prometheus metrics, trace propagation, OTel Collector pipelines для traces/metrics/logs, базовые dashboards, pprof endpoint для закрытого контура и алерт, который ведет к понятному runbook.

Мини-самопроверка:

Симптом	Первый вопрос	Первый сигнал
p95 `/convert` вырос	Это все routes или одна?	RED dashboard и trace slow request.
Данные устарели	API живой, но freshness нарушен?	Domain freshness metric.
5xx выросли	Это системная ошибка или bad input?	Error ratio + `error.kind` в logs/traces.
Memory растет	Это heap, goroutines или cache cardinality?	runtime metrics и heap/goroutine profile.
Kafka lag растет	Consumer медленный или rebalance/poison message?	Lag, handler duration, retry/DLQ metrics.

observabilitylogsmetricstracingalertsSLOproduction