Observability vs Мониторинг: В чем разница?

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

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

Основная цель мониторинга — оперативно ответить на вопрос "что произошло?", какая проблема или сбой возникли в работе ИТ-системы, чтобы минимизировать время простоя и негативное влияние на бизнес.

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

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

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

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

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

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

1. Должна ли система работать 24/7 без простоев, так как она обрабатывает критически важные бизнес-процессы (например, онлайн-платежи, управление клиентскими данными)?

2. Должна ли система поддерживать автоматическое масштабирование в зависимости от нагрузки (например, при увеличении числа пользователей или объема данных)?

3. Построена ли ИТ-система на основе микросервисов, каждый из которых выполняет отдельную функцию (например, аутентификация, обработка платежей, управление пользователями и т.д.)?

4. Является ли система распределенной? Иными словами, развернуты ли микросервисы в разных дата-центрах или в мультиоблачной среде?

5. Используются ли контейнеры (Docker) или оркестраторы (Kubernetes) для управления и масштабирования микросервисов?

6. Используются ли для хранения и обработки данных несколько типов баз данных, включая реляционные (например, PostgreSQL, MySQL) и NoSQL (например, MongoDB, Cassandra)?

7. Используются ли очереди сообщений (например, RabbitMQ, Apache Kafka) для асинхронной обработки данных и обмена сообщениями между микросервисами?

8. Используются ли распределенные системы кеширования (например, Redis, Memcached) и балансировщики нагрузки для обеспечения высокой производительности?

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

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

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

1. Импортонезависимость

Инструмент не должен зависеть от иностранных поставщиков ни напрямую, ни косвенно.

К примеру, если коммерческое observability решение в качестве своего интерфейса использует не собственную разработку, а иностранное ПО с открытым исходным кодом (opensource), распространяемое под лицензией GNU General Public License или ее производными лицензиями, в таком случае такое решение по наблюдаемости не может быть коммерческим продуктом согласно условиям GNU лицензии, должно распространяться бесплатно и публиковать свой исходный код целиком, а не только модифицированную часть интерфейса на основе opensource.

Поэтому при выборе поставщика observability важно заранее узнать, не построена ли существенная часть его решения на основе opensource программного обеспечения с лицензиями GNU Affero General Public License (AGPL), GNU General Public License или их производными лицензиями. Начав использовать решение, которое нарушает условия распространения открытого ПО, вы существенно повышает свои юридические риски, в плоть до судебного разбирательства с компанией правообладателем такого opensource продукта.

2. Предсказуемая стоимость владения

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

При выборе observability решения важно заранее ознакомиться с политикой лицензирования и посчитать полную стоимость владения, включающую в себя не только стоимость лицензий, но и услуги по внедрению и технической поддержки, затраты на аппаратное обеспечения (в случае on-premise инсталляции).

У многих продуктов по наблюдаемости политика лицензирования подразумевает разделение на функциональные модули, которые по-разному тарифицируются, приобретаются отдельными лицензиями и имеют разные ограничения и лимиты, например по числу ядер CPU, объему RAM, количеству пользователей, сессий и просмотров Real User Monitoring, сетевым устройствам и т.п.

Чаще всего модули бывают следующие:

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

Также важно понимать, что подход с разделением на модули в целом дает больше минусов, нежели плюсов, а именно:

На рынке представлены не только решения, лицензионная политика которых подразумевает разделение на модули. Есть observability платформы, у которых весь функционал доступен в рамках одной лицензии. Выбирая такое решение, вы сразу нивелируете минусы продуктов, применяющих разделение на модули, получаете предсказуемую стоимость и отсутствие превышений бюджета.

3. Масштабируемость

Решение и его политика лицензирования должны быть достаточно гибкими, чтобы можно было масштабироваться по мере роста бизнеса.

Оценивая observability инструменты по данному критерию, важно ответить на следующие вопросы: