В веб-сервисе измеряют четыре величины на каждый важный маршрут: сколько запросов приходит, какая доля из них заканчивается ошибкой, сколько времени идёт ответ и насколько загружены ресурсы, от которых он зависит (потоки приложения, соединения с базой, очередь). Это метрики. Для разбора конкретного случая к ним добавляют журналы с общим идентификатором запроса, а для сервисов из нескольких частей ещё и трассы.
Три сигнала не взаимозаменяемы: метрики дёшевы и показывают тенденцию, журналы дороже и показывают подробности, трассы связывают шаги цепочки. Ниже порядок выбора, который не зависит от конкретных инструментов. Как это делаем мы в проектах, описано на странице «Мониторинг и наблюдаемость веб-сервисов».
Три сигнала: какой на какой вопрос отвечает
Любой сигнал отвечает на свой вопрос. Если спрашивать не у того, получится или дорого, или бесполезно.
| Сигнал | Лучше всего отвечает | Что стоит хранить | Для чего не годится |
|---|---|---|---|
| Метрики | Есть ли проблема сейчас и как она менялась за последние часы | Числа с метками, собранные через равные промежутки времени | Разбор одного запроса: в числе нет подробностей о том, что случилось с конкретным заказом |
| Журналы | Что произошло с конкретным запросом или пользователем | События с полями: время, уровень, идентификатор запроса, код ошибки | Тенденции по большим объёмам: считать по текстовым строкам долго и дорого |
| Трассы | Где в цепочке вызовов потеряно время или произошла ошибка | Дерево шагов одного запроса с длительностью каждого | Простые сервисы: в одном процессе то же самое видно из журнала |
| События изменений | Что менялось перед началом проблемы | Версия, время выкладки, смена конфигурации, перезапуск | Самостоятельная диагностика: события только подсказывают, куда смотреть |
Сигналы связываются между собой: на графике метрик виден всплеск ошибок, по времени и маршруту открывается журнал, по идентификатору запроса из журнала открывается трасса. Если связи нет, сигналы остаются отдельными картинками и поиск причины превращается в сопоставление времени вручную.
Четыре величины, которые нужны всегда
Для каждого ключевого маршрута достаточно четырёх величин, и они подходят и к сайту, и к API, и к фоновому обработчику.
- Поток. Сколько запросов или сообщений приходит в единицу времени. Резкое падение потока без ошибок часто значит, что до сервиса просто не доходят пользователи: сломан вход, DNS или соседняя система.
- Ошибки. Доля запросов, закончившихся неудачей с точки зрения пользователя. Считайте и ответы с кодом ошибки, и ответы, которые «успешны», но с пустым или неверным содержанием, если вы можете их распознать.
- Время ответа. Распределение, а не среднее. Среднее скрывает медленный хвост: если десятая часть пользователей ждёт долго, среднее остаётся приемлемым. Смотрят высокие процентили, например девяносто пятый и девяносто девятый.
- Насыщение. Насколько заполнен ресурс, который ограничивает сервис: пул соединений с базой, число рабочих процессов, длина очереди, свободное место. Это сигнал заранее: сервис ещё работает, но запас кончается.
Их применяют к каждому уровню: маршрут сервиса, база данных, очередь, каждая внешняя система. Так получается перечень из нескольких десятков метрик, а не из нескольких сотен, и каждую из них можно объяснить. Тонкости, как задавать пороги и что считать нормой, зависят от вашей нагрузки; общий принцип «порог выше обычного поведения, но ниже поломки» работает после недели наблюдений, а не из таблицы.
Отдельно измеряйте то, ради чего сервис существует: число оформленных заказов, регистраций, платежей в час. Если эти бизнес-показатели упали, а ошибок в журнале нет, поломка видна только им.
Метрики: как не раздуть хранилище
У метрики есть название и метки (маршрут, код ответа, версия). Каждое сочетание значений меток создаёт отдельный ряд, поэтому хранилище растёт не от числа метрик, а от числа сочетаний.
| Решение | Как делают плохо | Как делают хорошо | Что получаете |
|---|---|---|---|
| Метки | Идентификатор пользователя или заказа в метке | Только значения из небольшого известного набора: маршрут, код, название системы | Предсказуемый объём и быстрые панели; подробности по одному заказу ищутся в журнале |
| Время ответа | Одна метрика «среднее время» | Гистограмма с границами, подобранными под ваш сервис, и высокие процентили | Видно медленный хвост и можно сравнивать с целью |
| Маршруты | Полный адрес с идентификатором в пути | Шаблон маршрута: «заказ по номеру» вместо каждого номера | Один ряд на маршрут, а не по ряду на каждый заказ |
| Сроки хранения | Всё одинаково долго | Подробные данные недолго, сжатые значения дольше | Можно сравнить с прошлым месяцем, не храня всё подробно |
Проверка простая: прикиньте произведение числа значений каждой метки. Если оно растёт с числом клиентов или заказов, метку пора убрать.
Журналы: что писать и чего не писать
Журнал нужен для поиска, поэтому каждая строка должна быть событием с полями, а не предложением. Минимальный состав: время, уровень, идентификатор запроса, название сервиса, версия, организация или пользователь в безопасной форме, код результата и короткое описание.
- Один идентификатор на запрос. Его создаёт первая точка входа и передаёт дальше в заголовке вызова и в поле сообщения очереди. Верните его пользователю в ответе при ошибке: по нему поддержка найдёт запись без расспросов.
- Уровни по смыслу. Ошибка — сценарий не выполнен. Предупреждение — система справилась, но что-то не так. Информация — обычный ход. Если «ошибками» помечено всё подряд, по уровню уже нельзя искать.
- Одно событие — одна запись. Не пишите по десять строк на один запрос и не пишите записи в цикле по каждому элементу списка.
- Чувствительное не пишем. Пароли, токены, ключи, данные карт и персональные данные вырезаются фильтром на уровне библиотеки журналирования. Записи о действиях пользователей для расследований ведутся отдельно, в журнале аудита.
- Сроки и объём. Подробные записи хранятся недолго, записи об ошибках дольше. Объём измеряйте: резкий рост журнала часто сигнализирует об ошибке, которая повторяется на каждом запросе.
Порядок хранения записей, имеющих юридическое значение, определяет юрист заказчика; технические меры (отдельный доступ, защита от изменения) описаны на странице «Защита персональных данных в веб-приложениях».
Трассы: когда нужны и как не платить за лишнее
Трасса — это запись пути одного запроса через сервисы, очередь и базу, где у каждого шага есть начало и длительность. Она отвечает на вопрос, который журнал отдельно взятого сервиса задать не может: где именно в цепочке ушло время.
| Ситуация | Нужна ли трассировка | Чем обходимся | Что проверить |
|---|---|---|---|
| Один процесс, одна база | Обычно нет | Журнал с идентификатором, метрики по маршрутам, журнал медленных запросов базы | Находятся ли медленные места без трассировки |
| Приложение и фоновые обработчики через очередь | Иногда | Идентификатор в сообщении очереди и метрики возраста сообщений | Теряется ли идентификатор при постановке в очередь |
| Несколько сервисов, вызывающих друг друга | Да | Выборочная трассировка с сохранением всех ошибок и медленных запросов | Проходит ли идентификатор через каждый вызов |
| Цепочка вызовов во внешние системы | Для своей стороны | Метрики по каждой системе: чужой стороны вы не увидите | Записывается ли время ожидания ответа от каждой системы |
Хранить все трассы незачем. Распространённая схема: сохранять небольшую долю запросов случайно, плюс все запросы с ошибкой и все запросы дольше порога. Так хранилище остаётся небольшим, а интересные случаи не теряются.
Оповещения: по симптомам, а не по причинам
Оповещение — это просьба оторвать человека от работы. Её оправдывает только проблема, которую человек может и должен решить сейчас.
| Тип правила | Пример | Кому и как срочно | Чем плохо |
|---|---|---|---|
| Симптом для пользователя | Доля ошибок на оформлении заказа выше порога | Дежурному сразу | Почти ничем; порог придётся подбирать по неделе наблюдений |
| Заканчивающийся запас | Диск заполнится в течение суток | В рабочее время, в общий список | Ночью будить не стоит: у вас ещё есть время |
| Причина без симптома | Процессор нагружен | Панель, не оповещение | Часто ложно: нагрузка бывает нормальной |
| Отсутствие данных | Метрики перестали приходить | Дежурному сразу | Без такого правила сломанный сбор выглядит как «всё спокойно» |
К каждому правилу прикладывают три вещи: что сломано для пользователя, кто отвечает и что проверить первым. Правило без владельца удаляют. Раз в квартал полезно устроить учение: нарочно сломать стенд и проверить, сработали ли правила, дошло ли сообщение и понял ли получатель, что делать.
Не путайте оповещения с мониторингом безопасности. Сигналы сервиса показывают, что он работает или нет, но не заменяют системы обнаружения вторжений.
Минимум на первую неделю
Если у сервиса пока ничего нет, начните с этого списка. Он выполним командой разработки без отдельных инструментов, а потом расширяется.
- Выпишите три-пять пользовательских сценариев, потеря которых вам важнее всего (вход, оформление, оплата).
- Настройте проверку этих сценариев снаружи с интервалом в минуту: она отвечает «работает ли для пользователя», пока остальное не готово.
- Включите четыре величины на этих маршрутах: поток, ошибки, время ответа с процентилями, насыщение пула соединений с базой.
- Приведите журнал к структуре и добавьте идентификатор запроса, затем покажите его пользователю в сообщении об ошибке.
- Добавьте отметку выкладки на графики: версия и время.
- Заведите два оповещения: доля ошибок на главном сценарии и пропавшие данные. Назначьте владельца каждому.
- Через неделю посмотрите, какие вопросы по сбоям вы задавали вслух и на какие не нашли ответа в сигналах. Это список следующих шагов.
Мониторинг только на бумаге: признаки
Панели могут быть красивыми и бесполезными. Проверьте себя по таблице.
| Признак | Что за ним стоит | Что спросить у команды |
|---|---|---|
| О сбоях узнают от пользователей | Проверки смотрят на узлы, а не на сценарии | Какое правило должно было сработать на последней поломке и почему не сработало |
| Причину ищут по чатам и серверам | Нет идентификатора запроса и единого места для журналов | Сколько шагов от обращения клиента до строки журнала |
| Оповещения отключили или не читают | Ложные срабатывания и правила без владельца | Какая доля тревог за месяц привела к действию |
| После выкладки неясно, стало ли лучше | Нет отметок выкладки и сравнения с прошлой версией | Откуда известно, что новая версия не ухудшила время ответа |
| Хранилище растёт быстрее нагрузки | Лишние метки или запись всего подряд | Какие метки имеют неограниченное число значений |
| Никто не проверял, что система тревог сама жива | Нет правила на пропажу данных и нет учений | Когда последний раз оповещение проверяли нарочно |
Что делаем мы и с чего начать
Начинаем с обследования: 200 000 ₽ и 2–3 недели за один сервис, 350 000 ₽ и 3–4 недели, если вокруг него несколько систем. На выходе перечень сценариев, карта слепых зон, цели и порядок реакции, план внедрения сигналов и вилка бюджета. Стоимость вычитается из первого этапа, если продолжаете с нами.
Дальше лёгкий пилот на одном сервисе (150 000–400 000 ₽, 2–8 недель) или тяжёлый со сквозной трассировкой (400 000–1 200 000 ₽, 2–3 месяца). Всё хранится на ваших серверах, настройки лежат в вашем репозитории. Мы не оказываем услуги SIEM и не дежурим круглосуточно: помесячное сопровождение — 20 000 / 60 000 / 120 000 ₽ в месяц, сверх пакета 5 000 ₽ в час. Цены и сроки — на странице «Тарифы», описание услуги — на странице «Мониторинг и наблюдаемость веб-сервисов».
Частые вопросы
Чем метрики отличаются от логов?
Метрики — числа во времени: сколько запросов, какая доля ошибок. Они показывают, есть ли проблема. Логи (журналы) — записи о событиях с подробностями: что произошло с конкретным запросом. Метрики дёшевы и годятся для оповещений, журналы нужны для разбора.
Что такое трассировка простыми словами?
Это запись пути одного запроса через несколько сервисов, очередь и базу с длительностью каждого шага. По ней видно, где именно потеряно время. Одному сервису в одном процессе она обычно не нужна.
Какие метрики обязательны для любого веб-сервиса?
Четыре величины на ключевых маршрутах: поток запросов, доля ошибок, распределение времени ответа и насыщение ресурсов (соединения с базой, очередь, место). К ним добавляют бизнес-показатели: число заказов или платежей в час.
Почему нельзя смотреть только среднее время ответа?
Среднее скрывает медленный хвост. Если небольшая часть пользователей ждёт долго, среднее остаётся приемлемым, а жалобы идут. Смотрите высокие процентили, например девяносто пятый и девяносто девятый.
Сколько хранить журналы и метрики?
Зависит от задач: подробные данные нужны недолго, для разбора свежих инцидентов, сжатые метрики хранят дольше, чтобы сравнивать периоды. Сроки для записей с юридическим значением определяет юрист заказчика.
Нужен ли отдельный инструмент или хватит того, что есть?
Для небольшого сервиса достаточно структурных журналов, метрик приложения и проверки сценариев снаружи. Отдельное хранилище и трассировка нужны, когда сервисов несколько и объём растёт. Начинать с набора инструментов вместо вопросов — типичная ошибка.
Можно ли хранить метрики и журналы в закрытом контуре?
Да, все основные инструменты разворачиваются на своих серверах. Для данных ограниченного доступа внешние облачные панели обычно не подходят по требованиям заказчика, поэтому мы настраиваем хранилища внутри вашего контура.
Заменяют ли метрики и журналы систему безопасности?
Нет. Они показывают работу сервиса, а не атаки. Системы обнаружения вторжений и корреляции событий безопасности — другая задача, и услуг SIEM мы не оказываем. Журналы приложения могут служить для них источником.