Связаться с намиПопробовать бесплатно

Observability

Статья создана
Обновлена 19 декабря 2025 г.

Observability (наблюдаемость) — возможность понять внутреннее состояние системы по предоставляемой ею информации. Включает сбор, анализ и визуализацию метрик, логов и трассировок для мониторинга и отладки приложений. Наблюдаемость лежит в основе обеспечения надежности современных приложений.

Термин был придуман в 60-х годах и использовался в основном в контексте проектирования самолетов, ракет и производственных процессов. В информационные технологии он попал в начале 2010-х годов, а к их концу — достиг пиковой популярности.

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

Отличие от мониторинга

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

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

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

Какие проблемы решает наблюдаемость

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

  • Компании в сфере финансовых технологий удалось сократить среднее время восстановления системы после сбоев на 60% (с 45 минут до менее чем 15 минут) и улучшить прозрачность работы системы на всех уровнях. Из неочевидных преимуществ: повысилось доверие между командами, перестали искать виноватых в инцидентах.
  • Таможенная служба Дубая страдала от длительных задержек на границе из-за отказов в работе приложения, что негативно влияло на торговлю. Комплексное решение для наблюдения ускорило вывод продукции на рынок на 70%. Служба также смогла выявлять болевые точки системы, чтобы улучшить качество обслуживания.
  • Сервис обзоров книг Blinklist смог нарастить конкурентное преимущество за счет отслеживания данных для агрессивных маркетинговых стратегий. В компании изменили подход к наблюдению за взаимодействием пользователей с приложением и повысили прозрачность операций, а на основе полученных данных разработали новые подходы к продвижению сервиса.
  • Британский банк TSB ускорил внедрение цифровых инноваций и улучшил качество обслуживания клиентов. Чтобы расширить присутствие на рынке, банк создал многооблачную архитектуру, однако усложнение системы заставило идти на компромисс между инновациями и качеством. Внедрение наблюдаемости решило проблему: позволило отслеживать все компоненты и зависимости в режиме реального времени, выявляя причины проблем еще до изменений в производственной среде.
  • Облачная компания Braze столкнулась с проблемами масштабирования, доступности приложения и неэффективности поддержки клиентов. Внедрение централизованного наблюдения позволило сократить время обработки запросов на 90%, а также создать отдельную, более эффективную команду технической поддержки клиентов.

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

Чтобы ваше приложение можно было назвать наблюдаемым, нужно пройти три этапа:

  1. Разработка.
  2. Сбор данных.
  3. Аналитика данных.

Этап разработки

Можно приобрести множество инструментов сбора и аналитики данных, однако все они будут бесполезны, если сама система представляет собой «черный ящик». До 80 % успеха наблюдаемости решается еще на этапе разработки. Рассмотрим основные моменты, которые нужно учесть:

  • Привязывайте библиотеки для сбора телеметрии ко всем проектам по умолчанию. Например, OpenTelemetry.

  • Собирайте все виды телеметрии — метрики, логи, трейсы.

  • Используйте единые атрибуты запроса во всех сервисах, чтобы проще было отследить контекст потенциальных проблем.

  • Структурируйте логи. Например, создавайте их в формате JSON с полной информацией о запросе.

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

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

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

  • Добавляйте подробные метки для сборки (версия сервиса, хеш коммита, идентификатор конвейера).

  • Следуйте принципу золотого сигнала, добавив возможность замерять следующие параметры:

    • время отклика системы;
    • количество запросов/транзакций в секунду;
    • процент ошибок, включая успешные запросы с неверным содержанием;
    • количество запросов/соединений с БД в очереди на обработку.

Сбор данных

Рассмотрим три основных типа телеметрии, которые минимально необходимы для наблюдения за системой:

  • Логи — журналы событий, которые подробно описывают действия пользователей и системы. С помощью логов можно очень точно и подробно описать все события, предшествовавшие возникновению проблемы. Для удобства логи часто размечаются по степени важности.
  • Трассировка — фиксирует полный путь пользовательского запроса по архитектуре приложения. В основном используется для отслеживания аномалий и обнаружения причинно-следственных связей при взаимодействии компонентов системы.
  • Метрики — числовые данные, которые замеряют производительность системы и использование ресурсов в конкретный момент времени. Для удобства поиска помечаются метками, например cpu_usage, sys.memory, disk.

