← [Главная](../README.md)

# 08 — Observability (наблюдаемость)

## Цель

Понять три столпа **observability**: логи, метрики и трейсы. Научиться связывать их с **SLO/SLA**, настраивать осмысленные алерты и не тонуть в шуме данных.

## Предварительно

- [Раздел 07 — Надёжность](../07-nadezhnost/README.md)
- Базовое понимание HTTP-запросов и микросервисной цепочки

## Время

**5–8 часов**

---

## Зачем observability

Без наблюдаемости вы узнаёте о проблеме от пользователей в Twitter. С ней:

- видите деградацию **до** полного outage;
- находите **корень** инцидента за минуты, не часы;
- доказываете выполнение **SLO** перед бизнесом;
- анализируете последствия релиза.

**Monitoring** отвечает: «работает ли?»  
**Observability** отвечает: «почему ведёт себя так?» — даже на новых, непредвиденных сбоях.

---

## Три столпа

| Столп | Вопрос | Пример |
|-------|--------|--------|
| **Logs** | Что произошло в точке времени? | `order_id=abc payment failed` |
| **Metrics** | Как меняются числа во времени? | `http_requests_total{status="500"}` |
| **Traces** | Как запрос прошёл по сервисам? | span: API → payment → DB |

Они **дополняют** друг друга. Метрика «рост 500» → трейс на медленный span → лог с stack trace.

---

## Оглавление раздела

| Страница | Содержание |
|----------|------------|
| [logging.md](logging.md) | Структурированные логи, уровни, correlation ID |
| [metriki-i-slo.md](metriki-i-slo.md) | RED/USE, SLI, SLO, error budget |
| [tracing-i-alerty.md](tracing-i-alerty.md) | Distributed tracing, алерты, on-call |

---

## Золотые сигналы (Google SRE)

Для большинства сервисов достаточно четырёх:

1. **Latency** — время ответа (p50, p95, p99).
2. **Traffic** — RPS, сообщений в секунду.
3. **Errors** — доля неуспешных запросов.
4. **Saturation** — насколько «полон» ресурс (CPU, очередь, connection pool).

Не собирайте «всё подряд» — начните с golden signals на критичных путях.

---

## Correlation ID — склейка мира

Один идентификатор на весь путь пользователя:

```text
X-Request-ID: 7f3c2a1b-...
  → API gateway логирует
  → Order service логирует тот же ID
  → Payment client передаёт в заголовке
```

Без correlation ID поиск по логам в 10 сервисах — кошмар.

---

## Стек (учебный, без привязки к вендору)

| Слой | Типичные инструменты |
|------|---------------------|
| Сбор логов | Fluent Bit, Vector → Loki / OpenSearch |
| Метрики | Prometheus + Grafana |
| Трейсы | OpenTelemetry → Jaeger / Tempo |
| Алерты | Alertmanager, Grafana OnCall |
| Дашборды | Grafana |

В курсе важны **концепции**; в облаке те же идеи в CloudWatch, Datadog, Yandex Monitoring и т.д.

---

## Практика на 20 минут

Для endpoint `POST /orders`:

1. Запишите 3 метрики, которые бы завели.
2. Запишите 2 поля обязательного лог-сообщения при ошибке.
3. Сформулируйте один SLO в виде «99.9% запросов быстрее X мс».

---

## Самопроверка

1. Чем observability отличается от классического monitoring?
2. Назовите три столпа observability.
3. Что такое correlation ID и зачем он нужен?
4. Перечислите четыре «золотых сигнала».

---

## Дальше

→ [Логирование](logging.md)  
← [Раздел 07](../07-nadezhnost/README.md)