Архитектура системы наблюдаемости: метрики, логи и трассировки

Система наблюдаемости строится на трех типах телеметрии: метрики показывают масштаб и время изменения, логи фиксируют детали событий, трассировки раскрывают путь конкретного запроса между сервисами. Связанный контур позволяет перейти от алерта по latency или error rate к проблемному span, записи об ошибке и инфраструктурной причине.

Метрик недостаточно, когда деградация возникает на стыке приложения, CPU, памяти, storage, сети, очереди и GPU. Практичная архитектура включает инструментацию приложений и инфраструктуры, сбор через агенты или OpenTelemetry Collector, отдельные хранилища для metrics, logs и traces, Grafana для анализа, Jaeger для просмотра трасс и алертинг по пользовательским симптомам и состоянию telemetry pipeline.

Конкретный стек зависит от числа сервисов, скорости ingest, требований к retention, допустимой задержки поиска, бюджета и правил безопасности. Базовые правила остаются одинаковыми: договориться об атрибутах ресурсов, прокидывать trace_id в логи, ограничивать cardinality метрик и контролировать работу самого контура телеметрии.

Как устроена система наблюдаемости: краткий ответ

Три вопроса, на которые должна отвечать observability-система

Рабочая система наблюдаемости отвечает на три вопроса:

• Что произошло? Метрики показывают рост ошибок, снижение throughput, увеличение задержки или насыщение ресурса.
• Где произошло? Трассировки указывают сервис, операцию, зависимость и конкретный участок пути запроса.
• Почему произошло? Логи, атрибуты span-ов и инфраструктурные показатели подтверждают timeout, ошибку подключения, нехватку ресурса, ошибку приложения или изменение конфигурации.

Например, p95 latency API выросла с 180 мс до 2,4 с. Метрика очерчивает временное окно и затронутый endpoint. Trace показывает, что 1,9 с занимает обращение к storage. Лог с тем же trace_id фиксирует timeout драйвера, а метрики storage подтверждают рост задержки I/O. У команды появляется проверяемая причина, а не предположение по одному графику.

Почему данные нужно анализировать вместе

Каждый источник телеметрии имеет собственную форму и назначение. Time series удобны для агрегации и алертов, события содержат подробности, дерево span-ов показывает зависимость операций. Раздельное хранение без общих атрибутов заставляет вручную сопоставлять время, имя сервиса, pod и запрос. Во время инцидента это увеличивает время диагностики.

Единый контекст связывает service.name, deployment.environment, cluster, namespace, pod, instance, trace_id и span_id. После такой настройки инженер открывает график, выбирает representative trace, находит связанные логи и сверяет их с состоянием CPU, памяти, сети или хранилища.

Цель observability состоит в доказательстве первопричины. Алерт сообщает о симптоме, а связанная телеметрия сокращает путь до подтвержденной причины.

Роль метрик, логов и трассировок в observability

Метрики: количественная картина состояния системы

Метрика представляет значение во времени. Для приложения обычно собирают request rate, latency, error rate, размер очереди, число активных запросов и saturation. Для инфраструктуры нужны CPU, memory pressure, filesystem usage, I/O latency, network errors, bandwidth, состояние базы данных, очередей и Kubernetes control plane.

Метрики подходят для SLI, SLO и алертов. Например, алерт можно строить на доле HTTP 5xx выше 2% за 10 минут, p95 latency выше согласованного порога или заполнении диска свыше 85%. Порог должен учитывать базовую линию конкретной системы, а не абстрактную норму.

Метрики плохо переносят высокую cardinality. Нельзя записывать user_id, request_id, trace_id, уникальный URL с параметрами или случайный идентификатор в labels Prometheus. Каждая новая комбинация labels создает series, увеличивает ingest, расход памяти и время выполнения запросов. Подробный контекст следует оставлять в логах и span-ах.

Логи: детали событий и ошибок

