Мониторинг проверял главную страницу, а лежала оплата

MAATRIX

Дашборд мониторинга был весь зелёный: сайт открывался, сервер отвечал, аптайм за месяц — 99,98%. А в это время покупатели по полчаса крутили спиннер на кнопке «Оплатить» и уходили. Разница между «сайт жив» и «бизнес работает» — это ровно та щель, в которую проваливаются самые обидные инциденты. Разберём по шагам, что мы видели, какие версии отбросили и в чём была настоящая причина.

Что увидели: тишина мониторинга и растущая очередь жалоб

Первый сигнал пришёл не из мониторинга, а из чата поддержки: три обращения подряд с формулировкой «не могу оплатить заказ, кнопка крутится и ничего не происходит». Дежурный админ первым делом открыл дашборд Uptime Kuma — там всё было ровно и зелёно, последняя проверка главной страницы прошла 40 секунд назад с кодом 200.

Открыли Grafana с бизнес-метриками (количество успешных заказов в час, отдельная панель, которую в компании смотрели раз в день, а не в реальном времени) — и там график с 13:50 упал почти в ноль. При этом панель с общим числом запросов к nginx оставалась на обычном уровне: пользователи заходили, листали каталог, но не могли завершить оплату.

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

Проверка в мониторинге выглядела примерно так:

{
  "type": "http",
  "url": "https://shop.example.com/",
  "method": "GET",
  "interval": 60,
  "expectedStatusCodes": [200]
}

Она честно делает то, что в неё заложено: раз в минуту забирает главную страницу и проверяет код ответа. К оплате, которая живёт на отдельном эндпоинте /api/payment/create и обслуживается отдельным процессом, эта проверка не имеет никакого отношения.

Первая гипотеза: виноват платёжный шлюз

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

Проверили статус-страницу платёжного провайдера — все системы зелёные, инцидентов не заявлено. Написали в чат поддержки провайдера с вопросом, есть ли проблемы с приёмом запросов от нашего мерчант-аккаунта — получили ответ, что за последний час от нашего идентификатора запросов не поступало вообще. Это важная деталь: не «получали и отклоняли», а «не получали». Значит, проблема раньше, чем запрос долетает до банка.

Заодно проверили логи исходящих запросов на своей стороне:

grep "payment/create" /var/log/app/payment-service.log | tail -n 50

Файл лога не обновлялся почти час — последняя строка датирована 13:52. Процесс либо не получает запросы, либо не пишет логи, либо не работает вовсе. Версия про шлюз отпала: до шлюза дело просто не доходило.

Вторая и третья гипотезы: кеш CDN и правило файрвола

Вторая версия — устаревший кеш CDN отдаёт клиентам старую версию страницы оформления заказа, из-за которой форма шлёт запросы не туда. У сайта действительно настроен CDN перед бэкендом, и с кешированием на проекте раньше уже бывали сюрпризы.

Проверили заголовки ответа для страницы оформления:

curl -sI https://shop.example.com/checkout | grep -i cache

cache-control: no-store, no-cache, must-revalidate
x-cache-status: BYPASS

Страница оформления заказа и API платежей изначально исключены из кеширования правилом в конфиге CDN — это специально настраивали раньше именно из-за похожего случая. Версия с кешем отпала за пять минут.

Третья версия — новое правило файрвола или fail2ban заблокировало IP-диапазон, из которого шли запросы к /api/payment/create. Проверили:

sudo iptables -L -n | grep -i drop
sudo fail2ban-client status nginx-req-limit
journalctl -u fail2ban --since "14:00" | grep -i ban

Ни одной свежей блокировки, связанной с нужным путём или диапазоном IP, не нашли. Правила файрвола не менялись со вчерашнего дня, а бан-лист пуст. Три версии отброшены за 20 минут — и это нормальная часть разбора инцидента: дешёвые гипотезы проверяются первыми именно потому, что их легко закрыть и не тратить время дальше.

Что показали логи и systemd

Раз проблема не на стороне шлюза, кеша и файрвола, а лог платёжного сервиса молчит — логично посмотреть на сам процесс. Сервис оплаты вынесен в отдельный systemd-юнит, за него отвечает nginx как reverse proxy на upstream 127.0.0.1:4010.

sudo systemctl status payment.service

● payment.service - Payment processing service
     Loaded: loaded (/etc/systemd/system/payment.service; enabled)
     Active: failed (Result: start-limit-hit) since Tue 2026-08-25 13:52:41 UTC; 47min ago
    Process: 18422 ExecStart=/usr/bin/node /opt/app/payment/server.js (code=killed, signal=KILL)

Вот она, разгадка в одну строку: failed (Result: start-limit-hit). Сервис не просто упал — он упал, systemd честно попытался его перезапустить несколько раз подряд, уткнулся в лимит перезапусков, признал юнит окончательно неисправным и прекратил попытки. С 13:52 процесс просто не существовал, и никто не пытался поднять его руками, потому что никто не знал, что он лежит.

Посмотрели, что было до этого:

journalctl -u payment.service --since "13:40" --until "13:53"

13:47:02 payment.service: server.js: unhandled promise rejection in retryAcquirerCall()
13:48:15 kernel: Out of memory: Killed process 18391 (node) total-vm:2874112kB, anon-rss:1972340kB
13:48:16 systemd: payment.service: Main process exited, code=killed, status=9/KILL
13:48:16 systemd: payment.service: Scheduled restart job, restart counter is at 3.
13:49:40 kernel: Out of memory: Killed process 18405 (node) total-vm:2861004kB, anon-rss:1968012kB
13:50:55 kernel: Out of memory: Killed process 18414 (node) total-vm:2855776kB, anon-rss:1954880kB
13:52:41 systemd: payment.service: Start request repeated too quickly.
13:52:41 systemd: payment.service: Failed with result 'start-limit-hit'.

Картина сложилась. В 13:47 выкатили небольшой релиз с изменением логики повторных запросов к эквайринговому API (retryAcquirerCall) — при определённых сетевых таймаутах функция уходила в повторные вызовы без ограничения глубины и без освобождения ссылок на предыдущие попытки, из-за чего память процесса Node.js быстро росла. Через пять минут под нагрузкой обычных дневных заказов процесс упирался в потолок памяти контейнера, ядерный OOM-killer убивал его, systemd поднимал заново — и цикл повторялся, пока не сработал лимит StartLimitBurst (по умолчанию 5 попыток за 10 секунд в современных дистрибутивах).

Настоящая причина: незаметный сбой и мониторинг, который об этом не спросили

Итоговая причинно-следственная цепочка выглядит так:

1. Релиз в 13:47 внёс баг в логику ретраев к API эквайера — при таймауте функция рекурсивно повторяла вызов без ограничения и без очистки памяти.
2. Память процесса payment.service росла за минуты, ядро убивало процесс через OOM-killer.
3. systemd честно перезапускал сервис несколько раз подряд и, упёршись в StartLimitBurst, перевёл юнит в failed, прекратив попытки без какого-либо внешнего уведомления.
4. nginx как reverse proxy на упавший upstream отвечал 502 Bad Gateway только на пути /api/payment/* — но именно это никто не проверял.
5. Проверка мониторинга ходила на /, которую отдавал совершенно другой, живой и здоровый процесс (статический фронтенд), поэтому статус оставался зелёным всё это время.

Ни одна из отдельных частей системы не соврала. OOM-killer сделал ровно то, для чего он существует — защитил хост от исчерпания памяти. systemd сделал ровно то, что написано в его юните, — попытался восстановить сервис и остановился, чтобы не долбить систему бесконечными рестартами мёртвого процесса. Мониторинг тоже не соврал: страница действительно отдавала 200. Проблема была не в поломке отдельного компонента, а в том, что ни один из них не был обязан заметить и сообщить о падении именно платёжного пути — а никто не настроил отдельную проверку для него.

Полезно сравнить, что видел каждый уровень наблюдения в момент инцидента:

Именно средняя строка — состояние systemd-юнита — оказалась самым дешёвым и самым быстрым индикатором, но она не была подключена ни к какому алертингу.

Что изменили после инцидента

Первым делом руками перезапустили сервис и сбросили счётчик отказов:

sudo systemctl reset-failed payment.service
sudo systemctl restart payment.service
sudo systemctl status payment.service

Дальше — три группы изменений, каждая закрывает свою дыру в наблюдаемости.

Синтетическая проверка критичного пути, а не только факта ответа сервера. Добавили в Uptime Kuma отдельный монитор с фактическим прогоном запроса к /api/payment/health — эндпоинту, который сервис оплаты сам открывает и который в реальном времени проверяет доступность своей БД-очереди и факт готовности принимать запросы (не настоящий платёж, а лёгкая внутренняя проверка готовности):

{
  "type": "http",
  "url": "https://shop.example.com/api/payment/health",
  "method": "GET",
  "interval": 30,
  "expectedStatusCodes": [200],
  "keyword": "\"status\":\"ready\""
}

Проверка не только смотрит на код ответа, но и ищет конкретную строку в теле — это отсекает ситуацию, когда какой-нибудь общий обработчик ошибок начнёт отдавать 200 с телом «упс».

Алерт на состояние systemd-юнита, а не только на HTTP. Через node_exporter со включённым --collector.systemd состояние юнита стало метрикой Prometheus, и на неё завели простое правило:

- alert: PaymentServiceDown
  expr: node_systemd_unit_state{name="payment.service", state="failed"} == 1
  for: 1m
  labels:
    severity: critical
  annotations:
    summary: "payment.service в состоянии failed"

Это перекрывает как раз тот случай, когда процесс лежит мёртвым и systemd уже даже не пытается его поднять — раньше об этом не узнавал вообще никто, кроме того, кто вручную зайдёт и наберёт systemctl status.

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

[Service]
MemoryMax=1500M
MemoryHigh=1200M
Restart=on-failure
RestartSec=5
StartLimitIntervalSec=60
StartLimitBurst=5

MemoryHigh заставляет ядро активнее подрезать процесс через управление cgroup ещё до жёсткого килла, а метрика потребления памяти процесса теперь тоже смотрится в Grafana с алертом при приближении к MemoryMax, чтобы утечка была видна за минуты до того, как дело дойдёт до OOM-killer.

Отдельно договорились, что бизнес-метрика заказов в час переезжает из панели «смотрим раз в день» в панель с алертом: падение больше чем на 50% относительно скользящего среднего за предыдущий час — повод для срабатывания дежурному, независимо от того, что показывает инфраструктурный мониторинг. Это тот случай, когда мониторинг доступности сайта технически работал безупречно, но не отвечал на главный вопрос бизнеса: зарабатывает ли сайт деньги прямо сейчас.

Похожая по сути ловушка разбиралась и в другом случае, когда healthcheck проверял не тот показатель, а контейнер продолжал считаться живым — тот же принцип: проверка отвечает буквально на заданный ей вопрос, и если вопрос сформулирован узко, широкая проблема пройдёт мимо. Общий антипаттерн, в который часто вырастает такая настройка мониторинга «для галочки», разобран в статье про мониторинг, на который никто на самом деле не смотрит — в нашем случае дашборд как раз смотрели, просто он не был настроен задавать нужный вопрос.

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