Наблюдаемость начинается не с графиков, а с вопроса о том, сможет ли команда объяснить деградацию раньше, чем пользователь уйдёт.
Логи, метрики, трассировки, оповещения на основе целевых уровней сервиса, операционные инструкции и контуры обратной связи здесь собраны в одну диагностическую платформу.
В архитектурном ревью глава помогает обсуждать качество сигналов, стоимость высокой кардинальности, усталость от алертов и данные, которые реально сокращают время расследования.
Практическая польза главы
Практика проектирования
Проектируйте путь телеметрии: инструментирование, сбор, хранение, корреляция, оповещение и реакция.
Качество решений
Оценивайте стек через качество сигналов, стоимость высокой кардинальности, время расследования и пригодность оповещений для дежурства.
Аргументация на интервью
Показывайте путь от симптома к причине: метрика, трассировка, лог, гипотеза и смягчение последствий.
Формулировка компромиссов
Явно обсуждайте цену детализации, сроков хранения, выборки трассировок и шума оповещений.
Источник
Site Reliability Engineering
Четыре золотых сигнала, показатели и целевые уровни сервиса, а также подходы к наблюдаемости систем в промышленной эксплуатации.
Во время инцидента дежурный решает не задачу «красиво нарисовать систему», а задачу «понять, что сломалось, и за минуты дойти до исправления». Наблюдаемость и проектирование мониторинга — про то, как собрать телеметрию, которая помогает принять это решение, а не просто копит десятки диагностических панелей, на которые никто не смотрит. В этой главе рассматривается через логи, метрики, , , , , , и цикл улучшений после инцидента.
Типичная платформа наблюдаемости
Карта платформы
Как сигналы проходят путь от приложения до расследования инцидента и решения дежурного.
Типовая платформа разделяет сбор, транспорт, хранение и реакцию, чтобы команды могли менять каждый слой независимо.
Сервисы и клиенты
где рождаются сигналы
Сервисы
API, очереди, фоновые задачи
Клиенты
Web, Mobile, пограничные события
Коллекторы
нормализация и обогащение
OpenTelemetry Collector
приём, фильтрация, маршрутизация
Агенты
узлы, контейнеры, соседние агенты
Транспорт
буферизация и защита от всплесков
Очередь/шина
Kafka, Pub/Sub, поток событий
Политики приёма
выборка, срок хранения, лимиты
Хранилища
разные модели чтения
Хранилище метрик
временные ряды и PromQL
Хранилище логов
поиск событий и контекста
Хранилище трассировок
спаны, зависимости, задержки
Аналитика и реакция
решение и обратная связь
Панели
SLO, RED/USE, бизнес-сигналы
Правила оповещения
алерты для дежурного и тикеты
Дежурство
инструкция, действие, разбор
Четыре опоры наблюдаемости
Логи
Что именно произошло в конкретном запросе: событие, контекст и след для расследования.
- в JSON вместо произвольного текста.
- Поля корреляции: идентификатор трассировки, спана, запроса и пользователя.
- Явное разделение : info, warn, error, fatal и бизнес-ошибки.
Метрики
Числовые временные ряды для целевых уровней сервиса, и раннего обнаружения деградаций.
- Базовые модели: и .
- Контроль , особенно для user_id, path и tenant.
- Отдельные рядом с техническими сигналами.
Распределённая трассировка
Путь одного запроса через сервисы, очереди и базы данных — здесь видно, на каком переходе осела задержка.
- через синхронные и асинхронные границы: протокол HTTP, gRPC, Kafka.
- для редких ошибок и запросов с высокой задержкой.
- Связка трассировок, логов и метрик для быстрого поиска .
Оповещения
Правила, которые поднимают команду ночью только тогда, когда отклонение реально стоит пробуждения.
- Оповещения от целевых уровней сервиса и , а не только от CPU/RAM.
- Разделение : будить дежурного, создать задачу или оставить информационный сигнал.
- Каждый ведёт к .
Углубление: логи, метрики, трассировки и оповещения
Логи: от разбора событий к операционной диагностике
Логи отвечают на вопрос про конкретное событие: кто вызвал операцию, что пошло не так, на каком шаге и с каким контекстом. Без этого расследование превращается в гадание по обрывкам строк.
Обязательно
- Единый JSON-формат и стабильная версия схемы записи.
- Корреляция по идентификатору трассировки, спана и для связи с трассировкой.
- Явные : operation, tenant, entity_id, outcome, error_code.
Дизайн решения
- Семплируйте информационные и отладочные события на уровне приёма событий, а не в приложении.
- Персональные данные и секреты маскируются до отправки в конвейер логов.
- Отделяйте от продуктовых логов, потому что у них разные сроки хранения и правила доступа.
Типичные ошибки
- Сырой стек вызовов (stack trace) без контекста операции и входных параметров: видно, где упало, но не видно, на каком запросе.
- Произвольные строки без машинно-разбираемых полей — по такому логу нельзя ни отфильтровать, ни построить агрегат.
- Пишем всё подряд без бюджета на хранение и задержку запросов, и счёт за наблюдаемость начинает обгонять счёт за сам сервис.
Пример структурированного события лога
{
"ts": "2026-02-15T06:00:00Z",
"level": "error",
"service": "checkout-api",
"operation": "CreateOrder",
"trace_id": "6c5f...",
"request_id": "req-1942",
"tenant": "acme",
"error_code": "PAYMENT_PROVIDER_TIMEOUT",
"duration_ms": 1840
}Конвейер телеметрии: от сигнала до реакции
путь сигнала
Сигнал становится решением, только когда проходит весь контур
Конвейер связывает код, коллекторы, хранилища, диагностику и дежурство в один проверяемый процесс.
Встраивание телеметрии
Код, клиенты и инфраструктура публикуют события, метрики и спаны.
Сбор и транспорт
Агенты и коллекторы нормализуют, фильтруют и маршрутизируют поток.
Хранение
Логи, метрики и трассировки попадают в хранилища с разными сроками жизни.
Корреляция
Общие идентификаторы связывают график, трассу и строки лога в гипотезу.
Реакция
Оповещение ведёт к дежурному, смягчению последствий и разбору.
Какие сигналы идут по конвейеру
Логи
события и контекст
Метрики
уровень сервиса и ёмкость
Трассировки
путь запроса
Оповещения
сигнал к действию
Практика
Пример интервью по диагностике инцидентов
Пошаговая диагностика инцидента с применением метрик RED, логов и гипотез.
Оповещения без шума: дизайн правил
5-15 минут
Быстрое расходование бюджета
Быстро поймать критичную недоступность и сократить .
Высокая скорость расходования бюджета ошибок за короткое окно.
1-6 часов
Медленное расходование бюджета
Поймать медленную деградацию качества, пока она не накопилась до полного отказа.
Устойчивое отклонение задержки или доступности от целевого уровня сервиса.
15-60 минут
Бизнес-аномалия
Увидеть до обращения клиентов.
Падение конверсии, всплеск неуспешных платежей или провал ключевого сценария.
Минимальная договорённость для команды: у каждого алерта для дежурного есть владелец, операционная инструкция и задача по итогам разбора. Без этого оповещения быстро превращаются в шум.
Источники
Связанные главы
- Зачем нужны надёжность и инженерия надёжности сервисов - Карта всего раздела инженерии надёжности сервисов: целевые уровни сервиса, инциденты, и безопасный выпуск изменений.
- Интервью по диагностике инцидентов - Где собранная здесь телеметрия проверяется делом: как по логам, метрикам и трассировкам выстроить и отсечь гипотезы во время инцидента.
- The Site Reliability Workbook - Целевые уровни сервиса, показатели уровня сервиса, и реагирование на инциденты в операционной практике.
- Prometheus: The Documentary - Откуда выросли метрики и кардинальность, о которых шла речь выше: история экосистемы Prometheus и мониторинга для облачно-ориентированных систем.
- eBPF: The Documentary - Как eBPF расширяет в сетях, ядре и практиках безопасности.