Лог содержит запись о конкретном событии: ошибке валидации, timeout, изменении конфигурации, результате операции, отказе зависимости или исключении приложения. Для поиска и корреляции используйте structured logging, например JSON с единым набором полей.

timestamp=2026-09-07T10:15:21Z
level=error
service.name=payment-api
deployment.environment=production
trace_id=4f8a21
span_id=8d92bc
operation=POST /payments
error.code=upstream_timeout
dependency=ledger-api

Минимальный набор включает timestamp, level, service.name, environment, версию сервиса, trace_id, span_id, операцию, код ошибки и безопасный технический контекст. Stack trace, текст ошибки и сведения о конфигурации помогают подтвердить гипотезу, которую сформировали по метрике и трассе.

Логи быстро накапливаются. Установите уровни severity, правила редактирования полей, сроки хранения и доступы. Пароли, токены, приватные ключи, cookie, полные payload с персональными данными и платежные реквизиты не должны попадать в telemetry.

Трассировки: путь запроса через распределенную систему

Distributed tracing описывает выполнение запроса как trace, состоящий из span-ов. Trace охватывает полный путь операции. Span описывает отдельный участок: обработку HTTP-запроса, вызов другого сервиса, SQL-запрос, чтение из storage, публикацию в очередь или вызов внешнего API.

У span есть trace_id, span_id, ссылка на родительский span, время начала, duration, status и attributes. По дереву parent-child видно, какая операция вызвала следующую и где появилась задержка. Jaeger подходит для поиска traces по сервису, операции, длительности, статусу и атрибутам.

Трасса отвечает на вопрос о пути исполнения. Она не заменяет мониторинг ресурсов. Медленный span базы данных может быть следствием блокировки, сетевой потери пакетов, исчерпания connection pool или нехватки IOPS. Для проверки нужны логи и инфраструктурные метрики.

Почему одних метрик недостаточно для диагностики

Симптом и причина находятся в разных слоях

Высокая загрузка CPU не доказывает, что CPU стал первопричиной инцидента. Низкая загрузка CPU не исключает проблему. Сервис может ждать ответ upstream-зависимости, блокировку в базе данных, чтение из storage или свободный worker в очереди.

Похожая ситуация возникает с GPU. Низкий GPU utilization при накопленной очереди запросов может означать ожидание CPU preprocessing, tokenization, доступа к данным, планирования или передачи по сети. Оценка только одного дорогого ресурса приводит к преждевременной закупке вычислений и не устраняет узкое место.

Средняя скорость storage тоже способна скрыть проблему. Среднее значение может оставаться приемлемым, пока часть запросов получает длинные паузы I/O. Трасса покажет длительность конкретного обращения, а логи могут зафиксировать timeout или повторную попытку. Практический разбор поиска bottleneck в CPU, памяти, сети, storage и приложении есть в статье как найти узкое место в системе.

Полный путь workload: CPU, данные, ускоритель и приложение

Для AI inference полезно наблюдать цепочку целиком: получение данных - CPU preprocessing или tokenization - передача на GPU - inference - CPU post-processing - ответ приложения. Для каждого участка нужны свои сигналы.

Та же логика работает для веб-приложения без ускорителей: ingress, API, сервис авторизации, база данных, кэш, очередь и worker образуют единый путь. Наблюдение за одним контейнером или одним узлом дает только фрагмент картины.

Как доказать первопричину, а не просто найти корреляцию

Совпадение двух графиков по времени формирует гипотезу. Для подтверждения нужны несколько независимых сигналов: единое временное окно, рост duration конкретного span-а, связанная запись лога, симптом на инфраструктурном уровне и повторяемость после контролируемого действия.

1. Зафиксируйте исходные показатели: latency, error rate, throughput, saturation и версию сервиса.
2. Найдите traces до и во время деградации, сравните waterfall операций.
3. Проверьте логи по trace_id и span_id.
4. Сверьте метрики зависимостей: storage latency, сетевые ошибки, memory pressure, queue depth или scheduling.
5. Внесите контролируемое изменение в тестовом контуре или повторите запрос после исправления.

