Оглавление

  1. Концепция Observability
  2. Логирование (Logging)
  3. Трейсинг (Tracing)
  4. Метрики (Metrics)
  5. Алертинг и уровни обслуживания (SLA, SLO, SLI)
  6. Профайлинг и диагностика (pprof, Runtime Trace)
  7. Культура SRE и эксплуатация

1. Концепция Observability

Наблюдаемость (Observability) — это свойство системы, позволяющее судить о её внутреннем состоянии на основе внешних данных (телеметрии).

  • Философия: Фича считается завершенной только после написания тестов, документации и настройки графиков мониторинга.
  • Мониторинг vs Наблюдаемость: Мониторинг отвечает на вопрос «Работает ли сервис?» (известные вопросы), наблюдаемость позволяет понять «Почему система ведет себя так?» (новые вопросы).

Три столпа наблюдаемости

  1. Метрики (Metrics): Числовые агрегаты. Отвечают на вопрос «Что происходит?».
  2. Логи (Logs): Записи событий. Отвечают на вопрос «Почему это произошло?».
  3. Трейсы (Traces): Путь запроса. Отвечают на вопрос «Где именно это произошло?».

Стандарт: Единый стандарт сбора телеметрии — OpenTelemetry (OTel) (объединение OpenTracing и OpenCensus).

2. Логирование (Logging)

Лог — это неизменяемая, упорядоченная по времени запись о событии.

Уровни логирования

  • DEBUG/TRACE: Детальная отладка.
  • INFO: Штатная работа.
  • WARN: Потенциальные проблемы.
  • ERROR: Ошибки в работе компонента.
  • FATAL/CRITICAL: Крах приложения (в Go log.Fatal вызывает os.Exit(1)).

Структурированное логирование и ZAP

Современный подход — структурированный лог (JSON). Это массив пар «ключ-значение», удобный для машинной обработки.

  • Стандартные средства Go: Пакет log (неструктурированный) и новый slog (структурированный, Go 1.21+).
  • Библиотека ZAP (Uber): Высокопроизводительный стандарт.
    • Logger: Строго типизированный (zap.String), максимальная скорость.
    • SugaredLogger: Удобный API (Infow, Infof), использует интерфейсы.
    • Пресеты: development (текст, stacktrace), production (JSON, оптимизация).

Инфраструктура сбора логов

Согласно The Twelve-Factor App, приложение пишет логи в stdout. Pipeline в OXXX:

  1. Приложение (stdout) → 2. Агент file.d (сбор и обогащение метаданными k8s) → 3. Kafka (буфер) → 4. Ingester/Logstash → 5. Graylog (LTS-хранилище и UI для поиска).

3. Трейсинг (Tracing)

Трейсинг — отслеживание пути запроса через распределенную систему для поиска узких мест (bottlenecks).

Ключевые понятия: Trace и Span

  • Trace (Трейс): Полный путь запроса. Имеет уникальный Trace ID.
  • Span (Спан): Единица работы (вызов функции, запрос к БД).
    • Имеет Span ID и Parent Span ID.
    • Атрибуты: время выполнения, теги (error=true, http.status), логи (события).
  • Семплинг (Sampling): Процент сохраняемых трейсов (100% — слишком дорого).

Реализация в Go

  • Используется context.Context для проброса Trace ID.
  • Функция startSpanFromContext связывает дочерний спан с родительским.
  • Инструмент: Jaeger (Collector, DB, UI). Визуализация в виде диаграммы Ганта.

4. Метрики (Metrics)

Метрики — это агрегированные числовые показатели.

Категории метрик

  • Технические: CPU, RAM, Latency.
  • Продуктовые: Кол-во заказов, регистраций.
  • UX/UI: Время загрузки страниц, клики.

Важность перцентилей

Среднее значение (mean) обманчиво. N-й перцентиль (p95, p99) показывает, что N% запросов выполнились быстрее этого времени, позволяя отсечь редкие выбросы и видеть реальный опыт большинства.

Методологии (LTES, RED, USE)

  1. The Four Golden Signals (LTES): Latency (Задержка), Traffic (Трафик), Errors (Ошибки), Saturation (Насыщенность).
  2. RED (для сервисов): Rate (Частота), Errors (Ошибки), Duration (Длительность).
  3. USE (для ресурсов): Utilization (Утилизация), Saturation (Насыщенность/Очередь), Errors (Ошибки).

Модели сбора: Push vs Pull

  • Push model: Приложение само отправляет данные.
  • Pull model: Сервер (Prometheus) опрашивает приложение по эндпоинту /metrics. Легче определить “живость” приложения.

Prometheus: типы метрик и кардинальность

  1. Counter (Счетчик): Только растет. Используется с функцией rate().
  2. Gauge (Шкала): Может расти и уменьшаться (температура, кол-во соединений).
  3. Histogram (Гистограмма): Распределение по “корзинам” (buckets). Квантили вычисляются на сервере.
  4. Summary (Сводка): Квантили вычисляются на клиенте.

Взрыв по лейблам (High Cardinality): Использование уникальных значений (например, user_id) в лейблах порождает миллионы временных рядов, перегружая хранилище.

5. Алертинг и уровни обслуживания (SLA, SLO, SLI)

  • SLI (Indicator): Конкретная метрика (например, % успешных запросов).
  • SLO (Objective): Внутренняя цель (например, 99.9% ответов за <100мс).
  • SLA (Agreement): Юридическое соглашение с клиентом (внешнее).
  • Доступность: Таблица “девяток” (99.99% — это ~52 мин простоя в год).
  • Инструменты: Alertmanager, PagerDuty (звонки дежурным).

6. Профайлинг и диагностика (pprof, Runtime Trace)

Когда метрики говорят «ЧТО», а трейсы «ГДЕ», профайлинг помогает понять «КАК» оптимизировать код.

pprof (Профайлинг)

  • Типы: CPU, Memory (Heap), Concurrency (блокировки).
  • Визуализация: Flamegraph (ширина блока — время ЦП), Memory graph.

Runtime Trace (go tool trace)

Детальная визуализация работы Go Runtime:

  • Жизненный цикл горутин.
  • Работа планировщика (на каком ядре какая горутина работала).
  • Threads и активность Heap.

7. Культура SRE и эксплуатация

SRE (Site Reliability Engineering) — применение подходов разработки к эксплуатации.

  • Белый ящик: Мониторинг внутренних метрик.
  • Черный ящик: Проверка системы снаружи (как пользователь).
  • Инцидент: Событие не по плану.
  • Постмортем (Postmortem): Письменный разбор инцидента. Цель — не найти виноватого, а не допустить повторения.
  • RCA (Root Cause Analysis): Поиск первопричины через анализ всех слоев телеметрии.

Метрики, логи и трейсы работают в синергии: Метрики сигнализируют о проблеме, трейсы локализуют место, а логи объясняют конкретную причину.