Мониторинг веб-сервисов: метрики, журналы и трассировка на заказ

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

1. Оповещение называет симптом. Сработало правило «доля ошибок на оформлении заказа выше порога». Оно сразу говорит, что сломано для пользователя, а не какой диск заполнен.
2. Панель сужает область. Ошибки идут от одного маршрута и начались сразу после выкладки: отметка видна на графике. Время ответа базы в норме.
3. Трасса показывает шаг. Неудачный запрос дошёл до вызова внешней системы доставки и завершился по таймауту. Остальные шаги быстрые.
4. Журнал называет причину. По идентификатору запроса находим строки: в новой конфигурации указан старый порт внешней системы.
5. Решение и проверка. Откатываем конфигурацию, смотрим на график ошибок, записываем причину в журнал инцидентов.

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

Одна строка — одно событие с полями

Событие пишется структурой (например, JSON), а не предложением. В строке есть время, уровень, идентификатор запроса, название сервиса и версия, организация или пользователь в безопасной форме, код результата. Поиск «все ошибки одной организации за вчера» тогда выполняется запросом, а не чтением глазами.

Идентификатор запроса проходит через всё

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

Что не должно попадать в журнал

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

Мониторинг веб-сервиса встраивается в сам сервис и его окружение: сигналы, панели, правила. Принять чужую систему на постоянное обслуживание и разбирать инциденты — другая услуга, сопровождение ПО; на практике они идут вместе, но договор и пакет часов разные. Если сервис ещё не написан, наблюдаемость закладывается в разработку веб-сервиса с начала, и это дешевле.

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

Безопасность — отдельная тема. Журналы приложения помогают разбирать события, но не заменяют систему обнаружения вторжений; о защите кода — безопасная разработка веб-приложений. Порядок сигналов описан в статье «Что измерять в веб-сервисе».