Такой порядок снижает риск менять работающий компонент по ложной корреляции.

Архитектура системы наблюдаемости: от источников до анализа

Контур телеметрии состоит из нескольких уровней: instrumentation и exporters в приложениях и инфраструктуре, агенты или Collectors, обработка и маршрутизация, backends для каждого типа данных, интерфейсы анализа и алертинг. На каждом уровне возможна потеря, задержка или искажение данных, поэтому архитектуру нужно наблюдать так же внимательно, как бизнес-сервисы.

Источники телеметрии в приложении и инфраструктуре

Начните с критичных пользовательских путей и их зависимостей. В приложениях подключите HTTP, RPC, базы данных, очереди, кэш, фоновые задачи и внешние API. В инфраструктуре соберите сигналы с хостов, виртуальных машин, контейнеров, Kubernetes nodes, pods, ingress, control plane, persistent volumes, storage, networking, CPU, memory и GPU.

Автоматическая инструментация быстро покрывает типовые библиотеки и протоколы. Ручная инструментация нужна на бизнес-операциях, критичных этапах обработки, границах очередей и участках с дорогими вычислениями. Имя span-а должно описывать операцию, например payment.authorize или storage.read_object, а не случайный фрагмент кода.

Сбор и обработка через OpenTelemetry Collector

OpenTelemetry Collector отделяет приложения от конкретных хранилищ. Он принимает телеметрию через receivers, изменяет поток processors и отправляет его exporters. Такая схема упрощает смену backend, централизует фильтрацию и дает единое место для правил enrichment.

Collector обычно добавляет resource attributes, фильтрует лишние поля, объединяет записи в batch, применяет sampling, ограничивает нагрузку и направляет metrics, logs и traces в разные системы. Например, traces могут уходить в Jaeger, метрики в Prometheus-совместимый backend, а логи в отдельное хранилище с поиском по полям.

Каждый Collector добавляет точку отказа. Контролируйте его health check, входящий и исходящий поток, queue size, dropped spans, failed exports, retry count и задержку доставки. Пропавшие метрики или сломанный exporter часто не вызывают явного сбоя приложения, поэтому проблему легко заметить поздно.

Специализированные backends и интерфейсы

Prometheus подходит для хранения и запроса метрик, а также для подготовки алертов. Grafana собирает дашборды из нескольких источников и помогает перейти от графика к связанным данным. Jaeger дает интерфейс для поиска и анализа трасс. Для логов нужен backend, который поддерживает полнотекстовый или label-based поиск, сроки хранения и разграничение доступа.

Один backend для всех сигналов иногда упрощает старт, но его возможности могут ограничить поиск, retention или стоимость при росте объема. Сравнивайте решения по модели хранения, query latency, ingest rate, репликации, резервному копированию, правилам доступа и операционной сложности.

Надежность самого telemetry pipeline

Проверяйте доставку данных на каждом переходе: exporter приложения, агент, Collector, сеть, очередь, backend и интерфейс анализа. Для этого нужны метрики scrape failures, dropped data, export errors, queue saturation, ingest latency и доступности хранилищ.

Добавьте тестовый сигнал. Например, раз в час отправляйте synthetic trace и событие с известным correlation ID, затем проверяйте их появление в backend. Такой тест выявляет разрыв pipeline раньше, чем телеметрия потребуется для расследования production-инцидента.

Как связать метрики, логи и трассировки

Общий контекст ресурса и сервиса

Зафиксируйте обязательные атрибуты: service.name, service.version, deployment.environment, cluster, namespace, pod, node, region и instance. Состав полей зависит от платформы, но их семантика должна оставаться общей для всех команд.

В labels метрик оставляйте стабильные значения с ограниченным числом комбинаций: сервис, окружение, namespace, код ответа, нормализованный endpoint. Подробные атрибуты запроса, идентификаторы пользователей и параметры операций размещайте в span-ах или логах с учетом политики безопасности.

