[Документация Yandex Cloud](../index.md) > [Облачная терминология](index.md) > Сети и доставка контента > Наблюдаемость

# Observability

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

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

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

## Отличие от мониторинга {#observability-vs-monitoring}

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

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

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

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

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

* Компании в сфере финансовых технологий [удалось](https://vc.ru/dev/2304655-vnedrenie-observability-v-finteh-kompanii) сократить среднее время восстановления системы после сбоев на 60% (с 45 минут до менее чем 15 минут) и улучшить прозрачность работы системы на всех уровнях. Из неочевидных преимуществ: повысилось доверие между командами, перестали искать виноватых в инцидентах.
* Таможенная служба Дубая [страдала](https://www.simform.com/blog/observability-success-stories/) от длительных задержек на границе из-за отказов в работе приложения, что негативно влияло на торговлю. Комплексное решение для наблюдения ускорило вывод продукции на рынок на 70%. Служба также смогла выявлять болевые точки системы, чтобы улучшить качество обслуживания.
* Сервис обзоров книг Blinklist [смог](https://barrmoses.medium.com/61-data-observability-use-cases-from-real-data-teams-d478a2d0dc37) нарастить конкурентное преимущество за счет отслеживания данных для агрессивных маркетинговых стратегий. В компании изменили подход к наблюдению за взаимодействием пользователей с приложением и повысили прозрачность операций, а на основе полученных данных разработали новые подходы к продвижению сервиса.
* Британский банк TSB [ускорил](https://www.simform.com/blog/observability-success-stories/) внедрение цифровых инноваций и улучшил качество обслуживания клиентов. Чтобы расширить присутствие на рынке, банк создал многооблачную архитектуру, однако усложнение системы заставило идти на компромисс между инновациями и качеством. Внедрение наблюдаемости решило проблему: позволило отслеживать все компоненты и зависимости в режиме реального времени, выявляя причины проблем еще до изменений в производственной среде.
* Облачная компания Braze [столкнулась](https://www.simform.com/blog/observability-success-stories/) с проблемами масштабирования, доступности приложения и неэффективности поддержки клиентов. Внедрение централизованного наблюдения позволило сократить время обработки запросов на 90%, а также создать отдельную, более эффективную команду технической поддержки клиентов.

## Как сделать систему наблюдаемой {#how-works}

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

1. [Разработка](#develop).
1. [Сбор данных](#collect).
1. [Аналитика данных](#analyze).

### Этап разработки {#develop}

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

* Привязывайте библиотеки для сбора телеметрии ко всем проектам по умолчанию. Например, [OpenTelemetry](https://opentelemetry.io/).
* Собирайте все виды телеметрии — метрики, логи, трейсы.
* Используйте единые атрибуты запроса во всех сервисах, чтобы проще было отследить контекст потенциальных проблем.
* Структурируйте логи. Например, создавайте их в формате JSON с полной информацией о запросе.
* Предусмотрите возможность отслеживания не только старта и завершения операции, но и всех промежуточных шагов (оплата, инвентаризация, отправка уведомлений и так далее).
* Записывайте ошибки как отдельное событие, чтобы проследить всю хронологическую цепочку. Такой подход позволяет различать временные сбои, которые удалось исправить, и окончательные результаты операции.
* Добавляйте в код не только технические, но и бизнес-метрики. Например, количество успешных заказов для каждого типа клиентов и количество отклоненных заказов, разделенных по конкретным причинам.
* Добавляйте подробные метки для сборки (версия сервиса, хеш коммита, идентификатор конвейера).
* Следуйте принципу [золотого сигнала](https://sre.google/sre-book/monitoring-distributed-systems/#xref_monitoring_golden-signals), добавив возможность замерять следующие параметры:
  
  * время отклика системы;
  * количество запросов/транзакций в секунду;
  * процент ошибок, включая успешные запросы с неверным содержанием;
  * количество запросов/соединений с БД в очереди на обработку.

### Сбор данных {#collect}

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

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

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

### Аналитика данных {#analyze}

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

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

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

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

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

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

* **Высокая [кардинальность](https://en.wikipedia.org/wiki/Cardinality_(data_modeling))**

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

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

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

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

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

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

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

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

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

## Искусственный интеллект в сфере Observability {#ai}

На сегодняшний день [искусственный интеллект](ml-models.md) стал неотъемлемой частью наблюдаемости и интегрируется во многих направлениях: за последний год его использование [выросло](https://newrelic.com/resources/report/observability-forecast/2025) с 42 % до 54 % для опытных команд. Главное преимущество ИИ для наблюдаемости в том, что он может быстрее и точнее находить и предсказывать проблемы.

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

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

## Observability в Yandex Cloud {#yc-observability}

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

* [Yandex Monitoring](https://yandex.cloud/ru-kz/services/monitoring/) — сервис для сбора, хранения и визуализации метрик, а также настройки алертов. Подробнее в документации [Monitoring](../monitoring/index.md).
* [Yandex Cloud Logging](https://yandex.cloud/ru-kz/services/logging/) — сервис для сбора и анализа логов. Подробнее в документации [Cloud Logging](../logging/index.md).
* [Yandex Managed Service for Prometheus®](https://yandex.cloud/ru-kz/services/managed-prometheus/) — система мониторинга, совместимая с [Prometheus](https://prometheus.io/docs/introduction/overview/). Подробнее в документации [Yandex Managed Service for Prometheus®](../monitoring/operations/prometheus/index.md).

#### Полезные материалы {#see-also}

* [Сбор метрик кластера «1С:Предприятие» на базе Linux](../monitoring/tutorials/collect-metrics-1c-cluster.md)
* [Видео: Observability для выявления аномалий и нахождения полезных инсайтов для бизнеса](https://yandex.cloud/ru-kz/blog/posts/2024/03/monthly-cloud-news-observability-engineering)
* [Вебинар: Эффективный мониторинг облачных решений](https://yandex.cloud/ru-kz/events/1161)
* [Вебинар: Звонки и эскалации в Monitoring](https://yandex.cloud/ru-kz/events/1017)
* [Вебинар: Инструменты Observability в Yandex Cloud](https://yandex.cloud/ru-kz/events/674)