System Design
Observability
Три столпа Observability
**Observability vs Monitoring** **Monitoring:** заранее определяем что отслеживать → "CPU > 80%" → alert **Observability:** можем задать ЛЮБОЙ вопрос о системе → "Почему запросы от users в Germany медленные по вторникам?" Observability = способность понять internal state по external outputs
**Связь между pillars:**
Все три связаны через **correlation IDs** (trace_id, request_id)
Что вы узнали о Три столпа Observability?
Logging
**Structured Logging - основа observability** ❌ Плохо: `console.log('User login failed for user123')` ✅ Хорошо:
Преимущества: - Можно искать по полям - Можно агрегировать - Машиночитаемый формат
**Log Levels:** | Level | Когда использовать
| **TRACE** | Детальный debug | Function entry/exit | | **DEBUG** | Development debug | Variable values | | **INFO** | Нормальная работа | Request processed | | **WARN** | Потенциальная проблема | Retry attempt | | **ERROR** | Ошибка операции | Failed to save | | **FATAL** | Система падает | Cannot connect to DB |
Что вы узнали о Logging?
Metrics
**Metrics - числовые измерения системы** Типы метрик: 1. **Counter** - монотонно растёт (requests_total) 2. **Gauge** - текущее значение (cpu_usage, active_connections) 3. **Histogram** - распределение (request_duration) 4. **Summary** - percentiles на клиенте
**Prometheus - стандарт метрик** **Pull model:** - Prometheus периодически (каждые 15s) делает HTTP GET - Сервисы экспортируют `/metrics` endpoint **Метрики format:**
**RED Method - ключевые метрики для сервисов:** | Metric | Что измеряет
| **R**ate | Requests per second | `rate(http_requests_total[5m])` | | **E**rrors | Error rate | `rate(http_errors_total[5m])` | | **D**uration | Latency (p50, p99) | `histogram_quantile(0.99, ...)` | **USE Method - для ресурсов (CPU, Memory, Disk):** - **U**tilization - % времени занят - **S**aturation - очередь ожидания - **E**rrors - количество ошибок
Что вы узнали о Metrics?
Distributed Tracing
**Tracing - путь запроса через систему** В микросервисах один user request проходит через 5-20 сервисов. Как понять где latency? **Термины:** - **Trace** - полный путь одного запроса - **Span** - одна операция (вызов сервиса, DB query) - **Context** - trace_id + span_id, передаётся между сервисами
**Context Propagation:** Как trace_id передаётся между сервисами:
**W3C Trace Context** - стандарт: `traceparent: 00-{trace-id}-{span-id}-{flags}`
**Sampling - нельзя хранить 100% traces:** | Strategy
| **Head-based** | Решение на входе (random 1%) | | **Tail-based** | Решение после завершения (все errors, slow) | | **Adaptive** | Динамически по нагрузке | Tail-based лучше для debugging (сохраняет problematic traces), но требует буфер в collector.
Что вы узнали о Distributed Tracing?
Alerting и SLO
**SLI, SLO, SLA - язык надёжности** **SLI (Service Level Indicator)** - метрика - "99.5% requests complete in <200ms" - "0.1% error rate" **SLO (Service Level Objective)** - цель - "Availability должен быть ≥99.9%" **SLA (Service Level Agreement)** - контракт - "Если SLO нарушен → refund клиенту"
**Alerting Best Practices:** ❌ **Alert fatigue** - слишком много alerts = игнорируют ✅ **Actionable alerts:** - Каждый alert требует действия - Нет alerts на "интересную информацию" - Severity levels: critical (page), warning (ticket), info (log) **Multi-window alerts:**
Short window (5m) catches spikes Long window (1h) filters noise
Что вы узнали о Alerting и SLO?