trace_id, span_id и correlation ID в логах

Прокидывайте trace_id и span_id в structured logs на входе и выходе каждого сервиса. Trace_id объединяет события одной технической операции. Span_id указывает конкретный шаг внутри этой операции. По этим полям можно открыть лог из трассы или найти трассу после ошибки в логе.

Бизнесовый correlation ID решает другую задачу. Например, один заказ может создавать несколько независимых технических traces: оформление, резервирование, списание, уведомление. Correlation ID связывает бизнес-процесс, а trace_id связывает одно выполнение запроса. Для критичных workflow полезно хранить оба идентификатора, если правила доступа допускают такое поле.

Не записывайте в correlation ID номер паспорта, e-mail, телефон, токен или другой чувствительный идентификатор. При необходимости используйте внутренний псевдоним или хеш с понятным сроком хранения.

Метрики, exemplars и переход к трассе

Exemplar связывает значение метрики с примером trace. Например, точка на графике p95 latency может содержать trace_id медленного запроса. Инженер открывает trace прямо из временного окна деградации и быстрее находит проблемный span.

Когда exemplars недоступны, используйте одинаковые service attributes, endpoint, status code, версию приложения и временное окно. Выберите трассы с высокой duration или ошибкой, затем сравните их с нормальными запросами. Этот путь медленнее, но сохраняет работоспособность корреляции.

Единые правила времени, имен и семантики

Синхронизируйте время на узлах через надежный источник времени. Разница даже в несколько секунд затрудняет сопоставление логов, span-ов и метрик; большая разница искажает порядок операций в trace.

Согласуйте единицы измерения и имена. Latency храните в секундах или миллисекундах по общему правилу, размер памяти указывайте явно, endpoint нормализуйте до шаблона /orders/{id}, а статус ошибки задавайте ограниченным набором значений. Поля вида failed, error, timeout и произвольный текст в одном атрибуте усложняют поиск и алерты.

Практический стек observability для разных сценариев

Минимальная конфигурация для одного кластера или небольшого парка

Для небольшого production-контура или лаборатории достаточно базовой схемы: Prometheus собирает host, container, Kubernetes и application metrics; Grafana показывает дашборды и алерты; OpenTelemetry Collector принимает traces и логи; Jaeger хранит и показывает traces; отдельный backend принимает structured logs.

Сразу соберите доступность, latency, error rate, saturation, дисковое пространство, I/O latency, memory pressure и сетевые ошибки. Трассировки начните с критичных API, базы данных, очереди и внешних вызовов. Для логов задайте обязательные поля и redaction. Полное покрытие всех сервисов на первом шаге редко дает пользу, соразмерную нагрузке на команду.

Подробное сравнение Prometheus, Grafana, OpenTelemetry Collector, Loki, Tempo, Thanos, VictoriaMetrics и других компонентов приведено в материале как выбрать стек мониторинга.

Архитектура для Kubernetes и микросервисов

В Kubernetes источники меняются после deployment, autoscaling и пересоздания pod. Нужны resource attributes для cluster, namespace, workload, pod, node и версии образа. Без этих полей сложно отличить регрессию конкретного release от проблемы узла или общей деградации зависимости.

Собирайте сигналы с nodes, pods, workloads, ingress, service mesh или gateway, control plane, persistent volumes и сетевого слоя. Применяйте sampling traces, контролируйте cardinality и настраивайте namespace-aware доступы. Для Kubernetes-аварий пригодится пошаговая статья диагностика pods и узлов через метрики.

Гетерогенные и AI-нагрузки

Гетерогенная нагрузка зависит от совместной работы CPU, GPU, памяти, storage и networking. GPU utilization отдельно не показывает эффективность inference. Ускоритель может простаивать из-за медленного доступа к model artifacts, нехватки CPU для preprocessing, очереди на планировщике или задержки сети.

