NPPWEB Docs

Диагностика и Runbook ​

Этот раздел нужен для повседневной эксплуатации платформы: когда данные не доезжают, экраны пустеют, источники начинают публиковать 0, а пайплайн выглядит “живым”, но результата почти нет.

Как мыслить о проблемах в NPPWEB ​

Почти любую проблему удобно разбирать по четырём слоям:

  1. Доступ к внешнему источнику — площадка недоступна, требует proxy, изменила HTML или API.
  2. Сбор и транспорт — scrape-helper не собирает карточки или не публикует raw-события.
  3. Нормализация и ingest — processing-worker не может преобразовать payload или отправить его в backend.
  4. Домен и аналитика — backend принял данные, но UI-срез почти пуст из-за фильтров, связей или бизнес-логики.

Эта последовательность важна: не стоит начинать с frontend, если SourceRun уже показывает FAILED, и не стоит переписывать парсер, если проблема в том, что аналитика читает только часть уже собранных сущностей.

Быстрая triage-проверка ​

1. Живы ли контейнеры ​

bash
cd infra
docker compose --env-file .env -f docker-compose.yml -f docker-compose.apps.yml ps

Обычно ожидается:

  • postgres, rabbitmq, minio, backend-api, frontend — healthy
  • processing-worker, scraper-service — Up
  • minio-init — Exited (0)

2. Жив ли backend ​

bash
curl http://localhost:3000/api/health
curl http://localhost:3000/api/health/ready

Если backend не готов, дальнейшая диагностика аналитики бессмысленна: worker не сможет сделать ingest, а frontend не сможет получить GraphQL.

3. Жив ли scraper control-plane ​

bash
curl http://localhost:3001/health
curl http://localhost:3001/api/runtime-status

Эти endpoints помогают понять:

  • видит ли backend scraper-service;
  • какие источники реально загружены;
  • не открыт ли circuit breaker;
  • не отключён ли autoRunEnabled.

4. Есть ли движение в очередях ​

RabbitMQ management обычно доступен на http://localhost:15672.

Особенно полезно смотреть очереди:

  • source.raw.v1
  • source.raw.retry.v1
  • source.raw.dlq.v1
  • source.normalized.v1

Если source.raw.v1 пустая и не растёт, проблема ближе к scrape-helper. Если raw есть, но ingest не происходит, проблема ближе к processing-worker или backend.

Главные симптомы и как их читать ​

Источник запускается, но собирает 0 ​

Смотреть в таком порядке:

  1. SourceRun.errorMessage и статус запуска.
  2. Логи scrape-helper.
  3. Прямой доступ к площадке из текущего контура.
  4. Не стали ли фильтры источника слишком узкими.

Типичные причины:

  • площадка не отвечает без HTTPS_PROXY;
  • источник поменял HTML или API;
  • поиск возвращает данные, но внутренняя фильтрация считает их нерелевантными;
  • лимит MAX_ITEMS слишком маленький, и в выборку не попадают нужные записи;
  • нужный источник вообще не включён в ENABLED_SOURCES.

Есть SUCCESS, но аналитика пустая ​

Это особенно частый случай и он не означает, что пайплайн полностью сломан.

Проверять нужно:

  1. что itemsDiscovered > 0;
  2. что itemsPublished > 0;
  3. какие сущности реально создаются в backend;
  4. не опирается ли экран только на часть доменной модели.

Примеры:

  • экран поставщиков может зависеть только от Procurement с уже заполненным supplierId;
  • RNP и FNS могут успешно пополнять свои собственные таблицы, но не участвовать в конкретном аналитическом срезе;
  • Fedresurs может ломать watchlist поставщиков, даже если закупочный контур сам по себе жив.

Массовые connect timeout или fetch failed ​

Это почти всегда сетевой вопрос.

Проверить:

  • заданы ли HTTP_PROXY и HTTPS_PROXY;
  • совпадает ли NO_PROXY с внутренними сервисами;
  • включён ли профиль proxy в deploy-контуре;
  • есть ли xray-local/config.json, если используется xray-proxy.

Если proxy указан, но сам контейнер не поднят, scrape-helper начнёт массово падать на всех внешних площадках.

HTTP 434 или 403 от zakupki.gov.ru ​

Это обычно признак того, что площадка режет автоматизированный доступ.

Полезно проверить:

  • проходит ли трафик через корректный proxy-маршрут;
  • не устарели ли HTTP-заголовки запроса;
  • не изменилась ли поисковая выдача;
  • не сработал ли circuit breaker после серии ошибок.

Fedresurs стабильно падает ​

Для Fedresurs нужно помнить, что публичный HTML-список больше не является надёжным способом сбора.

Production-сценарий теперь такой:

  • задать FEDRESURS_API_URL;
  • задать FEDRESURS_API_LOGIN;
  • задать FEDRESURS_API_PASSWORD;
  • проверять, что API действительно возвращает сообщения за расчётное окно.

Если логин и пароль не заданы, ждать устойчивого наполнения через HTML уже не стоит.

Полезные команды ​

Compose logs ​

bash
cd infra
docker compose --env-file .env -f docker-compose.yml -f docker-compose.apps.yml logs backend-api processing-worker scraper-service frontend

Для длительной диагностики:

bash
docker compose --env-file .env -f docker-compose.yml -f docker-compose.apps.yml logs -f scraper-service processing-worker backend-api

Ручной запуск конкретного источника ​

bash
curl -X POST http://localhost:3001/api/source-runs \
  -H 'content-type: application/json' \
  -d '{"sourceCodes":["eis","rnp"]}'

Так удобнее изолировать проблему по одному или двум адаптерам, не дожидаясь общего cron-цикла.

Проверка runtime scraper-service ​

bash
curl http://localhost:3001/api/runtime-config
curl http://localhost:3001/api/runtime-status

Это помогает увидеть:

  • текущее cron-расписание;
  • флаг autoRunEnabled;
  • список реально загруженных источников;
  • активные запуски;
  • circuit breaker states.

Если проблема похожа на data-gap, а не на outage ​

Когда система технически здорова, но бизнес-экраны пустоваты, полезно проверить:

  1. какие источники реально формируют конкретный экран;
  2. из каких таблиц и сущностей backend собирает агрегаты;
  3. не требуется ли связь supplierId, riskSignals или другое доменное обогащение;
  4. не узок ли аналитический период, например last90Days.

То есть вопрос часто звучит не как “почему сервис упал”, а как “почему экран использует только малую часть уже существующих данных”.

Рекомендованный порядок действий при инциденте ​

  1. Подтвердить симптом на UI или в SourceRun.
  2. Проверить health основных сервисов.
  3. Проверить runtime scraper-service.
  4. Посмотреть compose logs.
  5. Отделить outage внешнего источника от пустой аналитики.
  6. Зафиксировать точку потери данных: collect, publish raw, normalize, ingest, aggregate, render.
  7. Только после этого вносить кодовые изменения.

Куда идти дальше ​

Техническая и аналитическая документация платформы NPPWEB.

NPPWEB