Мониторинг Python-бэкенда на Prometheus: поймать сбой в 9:05, а не по звонку

Prometheus собирает метрики Python-бэкенда раз в 15 секунд и показывает, где мобильное приложение теряет запросы, раньше, чем позвонит клиент. Для старта хватит четырёх вещей: счётчика запросов с кодами ответа, гистограммы времени ответа, глубины очереди задач и возраста последней успешной синхронизации с 1С. Алерты строят по 95-му перцентилю и доле ошибок, потому что среднее время ответа прячет медленные запросы.

🕘 Понедельник, 9:05: сервер жив, заказы не уходят

Торговые представители оптовой компании открывают приложение за остатками и маршрутами на день. Экран крутится. Python-бэкенд отвечает на проверку «жив ли сервис», процессор свободен, мониторинг сервера зелёный. Но запросы за остатками встали в очередь Celery: воркеры ждут 1С, которая дообрабатывает ночной обмен. Поэтому таймаут в приложении срабатывает раньше, чем очередь доходит до этой задачи.

О проблеме поддержка узнаёт из звонков менеджеров и тратит утро на вопрос, кто виноват: приложение, бэкенд или 1С. Представитель на точке без остатков не оформляет заказ, и клиент может уйти к другому поставщику. Такой простой стоит выручки, а не только нервов.

Чем мониторинг приложения отличается от мониторинга сервера

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

📊 Какие метрики снимать с Python-бэкенда

Из четырёх типов метрик в библиотеке prometheus_client на практике хватает трёх.

• ✓Counter только растёт: число запросов по методу, маршруту и коду ответа, число ошибок обмена с 1С. Долю ошибок считают как отношение скорости роста ответов 5xx к скорости роста всех ответов.
• ✓Histogram раскладывает время ответа по корзинам. Корзины по умолчанию идут от 5 мс до 10 с, поэтому их подгоняют под реальный таймаут приложения, иначе все медленные запросы сольются в одну корзину «больше 10 секунд».
• ✓Gauge ходит вверх и вниз: длина очереди, занятые соединения пула к базе, возраст последней синхронизации.

Из гистограммы собирается 95-й перцентиль: функция histogram_quantile берёт корзины и считает, за какое время отвечают 95 запросов из 100. Среднее здесь не работает: быстрые ответы маскируют хвост зависших, а зависшие видит пользователь.

Метрика, которая закрывает сценарий понедельника

Самая полезная для мобильного клиента метрика не техническая. После каждого успешного обмена с 1С бэкенд записывает в Gauge текущее время методом set_to_current_time. Запрос time() минус это значение даёт возраст данных в секундах. Если остатки старше двух интервалов обмена, приложение показывает устаревшие цифры, хотя все процессы живы. Такой алерт сработал бы в 9:05 из нашей сцены.

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

🔧 Подключение prometheus_client: где ломается на практике

Prometheus работает по pull-модели: сам приходит на адрес /metrics каждого экземпляра и забирает значения. Для долгоживущего API это удобно. Ночной скрипт обмена, который запускается по cron и живёт недолго, этим способом не опросишь: он завершится раньше, чем придёт Prometheus. Для таких задач ставят Pushgateway, и скрипт отправляет туда итог перед выходом.

Несколько воркеров gunicorn

Каждый воркер gunicorn — отдельный процесс со своими счётчиками. Prometheus попадает на случайный воркер, и график скачет вверх и вниз при каждом опросе. Лечится multiprocess-режимом: каталог из переменной PROMETHEUS_MULTIPROC_DIR, сборка значений через MultiProcessCollector и очистка каталога при каждом перезапуске сервиса. Для Gauge задают multiprocess_mode, иначе библиотека не знает, как складывать значения разных воркеров.

Кардинальность меток

Каждая уникальная комбинация значений меток создаёт отдельный временной ряд в памяти Prometheus. В метку маршрута пишут шаблон /orders/{id}, а не /orders/48213. Идентификатор пользователя в метке за неделю раздувает базу метрик. Телефон или ФИО в метке — уже утечка персональных данных в систему, которую никто не считает хранилищем таких данных.