На дашборде такой системы нужны длина очереди, время ожидания, CPU utilization, memory pressure, storage latency, network throughput, GPU utilization, память GPU, duration inference и итоговая latency приложения. В трассе выделяйте spans для preprocessing, transfer, inference, post-processing и записи результата. Логи должны фиксировать ошибки планирования, загрузки модели и внешних зависимостей без чувствительных payload.

Когда нужен managed-сервис, а когда self-hosted стек

Self-hosted стек дает полный контроль над размещением данных, конфигурацией retention, доступом и стоимостью инфраструктуры. Он требует времени на обновления, резервное копирование, масштабирование, мониторинг backends и устранение отказов. Managed-сервис уменьшает операционную нагрузку, но вводит ограничения по размещению данных, интеграциям, тарифам и контролю над платформой.

Выбор опирается на SLA, security policy, допустимую потерю телеметрии, объем ingest, компетенции команды и бюджет эксплуатации. Для тестового размещения self-hosted компонентов можно использовать облачную инфраструктуру Timeweb Cloud, где доступны серверы, Kubernetes, базы данных и хранилища. Перед переносом production-телеметрии проверьте требования к регионам, доступам, резервным копиям и срокам хранения.

Хранилище, retention и sampling: как оценить объем данных

Оценка Prometheus по фактической скорости генерации

Универсальной формулы для расчета диска Prometheus нет. Объем зависит от числа scrape targets, интервала scrape, количества series, labels, типов метрик, сжатия и retention. Оценка вида фиксированное число гигабайт на сервис дает слишком грубый результат.

Практический метод выглядит так:

1. Добавьте в prometheus.yml все или часть реальных targets.
2. Запустите scrape с планируемым интервалом, например 15, 30 или 60 секунд.
3. Измерьте фактическую скорость генерации данных в KB/s.
4. Покажите скорость и число series в Grafana, наблюдайте их несколько дней, включая период нагрузки.
5. Экстраполируйте результат на остальные targets и нужный retention.
6. Добавьте около 20% запаса на straddling blocks.

Расчеты удобно свести в таблицу: target, число series, scrape interval, ingest rate, горячий период, архив, коэффициент репликации и запас. Повторяйте измерение после появления новых exporters, label или workload.

Retention и уровни хранения для логов и трасс

Метрики обычно хранят дольше, поскольку агрегированная история полезна для трендов, capacity planning и SLO. Логи и трассы стоят дороже из-за объема и детализации. Разделите горячий период с быстрым поиском и более длительное хранение с ограниченными возможностями запроса.

Для traces используйте head sampling или tail sampling. Сохраняйте ошибки, медленные запросы, критичные бизнес-операции и репрезентативную долю успешных запросов. Для логов задайте разные сроки хранения по severity, сервису и требованиям аудита. Ошибки критичного API могут храниться дольше обычных debug-записей.

На время расследования можно временно поднять sampling или продлить retention для затронутого сервиса. Зафиксируйте срок действия такого изменения, иначе аварийный режим превратится в постоянный рост расходов.

Баланс детализации, стоимости и скорости поиска

Оценивайте не только емкость диска. На итоговую стоимость влияют ingest rate, репликация, резервные копии, сетевая передача, query latency и вычислительные ресурсы backend. Медленный поиск в горячем периоде снижает ценность собранной телеметрии во время инцидента.

Для каждого сигнала определите минимально полезную детализацию. Метрика request rate обычно не требует user_id. Trace ошибки нуждается в операции, сервисе, зависимости и коде статуса. Лог может содержать технические параметры ошибки, но не секреты и полный пользовательский payload.

Пошаговая диагностика инцидента по единому контуру

Шаг 1. Зафиксировать симптом по метрикам

Сначала определите границы инцидента. Проверьте latency, error rate, throughput, saturation и распределение по endpoint, версии, namespace, instance или региону. Сопоставьте начало деградации с deployment, изменением конфигурации, ростом трафика, отказом зависимости или заполнением ресурса.

Единичный пик и устойчивая деградация требуют разных действий. Для алерта полезны окна наблюдения, например 5 и 30 минут, а также сравнение с обычным профилем этого же дня недели или периода нагрузки.

Шаг 2. Найти проблемный участок в трассировке

Выберите traces с ошибкой, высокой duration или совпадающим endpoint. Изучите waterfall span-ов, parent-child связи, retries, timeouts и external calls. Сравните нормальную трассу с проблемной, чтобы увидеть конкретную операцию, которая изменила длительность или статус.

Если root span длится 3 секунды, а 2,5 секунды занимает span postgres.query, проверяйте базу данных и соединение с ней. Если сервис проводит 2 секунды без дочерних span-ов, ищите синхронное вычисление, блокировку, GC pause или пробел в инструментации.

Шаг 3. Подтвердить причину логами и инфраструктурными сигналами

Найдите записи по trace_id и span_id. Ищите stack trace, timeout, отказ подключения, нехватку места, ошибку драйвера, сбой аутентификации или лимит внешнего API. Затем проверьте ресурс на полном пути workload: CPU preprocessing, memory pressure, storage latency, network errors, queue depth, scheduling и GPU metrics.

Например, trace указывает на задержку чтения из object storage, лог показывает повторные попытки, а метрики сети фиксируют рост retransmits на узле. Такая комбинация сильнее подтверждает сетевую причину, чем рост общего времени API сам по себе.

Шаг 4. Проверить исправление и обновить контекст

Исчезновение алерта не завершает расследование. Сравните метрики до и после изменения, повторите проблемный запрос или нагрузочный сценарий, проверьте новые traces и связанные логи. Убедитесь, что ошибка не переместилась в другой сервис и latency не выросла на соседнем участке.

После инцидента зафиксируйте первопричину, временную шкалу, затронутые компоненты, пробелы телеметрии и действие для предотвращения повтора. Добавьте metric, span или поле лога, если без него поиск занял лишнее время.

Как выбрать архитектуру под масштаб и задачи эксплуатации

Небольшая инфраструктура или лабораторный контур

Начните с ключевых метрик, structured logs и трассировок критичных запросов. Один Collector и простой набор backends снижают порог поддержки. Ограничьте retention и sampling, но сразу используйте единые service attributes, trace_id и правила именования.

Проверяйте конфигурацию на тестовом контуре. Запустите контролируемый timeout, ограничьте CPU или создайте задержку storage, затем пройдите путь от алерта к trace и логу. Такая проверка показывает практическую ценность раньше, чем случится реальная авария.

Production-кластер с микросервисами

При росте числа сервисов нужны отказоустойчивость Collectors, разделение ingest и storage, контроль cardinality, резервирование критичных backends, доступы по namespace и алерты по pipeline. Определите SLO для observability-платформы: допустимую задержку доставки, долю потерянных данных, время доступности поиска и срок восстановления.

Часть телеметрии можно собирать локально на node, часть отправлять через gateway Collector. Выбор зависит от сетевой топологии, числа pod, требований к буферизации и правил маршрутизации. Фиксируйте лимиты памяти и очередей, чтобы всплеск телеметрии не повлиял на рабочие нагрузки.

Несколько кластеров, регионов или команд

Несколько кластеров требуют решения о централизованном или федеративном сборе. Централизованная схема упрощает общий поиск и корреляцию. Локальные backends снижают межрегиональный трафик и помогают соблюдать требования к размещению данных. Часто подходит комбинированный вариант с локальным буфером и централизованным долгим хранением.

Согласуйте схему атрибутов, маршрутизацию по командам и регионам, правила доступа и стоимость передачи. Для сложных распределенных систем полезен материал об архитектуре высоконагруженных систем, где разобраны мониторинг, отказоустойчивость и поиск узких мест.

Лучшие практики observability и типичные ошибки

Сбор всех данных без приоритизации

