Observability, или наблюдаемость, — это способность понимать внутреннее состояние ИТ-системы по данным, которые она генерирует во время работы. К таким данным относятся метрики, журналы событий, распределенные трассировки и другая телеметрия.
Observability помогает инженерам отвечать не только на вопрос работает ли система, но и понимать, почему она работает медленно, где возникла ошибка, какой компонент стал причиной сбоя и как проблема повлияла на пользователей.
Подход особенно важен для облачных приложений, микросервисов, Kubernetes, распределенных систем, высоконагруженных сайтов и инфраструктуры, где один пользовательский запрос может проходить через десятки компонентов.
Что такое Observability простыми словами
Представим интернет-магазин. Пользователь нажимает кнопку Оформить заказ, но страница зависает. Сам сайт доступен, серверы включены, процессоры не перегружены. Обычный мониторинг может показать, что инфраструктура в целом работает нормально.
Но проблема может находиться глубже: сервис заказов слишком долго обращается к базе данных, платежный API отвечает с задержкой или один микросервис возвращает ошибки.
Observability позволяет проследить весь путь запроса и определить, где именно возникает задержка.
Главная задача Observability — дать инженеру достаточно данных, чтобы понять внутреннее состояние сложной системы без необходимости заранее знать все возможные виды отказов.
Чем Observability отличается от мониторинга
Мониторинг и Observability тесно связаны, но не полностью совпадают.
Мониторинг обычно отвечает на заранее определенные вопросы. Например, превышает ли загрузка процессора 90 процентов, доступен ли сайт, достаточно ли свободного места на диске.
Observability помогает исследовать неизвестные проблемы. Инженер может начать с симптома и постепенно определить его причину, даже если для конкретного сбоя заранее не был создан отдельный алерт.
| Мониторинг | Observability |
|---|---|
| Проверяет известные показатели | Позволяет исследовать неизвестные проблемы |
| Часто строится вокруг алертов | Строится вокруг анализа телеметрии |
| Отвечает на вопрос что произошло | Помогает понять почему это произошло |
| Может контролировать отдельные серверы | Связывает данные всей распределенной системы |
На практике качественная система эксплуатации обычно сочетает оба подхода. Мониторинг быстро обнаруживает отклонение, а Observability помогает провести диагностику.
Основные компоненты Observability
Классически выделяют три основных источника телеметрии: метрики, логи и трассировки. Иногда их называют тремя столпами Observability.
| Компонент | Что показывает |
|---|---|
| Метрики | Числовые показатели состояния системы во времени |
| Логи | Подробные события, ошибки и сообщения приложений |
| Трассировки | Путь отдельного запроса через компоненты системы |
Эти данные особенно полезны вместе. Метрика показывает рост ошибок, трассировка помогает найти проблемный сервис, а лог объясняет конкретную техническую причину.
Что такое метрики
Метрики — числовые значения, которые собираются через определенные интервалы времени. Они позволяют отслеживать изменение состояния системы и строить графики.
Примерами метрик являются загрузка процессора, использование оперативной памяти, количество запросов в секунду, время ответа приложения, число ошибок и длина очереди сообщений.
Метрики удобны тем, что их можно эффективно хранить и анализировать на больших интервалах времени.
- CPU utilization;
- использование памяти;
- доступное место на диске;
- количество HTTP-запросов;
- доля ошибок;
- время ответа;
- количество подключений к базе данных;
- размер очереди;
- количество активных пользователей.
Что такое логи
Логи, или журналы событий, содержат информацию о конкретных действиях и событиях внутри приложения или инфраструктуры.
Например, приложение может записать информацию об успешном запуске, ошибке подключения к базе данных, отказе авторизации или необработанном исключении.
Логи обычно содержат больше деталей, чем метрики, но их объем значительно выше. В крупных инфраструктурах могут генерироваться миллионы записей ежедневно.
Поэтому журналы желательно централизовать, структурировать и снабжать метаданными, которые позволяют быстро найти события конкретного приложения, сервера, пользователя или запроса.
Что такое трассировка
Distributed Tracing, или распределенная трассировка, показывает путь одного запроса через несколько сервисов.
Например, пользователь открывает страницу товара. Запрос сначала поступает на Reverse Proxy, затем в веб-приложение, после этого приложение обращается к сервису каталога, базе данных и сервису рекомендаций.
Трассировка позволяет увидеть каждый этап, его продолжительность и возможные ошибки.
Это особенно важно в микросервисной архитектуре, где без трассировки сложно определить, какой из десятков компонентов замедлил пользовательский запрос.
Что такое Trace
Trace представляет полный путь конкретной операции через распределенную систему.
Например, один HTTP-запрос пользователя может создать trace, который включает работу API Gateway, сервиса авторизации, сервиса заказов и базы данных.
Каждый trace получает уникальный идентификатор. Он помогает связать события между несколькими приложениями и найти относящиеся к одному запросу логи.
Что такое Span
Span — отдельный участок трассировки. Он описывает определенную операцию внутри общего запроса.
Например, trace оформления заказа может содержать несколько span: проверку пользователя, обращение к каталогу, запись заказа в базу и запрос к платежному сервису.
| Понятие | Суть |
|---|---|
| Trace | Полный путь запроса через систему |
| Span | Отдельный этап обработки этого запроса |
| Trace ID | Идентификатор всей операции |
| Span ID | Идентификатор конкретного этапа |
Как метрики, логи и трассировки работают вместе
Представим, что мониторинг показывает рост времени ответа интернет-магазина.
По метрикам инженер видит, что задержка появилась примерно в 14:30 и затронула около 20 процентов запросов.
Затем он открывает трассировки медленных запросов и обнаруживает, что большая часть времени расходуется на обращение к сервису каталога.
После этого в логах сервиса находится ошибка подключения к одному из узлов базы данных.
Таким образом, каждый источник телеметрии отвечает на разные вопросы и помогает последовательно приблизиться к первопричине.
Что такое телеметрия
Телеметрия — данные о состоянии и работе системы, которые автоматически собираются и передаются для анализа.
В контексте Observability к телеметрии относятся метрики, логи, трассировки, события и иногда профили производительности.
Чем сложнее инфраструктура, тем важнее единые правила сбора телеметрии. Если каждое приложение использует собственный формат логов и идентификаторов, анализ распределенных проблем становится значительно сложнее.
Observability и SRE
Observability является одним из ключевых инструментов Site Reliability Engineering. SRE-команда отвечает за надежность сервисов и должна объективно понимать их состояние.
Без наблюдаемости сложно контролировать SLI и SLO, анализировать инциденты и сокращать время восстановления.
Например, SRE может установить SLO, согласно которому 99,9 процента запросов должны обрабатываться быстрее определенного времени. Метрики позволяют измерять выполнение цели, а трассировки и логи помогают разобраться с причинами нарушения.
Observability и SLI
SLI представляет фактический измеряемый показатель качества сервиса. Observability предоставляет данные, из которых такие показатели рассчитываются.
Например, из телеметрии можно определить долю успешных запросов, задержку или доступность определенной функции приложения.
Важно выбирать SLI с учетом пользовательского опыта. Низкая загрузка процессора не означает, что пользователь может успешно оформить заказ.
Observability и SLO
SLO устанавливает целевое значение для определенного SLI. Например, 99,95 процента запросов должны выполняться без ошибок.
Observability позволяет постоянно измерять фактическое состояние и сравнивать его с целевым.
Если система начинает приближаться к нарушению SLO, команда может заранее определить проблемный компонент и принять меры.
Observability и алерты
Алерт уведомляет инженера о том, что показатель вышел за допустимые пределы или произошло значимое событие.
Хорошая Observability-платформа не должна создавать уведомление для каждой технической аномалии. Иначе инженеры начинают получать слишком много сигналов и перестают воспринимать их серьезно.
Желательно создавать алерты для ситуаций, которые действительно влияют на пользователя или требуют действия специалиста.
Наблюдаемость должна уменьшать неопределенность при инциденте, а не создавать сотни графиков и уведомлений без понятной цели.
Что такое Alert Fatigue
Alert Fatigue — усталость инженеров от слишком большого количества уведомлений.
Например, система может каждую ночь отправлять предупреждение о кратковременной высокой загрузке процессора, хотя пользователи не замечают никаких проблем. Со временем сотрудники начинают игнорировать такие уведомления.
Опасность заключается в том, что среди большого количества незначимых сигналов может затеряться действительно критичный инцидент.
Поэтому алерты должны регулярно пересматриваться и привязываться к реальному влиянию на сервис.
Observability в микросервисах
Микросервисное приложение может состоять из десятков или сотен независимых сервисов. Один пользовательский запрос проходит через несколько из них.
Если запрос завершается ошибкой, найти причину по отдельным логам каждого сервиса сложно.
Распределенная трассировка связывает этапы обработки в единую цепочку. Инженер видит, какой сервис вызвал следующий, сколько времени занял каждый этап и где появилась ошибка.
Поэтому Observability становится особенно важной по мере роста количества компонентов системы.
Observability в Kubernetes
Kubernetes усложняет традиционный подход к мониторингу. Контейнеры могут автоматически создаваться, удаляться и перемещаться между физическими серверами.
Нельзя рассчитывать, что администратор вручную войдет на конкретный сервер и найдет нужный лог-файл.
Поэтому данные необходимо собирать централизованно и связывать с метаданными Kubernetes: кластером, namespace, pod, контейнером и приложением.
В Observability Kubernetes обычно входят метрики кластера, состояние подов, логи контейнеров, сетевые показатели и трассировки приложений.
Observability в облаке
Облачные инфраструктуры динамичны. Виртуальные машины и контейнеры могут создаваться автоматически, а приложения распределяться между несколькими зонами и регионами.
Observability позволяет видеть эту инфраструктуру как единую систему, а не как набор отдельных серверов.
Например, можно определить, что ошибки возникают только у пользователей, запросы которых обслуживаются конкретной зоной доступности.
Observability и база данных
Проблемы базы данных часто становятся причиной медленной работы приложений.
Для СУБД полезно контролировать время выполнения запросов, количество соединений, блокировки, использование памяти, операции чтения и записи, размер базы и репликацию.
При наличии распределенной трассировки можно определить, какой запрос приложения вызвал медленную SQL-операцию и сколько времени заняло ее выполнение.
Observability и API
Для API обычно контролируют количество запросов, коды ответов, задержку, объем трафика и доступность отдельных методов.
Особенно важно видеть не только среднее время ответа. Например, среднее значение может составлять 100 миллисекунд, но небольшая часть пользователей получает ответ через несколько секунд.
Поэтому анализируют распределение задержек и перцентили, позволяющие оценивать опыт большей части пользователей.
Что такое latency
Latency — задержка между началом операции и получением результата.
Для веб-сервиса это может быть время обработки HTTP-запроса. Для базы данных — длительность выполнения запроса.
Высокая latency не всегда означает полный отказ сервиса, но может сделать систему практически непригодной для пользователя.
Observability помогает определить, на каком именно участке появляется задержка.
Что такое Error Rate
Error Rate показывает долю операций, завершившихся ошибкой.
Например, из тысячи запросов десять завершились кодом 500. В таком случае доля ошибок составляет один процент.
Эта метрика часто используется в SLI и SLO, поскольку напрямую отражает способность сервиса успешно выполнять запросы пользователей.
Что такое Saturation
Saturation показывает, насколько близок ресурс к максимальной нагрузке.
Например, сервер может использовать почти всю оперативную память, база данных — достигать предела соединений, а дисковая система — иметь длинную очередь операций.
Высокая насыщенность не обязательно уже означает отказ, но может предупреждать о скором ухудшении производительности.
Метод RED
Для наблюдения за сервисами часто используют подход RED. Он концентрируется на трех группах показателей.
| Показатель | Что измеряет |
|---|---|
| Rate | Количество запросов |
| Errors | Количество или долю ошибок |
| Duration | Продолжительность выполнения запросов |
Такой набор хорошо подходит для веб-сервисов и API, поскольку быстро показывает уровень нагрузки, ошибки и скорость ответа.
Метод USE
Для инфраструктурных ресурсов может использоваться подход USE.
| Показатель | Что показывает |
|---|---|
| Utilization | Степень использования ресурса |
| Saturation | Наличие очередей и приближение к пределу |
| Errors | Ошибки работы ресурса |
Например, для дисковой системы можно оценивать процент использования, длину очереди операций и ошибки ввода-вывода.
Что такое OpenTelemetry
OpenTelemetry — открытый набор спецификаций, инструментов и компонентов для формирования и передачи телеметрических данных.
Он помогает унифицировать работу с метриками, логами и трассировками в разных приложениях.
Главная идея заключается в том, чтобы приложение могло генерировать телеметрию в стандартизированном виде и отправлять ее в выбранную систему наблюдаемости.
Это уменьшает зависимость приложений от конкретного продукта мониторинга и упрощает построение единого подхода к телеметрии.
Что такое инструментирование приложения
Инструментирование означает добавление в приложение механизмов, которые формируют телеметрию.
Например, разработчик может настроить измерение времени выполнения HTTP-запросов, создание trace для пользовательской операции и добавление идентификатора запроса в логи.
Часть инструментирования может выполняться автоматически с помощью библиотек и агентов, а для бизнес-операций часто требуется дополнительная настройка со стороны разработчиков.
Корреляция логов и трассировок
Большую ценность дает возможность связать разные источники данных.
Например, пользователь сообщает, что в определенное время не смог выполнить платеж. Инженер находит trace операции и получает его Trace ID.
По этому же идентификатору можно найти относящиеся к запросу записи в логах нескольких сервисов.
Без корреляции пришлось бы вручную сопоставлять время, адреса серверов и другие признаки, что значительно увеличивает время диагностики.
Observability и пользовательский опыт
Хорошая наблюдаемость должна отражать не только техническое состояние серверов, но и возможность пользователя выполнить нужную операцию.
Например, все серверы могут быть доступны, но оплата заказов не работает из-за проблемы внешнего платежного сервиса.
Поэтому полезно отслеживать бизнес-операции: успешное оформление заказа, авторизацию, загрузку отчета или выполнение платежа.
Такие показатели дают более точное представление о реальном качестве сервиса.
Observability и бизнес-метрики
Техническую телеметрию можно дополнять бизнес-показателями. Например, количеством оформленных заказов, регистраций или платежей в минуту.
Резкое снижение бизнес-метрики может обнаружить проблему раньше, чем обычный инфраструктурный мониторинг.
Например, серверы работают нормально, но после обновления кнопка оформления заказа перестала отправлять форму. CPU и память остаются в норме, а количество заказов резко падает.
Наблюдение за бизнес-метриками помогает быстрее заметить такие ошибки.
Observability и безопасность
Телеметрия может использоваться и для расследования инцидентов безопасности. Логи позволяют увидеть неудачные попытки входа, необычные запросы или изменение конфигурации.
При этом сама система Observability содержит большое количество чувствительной технической информации. В логах могут случайно появляться токены, персональные данные или параметры запросов.
Поэтому доступ к телеметрии необходимо ограничивать, а приложения следует настраивать так, чтобы секреты и лишние пользовательские данные не попадали в журналы.
Стоимость Observability
Сбор всей возможной телеметрии может оказаться дорогим. Особенно быстро растет объем логов и трассировок.
Если приложение генерирует тысячи запросов в секунду, сохранение подробной трассировки каждого запроса потребует значительных ресурсов хранения.
Поэтому компании используют разные сроки хранения, фильтрацию, агрегацию и sampling.
Что такое Sampling
Sampling — сохранение только части телеметрических данных вместо полного потока.
Например, система может сохранять подробные трассировки для одного процента обычных успешных запросов, но сохранять все запросы, завершившиеся ошибкой.
Это помогает уменьшить стоимость хранения и обработки данных, сохраняя достаточный объем информации для диагностики.
Неправильный sampling может скрыть редкие проблемы, поэтому стратегию выборки необходимо продумывать с учетом критичности сервиса.
Cardinality в метриках
Cardinality показывает количество уникальных комбинаций значений меток у метрики.
Например, метрика количества HTTP-запросов с меткой метода имеет небольшую кардинальность, потому что возможных HTTP-методов немного.
Если добавить в метку уникальный идентификатор каждого пользователя, количество комбинаций может вырасти до миллионов.
Высокая cardinality значительно увеличивает требования к хранению и обработке метрик, поэтому уникальные идентификаторы обычно лучше хранить в логах или трассировках.
Преимущества Observability
- ускоряет диагностику сложных сбоев;
- позволяет видеть взаимосвязи между сервисами;
- помогает контролировать пользовательский опыт;
- снижает время восстановления после инцидентов;
- помогает анализировать производительность;
- дает данные для SLI и SLO;
- упрощает расследование проблем после релизов;
- позволяет находить узкие места инфраструктуры;
- повышает прозрачность распределенных систем.
Недостатки и риски Observability
Само наличие большого количества данных еще не означает хорошую наблюдаемость. Компания может собирать терабайты логов, но не иметь возможности быстро определить причину проблемы.
- высокая стоимость хранения телеметрии;
- слишком большое количество незначимых метрик;
- сложность настройки распределенной трассировки;
- риск попадания конфиденциальных данных в логи;
- большое количество шумных алертов;
- необходимость стандартизировать форматы данных;
- дополнительная нагрузка на приложения;
- сложность поддержки единой системы в большой инфраструктуре.
Типичные ошибки при внедрении Observability
- Собирать все данные без понимания, зачем они нужны.
- Считать Observability обычным набором графиков CPU и памяти.
- Не связывать логи, метрики и трассировки между собой.
- Не использовать единые идентификаторы запросов.
- Создавать алерты для каждого технического отклонения.
- Не контролировать стоимость хранения телеметрии.
- Записывать пароли, токены и другие секреты в логи.
- Не отслеживать пользовательские и бизнес-операции.
- Хранить телеметрию без понятных сроков хранения.
- Не обучать инженеров работе с инструментами анализа.
Как внедрить Observability
Шаг 1. Определить критичные сервисы
Необходимо понять, какие системы наиболее важны для бизнеса и какие пользовательские операции необходимо контролировать в первую очередь.
Шаг 2. Выбрать ключевые показатели
Нужно определить метрики доступности, ошибок, задержки и нагрузки, которые отражают состояние сервиса.
Шаг 3. Централизовать логи
Журналы разных серверов и приложений следует собирать в общей системе, где по ним можно выполнять поиск и анализ.
Шаг 4. Добавить трассировки
Для распределенных приложений полезно создать сквозные Trace ID и отслеживать путь пользовательских запросов между сервисами.
Шаг 5. Связать источники данных
Метрики, логи и трассировки должны дополнять друг друга. Из графика ошибки желательно иметь возможность перейти к конкретному trace и его логам.
Шаг 6. Настроить полезные алерты
Следует уведомлять сотрудников только о событиях, которые требуют действий или заметно влияют на пользователей.
Шаг 7. Контролировать стоимость
Для больших объемов телеметрии необходимо определить сроки хранения, sampling и правила фильтрации.
Практический пример
Компания использует интернет-магазин, построенный из нескольких микросервисов. После очередного релиза часть пользователей начала жаловаться на медленное оформление заказов.
Мониторинг показал, что серверы работают и уровень ошибок остается небольшим. По общей загрузке инфраструктуры определить проблему не удалось.
Инженеры изучили трассировки медленных запросов и обнаружили, что сервис заказов большую часть времени ожидает ответ сервиса расчета доставки.
Затем по Trace ID нашли связанные записи в логах. Выяснилось, что после обновления сервис доставки начал выполнять дополнительный медленный запрос к базе данных.
После оптимизации запроса задержка вернулась к нормальному уровню. Без распределенной трассировки инженерам пришлось бы вручную проверять каждый компонент системы.
Observability и MTTR
MTTR часто используется для оценки времени восстановления после инцидента.
Хорошая Observability помогает уменьшать этот показатель, поскольку инженер быстрее переходит от симптома к первопричине.
Если при аварии специалист сначала тратит несколько часов на сбор логов с разных серверов, восстановление затягивается. Централизованные и связанные данные позволяют начать анализ практически сразу.
Когда бизнесу нужна Observability
Чем сложнее цифровая инфраструктура и выше стоимость простоя, тем больше ценность наблюдаемости.
- приложение состоит из множества микросервисов;
- используются Kubernetes и контейнеры;
- сервис работает круглосуточно;
- причины инцидентов сложно находить обычным мониторингом;
- используются SLI и SLO;
- частые релизы влияют на стабильность;
- система распределена между несколькими облаками или дата-центрами;
- необходимо уменьшить время восстановления после сбоев.
Когда сложная Observability-платформа может быть избыточной
Для небольшого сайта на одном сервере внедрение дорогостоящей распределенной трассировки может не оправдывать затраты.
В такой инфраструктуре базовых метрик, централизованных логов и контроля доступности часто достаточно.
Набор инструментов должен соответствовать сложности системы. Цель Observability заключается не в максимальном количестве данных, а в возможности быстро получать ответы на важные вопросы о работе сервиса.
Связанные термины
| Термин | Связь с Observability |
|---|---|
| Monitoring | Контроль заранее определенных показателей и состояний системы |
| Метрики | Числовые данные о работе системы |
| Логи | Журналы событий приложений и инфраструктуры |
| Distributed Tracing | Отслеживание пути запроса через распределенную систему |
| OpenTelemetry | Открытый подход к формированию и передаче телеметрии |
| SRE | Инженерный подход к надежности, активно использующий Observability |
| SLI | Фактически измеряемый показатель качества сервиса |
| SLO | Целевое значение показателя надежности |
| Latency | Задержка выполнения операции |
| Alert | Уведомление о проблеме или значимом отклонении |
| Trace | Полный путь отдельной операции через систему |
| Span | Отдельный этап внутри распределенной трассировки |
Краткий итог
Observability — подход к наблюдению за ИТ-системами, который позволяет понимать их внутреннее состояние по телеметрическим данным. Основными источниками информации являются метрики, логи и распределенные трассировки.
В отличие от простого мониторинга, Observability помогает исследовать не только заранее известные проблемы, но и сложные неожиданные сбои. Инженер может увидеть симптом, проследить путь запроса и определить конкретный компонент, ставший причиной ошибки или задержки.
Наблюдаемость особенно важна для микросервисов, Kubernetes, облачной инфраструктуры и SRE. При этом эффективность зависит не от количества собранных данных, а от их качества, связи между источниками, удобства анализа и способности быстро отвечать на вопросы о реальном пользовательском опыте.
