---
title: "Наблюдаемость: журналы, метрики, трассировки"
url: "https://kzsaleshub.com/framework/observability-three-pillars/"
type: "framework"
category: "IT и разработка"
language: "ru"
source: "KZSalesHub"
published: "2026-08-11"
last_updated: "2026-09-03"
---

# Наблюдаемость: журналы, метрики, трассировки

**Суть.** Мониторинг отвечает на заранее заданные вопросы: «сервер жив?», «место на диске?». Наблюдаемость — свойство системы, при котором по её сигналам можно ответить на вопрос, который никто заранее не предусмотрел: «почему у этого клиента вчера вечером всё тормозило?». Три вида сигналов дают разные ответы и нужны вместе.

## Три вида сигналов

| Сигнал | На что отвечает | Цена |
| --- | --- | --- |
| Журналы | Что именно произошло в конкретный момент | Дорого хранить, медленно искать без структуры |
| Метрики | Как ведёт себя система в целом и в динамике | Дёшево, но нет подробностей |
| Трассировки | Через какие службы прошёл запрос и где потерял время | Требует сквозной разметки запросов |

## С чего начинать

С метрик, отражающих опыт клиента: доля успешных запросов и время ответа. Дальше структурированные журналы с идентификатором запроса — это уже позволяет проследить один случай. Трассировки нужны, когда служб становится больше пяти и «где тормозит» перестаёт быть очевидным.

Единый стандарт сбора избавляет от привязки к одному поставщику: сигналы собираются в общем формате, а куда их отправлять — отдельное решение.

## Когда применять

Когда на вопрос «почему у клиента не работает» команда отвечает не фактом, а гипотезой. Мониторинг отвечает на вопрос «что сломалось», наблюдаемость — на вопрос «почему», и это разные вложения. Для системы из одного приложения хватает первого; как только появляется несколько сервисов и сеть между ними, нужен второй.

## Три опоры и что каждая даёт

| Опора | Отвечает на вопрос | Стоимость хранения |
| --- | --- | --- |
| Метрики | Что происходит сейчас и как это менялось | Низкая: числа хорошо сжимаются |
| Журналы | Что именно случилось в конкретном запросе | Высокая, растёт линейно с нагрузкой |
| Трассировки | Где во всей цепочке потерялось время | Средняя, обычно с выборкой |

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

## Что делает данные полезными

1. Сквозной идентификатор запроса во всех трёх опорах: без него связать метрику, журнал и трассировку невозможно, и каждый источник живёт сам по себе.
2. Структурированные журналы: пары «поле — значение», а не свободный текст. Текстовый журнал невозможно фильтровать по клиенту или по версии.
3. Единый словарь имён: сервис, окружение, версия, клиент. Разные названия одного и того же — главная причина, почему данные есть, а ответа нет.
4. Срок хранения по уровням: подробности — дни, агрегаты — месяцы, ключевые показатели — годы.

## Что это значит в деньгах

Наблюдаемость почти всегда оказывается заметной статьёй расходов, и растёт она вместе с трафиком. Два рычага дают основную экономию: выборка трассировок (хранить не все, а долю плюс все ошибочные) и дисциплина уровней журналирования. Отладочный уровень, случайно оставленный включённым в продуктиве, способен удвоить счёт за неделю.

## Где ломается

**Собирают всё подряд.** Счёт за хранение растёт быстрее пользы. Объём журналов должен быть решением, а не побочным эффектом.

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

**Меряют серверы, а не сценарии.** Все показатели зелёные, клиент не может оформить заказ.

- **Собирают всё подряд.** Объём растёт, а время поиска ответа не сокращается.
- **Панели строят под демонстрацию.** Красивые экраны, по которым нельзя понять, почему упало.
- **Нет владельца.** Данные общие, отвечает никто, качество разметки падает за квартал.
- **Оповещения не связаны с влиянием на клиента.** Тогда их либо слишком много, либо они приходят позже жалобы.

## Частые вопросы

**С чего начать при ограниченном бюджете**

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

**Нужны ли трассировки небольшой команде**

Если сервисов меньше трёх — обычно нет. Их ценность появляется там, где запрос проходит через несколько систем и непонятно, кто из них тормозит.

**Как связано с уровнями обслуживания**

Прямо: [индикаторы](https://kzsaleshub.com/framework/sli-slo-sla/) считаются именно из этих данных. Договорённость о доступности без наблюдаемости не проверяема.

## Связанное

- [SLI, SLO и SLA](https://kzsaleshub.com/framework/sli-slo-sla/)
- [Разбор инцидентов](https://kzsaleshub.com/framework/incident-postmortem/)
- [Наблюдаемость в глоссарии](https://kzsaleshub.com/glossary/observability/)

Мониторинг отвечает, что сломалось. Наблюдаемость — почему. Второе стоит дороже и нужно тогда, когда причины отказов перестали быть очевидными.

---
Источник: https://kzsaleshub.com/framework/observability-three-pillars/