Наблюдайте за сервисом и его пользователями

Начните с вопроса

Мониторинг проверяет известные условия. Наблюдаемость помогает исследовать поведение системы, включая непредвиденные сбои. Большее число дашбордов не даёт автоматически более точных ответов.

Для вымышленного сервиса экспорта начните с вопроса пользователя: может ли уполномоченный пользователь получить правильный экспорт за согласованное время? Затем выберите сигналы, которые помогают ответить на этот вопрос и объяснить сбои.

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

Свяжите разные виды доказательств

Метрика измеряет величину во времени. Лог записывает событие. Trace связывает операции при прохождении запроса через систему. Span представляет одну операцию внутри trace.

Для асинхронной работы сохраняйте безопасную связь между отправленной задачей и её выполнением worker. Ответ HTTP 202 может означать, что работа принята. Он не доказывает, что экспорт завершён.

Оповещайте, когда нужно действие

Определите SLI и его знаменатель до установки SLO. В этом примере считайте разрешённые экспорты, правильно завершённые за согласованное время. Определите, как в измерение входят длительные и брошенные задачи.

Бюджет ошибок описывает допустимые сбои в окне SLO. Скорость расходования бюджета, или burn rate, показывает, как быстро сбои его расходуют. Рекомендации Google используют несколько временных окон для баланса между своевременным обнаружением и шумом оповещений. Оповещения по SLO.

Вызывайте ответственного, когда условие требует своевременного действия. Менее срочную работу отправляйте в очередь. Для каждого оповещения нужны ответственный, описание влияния, ссылка для расследования и инструкция по реагированию. Пересматривайте оповещения, которые регулярно не приводят к действию.

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

Защитите pipeline телеметрии

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

Не используйте email клиента или уникальный ID задачи как метку метрики. Неограниченные метки увеличивают число временных рядов и могут раскрывать идентификаторы. Для метрик используйте контролируемые измерения. Разрешённые идентификаторы связи помещайте в логи или traces с контролем доступа.

Измеряйте сам pipeline. Проверяйте ошибки приёма, потерянные данные и возраст последнего наблюдения. Ровный график ошибок может означать отсутствие ошибок или отсутствие поступающей телеметрии. Показывайте эту разницу.

Исследуйте конкретный сбой

Вымышленный сервис отвечает HTTP 202 на каждый запрос. Возраст задач в очереди растёт с секунд до 15 минут. Логи worker показывают повторяющиеся тайм-ауты базы данных. Выборочные traces показывают, что большая часть времени worker уходит на обращения к базе данных.

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

Taiga Monitoring даёт представление о состоянии продукта через сигналы доступности и работы в браузере. Он дополняет наблюдаемость инфраструктуры и приложения, а не заменяет эти системы. Monitoring.