Готовые обёртки и нагрузка

Для Django есть django-prometheus, для FastAPI prometheus-fastapi-instrumentator. Они дают HTTP-метрики за несколько строк. Метрики обмена с 1С и очередей добавляют вручную: ни одна обёртка не знает, что для вашего бизнеса значит «синхронизация».

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

🔔 Алерты, которые будят по делу

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

Для бэкенда из нашего сценария хватает четырёх правил:

1. ✓95-й перцентиль времени ответа держится выше таймаута мобильного клиента.
2. ✓Доля ответов 5xx выше порога, который согласовали с бизнесом.
3. ✓Возраст последней синхронизации с 1С превышает два интервала обмена.
4. ✓Очередь растёт, а воркеры не снимают из неё задачи.

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

По умолчанию Prometheus хранит данные локально 15 дней. Чтобы сравнить закрытие месяца с прошлым кварталом, этого мало, поэтому крупные компании настраивают remote write во внешнее долговременное хранилище.

⚖️ Prometheus, логи или облачный APM: что выбрать

Четыре варианта, которые обсуждают чаще всего, сравниваем по трём вещам: что видно, кто нужен в команде и где слабое место.

Для бэкенда мобильного приложения с обменом с 1С мы берём вторую строку как основу. Метрики показывают, что и когда сломалось, а история за недели видна без подписки, которая дорожает с трафиком. Трассировку добавляют, когда метрики указали проблемное место, но не объяснили причину.

Отдельный вопрос — персональные данные. Трассировки и логи часто содержат телефоны, ФИО, адреса доставки. 152-ФЗ требует хранить базы с персональными данными граждан России на серверах в России, поэтому перед подключением зарубежного сервиса проверьте, куда он пишет данные.

🚀 Как это закладываем мы и сколько стоит

Мы проектируем бэкенд мобильного приложения сразу с адресом /metrics: HTTP-метрики, очередь задач, метрики обмена и дашборд под рабочие сценарии заказчика. Самое уязвимое место такого приложения — обмен с учётной системой, поэтому в проектах по интеграции приложения с 1С метрики обмена идут первыми. В B2B-приложении с 1С для торговых представителей это возраст остатков и время проведения заказа.

Если приложение делается с нуля, метрики закладываются в архитектуру, а не прикручиваются после первого сбоя. Разработка мобильных приложений стоит от 500 000 ₽. Если бэкенд уже работает, Prometheus, Grafana и Alertmanager подключает системный администратор: час работы стоит 3 800 ₽, ставки собраны на странице цены и тарифы. Сколько часов понадобится, зависит от числа сервисов и точек обмена. Срок называем после просмотра кода и инфраструктуры.

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

❓ Частые вопросы

Чем Prometheus отличается от обычного мониторинга сервера?

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

Сильно ли Prometheus нагружает Python-приложение?

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

Как мониторить Python-приложение на нескольких воркерах gunicorn?

Включите multiprocess-режим prometheus_client: задайте каталог в переменной PROMETHEUS_MULTIPROC_DIR, собирайте значения через MultiProcessCollector и очищайте каталог при каждом перезапуске сервиса. Для Gauge укажите multiprocess_mode. Без этого Prometheus попадает на случайный воркер, и графики скачут при каждом опросе.

Сколько стоит подключить мониторинг к уже работающему бэкенду?

Работа системного администратора стоит 3 800 ₽ в час. Число часов зависит от количества сервисов и точек обмена с учётной системой, поэтому срок называем после просмотра кода и инфраструктуры. Если мобильное приложение разрабатывается с нуля, метрики закладываются в архитектуру, а сама разработка стартует от 500 000 ₽.

Сколько хранит данные Prometheus и хватает ли этого?

По умолчанию Prometheus хранит данные локально 15 дней. Для разбора сбоя за прошлую неделю этого достаточно. Чтобы сравнить закрытие месяца с прошлым кварталом, срок хранения увеличивают параметром retention или передают данные через remote write в долговременное хранилище.