Эта серия статей призвана разъяснить технические термины в понятной форме и углубиться в тему сравнения наблюдаемости и мониторинга.
Вы когда-нибудь пытались диагностировать неисправность автомобиля, просто прислушиваясь к странному стуку? Так выглядит традиционный мониторинг в мире современного сложного программного обеспечения. Вы знаете, что что-то не так, но выяснение причины может превратиться в длительную и утомительную игру в угадайку. Часто для выявления первопричины проблемы необходимо знать, что именно нужно искать, а мы не всегда имеем такую возможность.
На помощь приходит наблюдаемость. Это больше, чем просто мониторинг; это способность понять внутреннее состояние вашей системы, просто посмотрев на данные, которые она генерирует извне. Когда происходит инцидент, особенно такой, с которым вы никогда раньше не сталкивались (печально известные «неизвестные неизвестные»), наблюдаемость предоставляет данные, необходимые для того, чтобы задать любой вопрос и быстро найти на него ответ. Давайте углубимся в некоторые аспекты, составляющие наблюдаемость.
Топливо для инсайтов: Телеметрия
Вся система наблюдаемости построена на данных. Эти данные в совокупности называются телеметрией.
Телеметрия – это автоматический сбор и передача данных из удаленных источников, в нашем случае – из ваших приложений и инфраструктуры. Это «материал», который вы собираете и который часто подразделяется на три основных типа, иногда называемых «тремя столпами наблюдаемости»:
- Метрики: Цифровые измерения, собираемые в течение определенного времени (например, загрузка ЦП, задержка запросов, количество ошибок). Представьте линейный график с падениями.
- Журналы: Записи с временными метками о произошедших отдельных событиях (например, «Пользователь вошел в систему», «Запрос к базе данных не удался»). Представьте подробные записи в дневнике.
- Трассировки (распределенная трассировка): Записывают путь одного запроса по мере его прохождения через несколько служб. Представьте маршрут GPS одного взаимодействия.
После запроса: Распределенное отслеживание
В мире микросервисов (где одно действие пользователя может затронуть 10 различных приложений) выявление замедления работы – настоящий кошмар.
Распределенное отслеживание решает эту проблему, присваивая уникальный идентификатор запросу в момент его поступления в систему и отслеживая его во всех сервисах, с которыми он взаимодействует.
- Пример: Пользователь нажимает «Купить сейчас». Система отслеживания прослеживает запрос от фронт-энд службы до службы инвентаризации, затем до платежного шлюза и, наконец, до службы подтверждения. Если платежный шлюз заработал 45 секунд, трассировка визуально отмечает этот промежуток времени, мгновенно указывая вам, где находится узкое место.
Управление данными: Кардинальность
При сборе огромных объемов телеметрических данных не все данные создаются одинаково.
Кардинальность означает количество уникальных значений в поле данных.
- Низкая кардинальность: Поле типа «статус» может иметь только 3 уникальных значения («успех», «неудача», «ожидание»). Этими данными легко управлять.
- Высокая кардинальность: Поле типа «ID пользователя» или «ID сеанса» может иметь миллионы уникальных значений. Хотя данные с высокой кардинальностью чрезвычайно полезны для детального устранения неполадок (например, «Что случилось с заказом этого конкретного пользователя?»), они могут увеличить затраты на хранение и замедлить выполнение запросов, если ими не управлять должным образом.
Когда время – деньги: MTTR
Основная цель хорошей наблюдаемости – минимизировать последствия сбоя. Наиболее важным показателем для измерения этих последствий является MTTR.
MTTR означает среднее время восстановления (или иногда среднее время устранения/ремонта). Это среднее время, необходимое вашей команде для полного восстановления нормальной работы системы после обнаружения сбоя.
Более низкий показатель MTTR является признаком высокоэффективной и устойчивой команды. Благодаря высокой наблюдаемости вы можете быстро диагностировать проблемы, что значительно сокращает MTTR и позволяет сэкономить деньги компании и сохранить лояльность клиентов.
Конечная цель: Анализ первопричин
После тушения пожара и восстановления системы (благодаря вашему низкому MTTR!) работа еще не закончена. Необходимо выяснить, как предотвратить повторение подобной ситуации.
Анализ первопричин (RCA) – это структурированный процесс, который позволяет выявить глубинные, фундаментальные причины проблемы, скрытые за поверхностными симптомами. Его цель – найти постоянное решение, а не просто временное исправление.
- Аналогия: У вас прокололась шина. Симптом – прокол. Причина может быть в гвозде на дороге, производственном дефекте или плохом поддержании давления в шинах. RCA гарантирует, что вы замените шину и начнете регулярно проверять давление.
Проактивное мышление: подход Shift Left
Но зачем ждать, пока проблема затронет ваших реальных клиентов?
Shift Left – это подход в разработке программного обеспечения, который предполагает перенос таких практик, как тестирование, доступность, безопасность и наблюдаемость, на более ранние этапы жизненного цикла разработки.
- Пример: Вместо того чтобы ждать, пока код поступит в производство, чтобы увидеть, создает ли новая функция слишком много данных журнала, разработчик использует инструменты наблюдаемости для проверки проблем на этапе тестирования. Это удешевляет и ускоряет исправление ошибок, предотвращая дорогостоящие сюрпризы в будущем.
Предсказуемая проблема: Сезонность
Иногда поведение вашей системы не является ошибкой, а является закономерностью.
Сезонность в области наблюдаемости относится к предсказуемым, повторяющимся колебаниям в ваших телеметрических данных в течение фиксированных периодов (ежедневно, еженедельно, ежемесячно, ежегодно). Это не аномалии, а ожидаемые тенденции.
- Пример: Ваш сайт электронной коммерции может испытывать массовый, предсказуемый всплеск запросов каждое воскресенье утром в 10 часов, когда выходит еженедельный рекламный проспект. Игнорирование этого «сезонного» всплеска может вызвать ненужное предупреждение, но внимательная система знает: «Нет, это просто воскресный день развлечений».
Наблюдаемость – это переход от реактивной позиции «Что сломалось?» к проактивной позиции «Почему это сломалось и как мы можем гарантировать, что это больше не повторится?». Понимая эти ключевые термины и внедряя соответствующие практики, вы не просто контролируете свои системы, а полностью их осваиваете.
Источник: What Even Is… Observability?