Разумеется, чтобы данные можно было эффективно использовать, они должны долго храниться, а также быть структурированными, коррелированными, индексированными и обогащенными тегами.

Аналитика данных

Красивые графики и многопороговые алерты сами по себе не поднимут упавший сервер, но когда по ним вы можете без помощи разработчиков быстро решить проблему посреди ночи — это и есть настоящая Observability. Рассмотрим примеры задач, которые наблюдаемая система должна иметь возможность оперативно решить:

  • Автоматическое выявление деградаций без помощи алертов. Если какие-то пользователи странно себя ведут, количество ошибок увеличилось, показатели какого-то региона снизились и т. д. — это должно быть видно в режиме реального времени.
  • Возможность видеть корреляцию событий по всем типам телеметрии. Например, если упала метрика, то в пару кликов можно обнаружить конкретные ошибки в логах и медленный участок в трассировке.
  • Анализ коренных причин. Когда что-то сломалось, первый вопрос — что именно. И ответ на него должен выясняться за минуты, а не за часы и дни.
  • Анализ карты зависимостей. Необходимо понимать, где узкое место системы, какой микросервис тормозит другие.
  • Прогнозирование. На основе метрик и трассировки должна быть возможность предсказать, когда тот или иной ресурс может закончиться.
  • Предложение исправлений. Некоторые умные системы уже способны подсказать проблемную версию конкретного микросервиса и когда она была развернута.
  • Автоматическое реагирование. В случае поломок, например, можно настроить автомасштабирование, откат к прошлой версии, смену региона и другое.

Проблемы внедрения наблюдаемости

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

  • Большие объемы и сложность данных

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

  • Высокая кардинальность

    Высококардинальные ключи, которые связаны с огромным количеством данных (например, user_id, session_id), могут сделать некоторые метрики бесполезными и кратно увеличить их стоимость. Некоторые разработчики даже отказываются от них, что негативно влияет на корреляцию между данными.

  • Выбор метода сбора данных в распределенных трассировках

    Метод Head-based собирает данные о трассировке в начале пути — это экономично, но редкие данные, которые приходят позже, могут потеряться. Метод Tail-based действует в конце пути — данные не теряются, но процесс выходит слишком ресурсоемким и сложным. Решений вида «дешево и точно» сегодня не существует.

  • Наблюдаемость UI и мобильных приложений

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

  • Наблюдаемость бессерверных вычислений

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

  • Ненадежное предварительное тестирование

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

Искусственный интеллект в сфере Observability

На сегодняшний день искусственный интеллект стал неотъемлемой частью наблюдаемости и интегрируется во многих направлениях: за последний год его использование выросло с 42 % до 54 % для опытных команд. Главное преимущество ИИ для наблюдаемости в том, что он может быстрее и точнее находить и предсказывать проблемы.

Рассмотрим основные направления внедрения ИИ в Observability:

  • Автоматическое обнаружение аномалий и предиктивный анализ. Модели обучаются на старых данных и находят закономерности. К моменту подключения к действующим процессам они уже могут выявлять аномалии и предсказывать поломки.
  • Экономия времени на анализ. Разработчики не всегда могут быстро отыскать в тоннах логов конкретные корреляции и понять причину проблемы. Однако быстрая обработка больших объемов информации — одна из самых сильных сторон ИИ.
  • Решение проблем. ИИ не только диагностирует и предсказывает проблемы, но и может их решать. Например, автоматически перезапускать сервисы, масштабировать выделенные ресурсы и другое.
  • Оптимизация затрат. ИИ способен на сложные расчеты, которые помогают собирать телеметрию более разумно, отсеивая ненужную. Такой подход может снизить затраты на наблюдаемость на 30–40%.
  • Чат-боты. Чат-боты с ИИ могут помочь разработчикам с проблемами разной сложности, а также стать эффективным «сотрудником» технической поддержки.

Observability в Yandex Cloud

Yandex Cloud предлагает следующие сервисы для внедрения наблюдаемости в ваши проекты:

Полезные материалы

Предыдущая
gRPC
Следующая
REST API