Максимальный объем телеметрии увеличивает стоимость хранения, шум и время поиска. Начните с критичных пользовательских путей, зависимостей, SLI и SLO. Новые метрики, логи и spans добавляйте после измерения их пользы в диагностике.

Каждый сигнал должен иметь ответ на два вопроса: какое решение он помогает принять и кто реагирует на его изменение. Если ответа нет, сигнал часто становится лишним расходом.

Высокая cardinality и неуправляемые labels

Не добавляйте в labels метрик user_id, request_id, trace_id, хеш сессии, полный путь с динамическими параметрами или текст ошибки. Нормализуйте endpoint, ограничивайте набор status code и контролируйте новые labels в code review. Детальный контекст переносите в traces и logs.

Следите за числом active series и скоростью их роста. Резкий рост после deployment часто связан с новым label, изменением имени endpoint или exporter, который публикует уникальные значения.

Отсутствие контроля за pipeline телеметрии

Сервис может выглядеть здоровым, хотя Collector перестал экспортировать spans или Prometheus не может scrape часть targets. Мониторьте scrape failures, dropped data, export errors, queue saturation, задержку доставки и доступность backend. Проверяйте тестовый сигнал и переход от метрики к trace и логу регулярно.

Полный список архитектурных ошибок, включая шумные алерты, неправильную retention и разрыв между источниками телеметрии, собран в статье типовые ошибки при разработке систем мониторинга.

Логи и трассы без политики безопасности

Определите правила redaction, шифрования, контроля доступа, retention и аудита до подключения массового сбора логов. Запретите запись паролей, токенов, ключей, cookie, полных payload с чувствительными данными и персональных идентификаторов без обоснованной необходимости.

Проверяйте telemetry при code review и тестировании. Секрет может попасть в span attribute, сообщение исключения, HTTP header или debug-лог даже при корректной настройке основного logger.

План запуска системы наблюдаемости

Шаг 1. Определить критичные пользовательские и инфраструктурные пути

Составьте список сервисов, операций, зависимостей и SLO. Для каждого пути определите ожидаемый уровень доступности, latency, error rate, допустимое насыщение ресурсов и последствия потери данных. Начните с операций, остановка которых заметна пользователям или бизнес-процессу.

Шаг 2. Подключить метрики и базовые алерты

Добавьте application и infrastructure metrics, зарегистрируйте Prometheus targets, соберите дашборды Grafana и настройте алерты по симптомам. Наблюдайте фактическую скорость генерации данных несколько дней, затем выберите retention и емкость storage с запасом около 20% для straddling blocks.

Проверьте алерты вручную: создайте контролируемый рост latency, ошибку зависимости или нехватку дискового пространства. Алерт должен содержать сервис, окружение, временное окно и ссылку на полезный дашборд, если такая ссылка есть в локальной системе.

Шаг 3. Добавить structured logs и distributed tracing

Зафиксируйте обязательные поля логов, настройте передачу trace_id и span_id, инструментируйте входящие запросы, вызовы зависимостей, очереди, базу данных и критичные бизнес-операции. Введите sampling для ошибок, медленных запросов и репрезентативной доли успешных операций.

Проверьте корреляцию на реальном запросе: график должен вести к trace, trace к логам, а логи к тому же сервису, окружению и временному окну. Разрыв на этом этапе лучше устранить до расширения покрытия.

Шаг 4. Проверить систему на искусственном инциденте

Создайте контролируемый timeout зависимости, задержку storage, ограничение CPU или ошибку сети в тестовом контуре. Пройдите весь путь расследования: алерт, метрики, trace, span, лог, инфраструктурное подтверждение и повторная проверка после исправления.

Зафиксируйте версии компонентов, конфигурации, ограничения sampling, известные пробелы телеметрии и результаты проверки в базе знаний команды. Пересматривайте схему после крупных изменений архитектуры, появления новых сервисов, роста нагрузки или изменения требований безопасности.