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

В этом руководстве обе идеи объясняются без использования маркетингового языка и прослеживаются в одном вымышленном инциденте от предупреждения до основной причины. Журналы, трассировка и цифры придуманы для иллюстрации процесса. Вы также должны знать, что поставщики и практики проводят эту линию по-разному, и некоторые считают, что это отчасти маркетинговое различие. Мы делаем упор на практическую часть.

Короткий ответ

Мониторинг — это деятельность. Вы заранее решаете, за чем следить, например, за процессором, частотой ошибок или дисковым пространством, и устанавливаете пороговые значения, которые вызывают оповещения. Он отвечает: «Произошло ли то, о чем я беспокоился?»

Наблюдаемость — это свойство вашей системы. Этот термин пришел из теории управления, где он описывает, насколько хорошо вы можете сделать вывод о внутреннем состоянии системы на основе ее внешних результатов. На практике он отвечает: «Что происходит и почему, в том числе и из-за проблем, которых я не ожидал?»

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

Мониторинг и наблюдаемость бок о бок

Это не выбор между двумя. Вам по-прежнему нужны оповещения, подсказывающие, когда искать.

Почему одного мониторинга недостаточно

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

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

Журналы, метрики и трассировки

Эти три типа телеметрии часто называют столпами наблюдаемости. Каждый отвечает на свой вопрос:

Метрики

http_requests_total{service="checkout", status="500"} 1832
http_request_duration_seconds{service="checkout", quantile="0.95"} 2.4

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

Следы

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

POST /checkout                      2410 ms
├─ auth-service: verify token         18 ms
├─ cart-service: load cart            42 ms
├─ pricing-service: calculate       2290 ms   <-- slow
│  └─ SELECT coupons ...            2265 ms
└─ payment-service: not reached

Трассировка делает медленный шаг очевидным, что очень сложно увидеть в отдельных логах отдельных сервисов.

Журналы

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

Описание инцидента

Вот как части соединяются друг с другом на вымышленном примере.

Мониторинг выполнялся на этапе 1. Все, что было дальше, было наблюдаемостью. Обратите внимание, как каждый вопрос возник из предыдущего ответа. Никто не мог заранее создать информационную панель для «запроса купонов в мобильном приложении из сегодняшней кампании». Что касается самого исправления, в нашем руководстве по оптимизации SQL-запросов показано, как читать такой план.

Улучшенные журналы

Журналы в виде простого текста созданы для человеческого глаза, и их трудно запрашивать. Структурированные журналы используют поля, по которым машина может фильтровать:

# Hard to search
ERROR Payment failed for user 42 after 3 tries

# Easy to search
{"level":"error","event":"payment_failed","user_id":"42",
 "attempts":3,"provider":"acme","trace_id":"a1b2c3","duration_ms":2410}

При помощи второй формы можно сразу спросить «сколько сбоев у одного провайдера за последний час?» Поле trace_id особенно ценно, поскольку оно связывает строку журнала со всем запросом для каждой службы, к которой он обращается.

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

Золотые сигналы

Не знаете, что отслеживать? Книга Google Site Reliability Engineering предлагает четыре сигнала для систем, ориентированных на пользователя:

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

Оповещения, которым люди доверяют

Если оповещения срабатывают постоянно, люди перестанут их читать. Хорошие люди следуют нескольким правилам:

• Оповещение о симптомах, которые ощущают пользователи. «Ошибки при оформлении заказа выше 2 %» лучше, чем «Загрузка процессора при 85 %». Высокий процессор, который никому не вредит, не должен никого будить.
• Сделайте каждое оповещение действенным. Если никому не нужно ничего делать, сделайте его элементом панели управления или удалите.
• Ссылка на Runbook. Расскажите респонденту, где искать и что попробовать.
• Регулярно просматривайте их. Удалите или исправьте все оповещения, которые были проигнорированы в прошлом месяце.

Цели уровня обслуживания

SLO превращает «сайт должен быть быстрым и надежным» в измеримую цель, например «99,9% запросов на оформление заказа выполняются в течение 30 дней». Это позволяет исключить около 0,1 % ошибок, что называется бюджетом ошибок. Если у вас осталось много, вы можете отправить товар быстрее, а если он почти израсходован, вы можете поставить надежность в приоритет. Это полезный способ разрешить споры между скоростью доставки и стабильностью.

OpenTelemetry и инструменты

OpenTelemetry — это независимый от поставщиков стандарт с открытым исходным кодом для создания и экспорта данных телеметрии. Это проект Cloud Native Computing Foundation. Инструментирование с его помощью означает, что вы можете изменить свой бэкэнд позже, не переписывая код. Это не продукт хранилища или информационной панели, поэтому вы можете объединить его с одним из них:

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

С чего начать

1. Начните с золотых сигналов для вашей самой важной услуги.
2. Добавьте одно или два оповещения о симптомах, которые замечают пользователи.
3. Перейдите на структурированные журналы, с идентификатором запроса в каждой строке.
4. Добавьте трассировку в свой основной путь пользователя с помощью OpenTelemetry, поскольку автоматическое инструментирование может охватывать многие распространенные платформы.
5. Свяжите развертывания со своими графиками, чтобы вы могли увидеть, вызвал ли выпуск из вашего конвейера CI/CD изменения.
6. Извлекайте уроки из каждого инцидента. После каждого из них спрашивайте, какие данные помогли бы быстрее решить проблему, и добавляйте их.

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

Распространенные ошибки

• Купить инструмент и назвать его наблюдаемым. Ценность зависит от хорошего инструментария и того, как вы используете данные.
• Относитесь к трем столпам как к контрольному списку. Отдельные данные без возможности связать их заставляют искать информацию на вкладках. Общие идентификаторы имеют значение.
• Собираем всё. Нефильтрованная телеметрия обходится дорого и добавляет шума.
• Слишком много информационных панелей. Несколько доверенных просмотров превосходят сотню, которую никто не открывает.
• Думаю, что это заменяет тестирование. Тесты все равно нужны перед выпуском. Однако Canary-релизы хорошо сочетаются с этими сигналами.

Итоги

Мониторинг сообщает вам, что что-то пошло не так, а наблюдаемость дает вам возможность выяснить, почему. Практический тест прост: сможете ли вы найти причину, не отправляя новый код, при появлении незнакомой проблемы? В следующий раз, когда вы попадете в аварию, запишите все вопросы, на которые вы не смогли ответить. Этот список — ваша дорожная карта.

Часто задаваемые вопросы

Продолжайте учиться