Пользователи
Это проверка storage-слоя. При включённом PostgreSQL данные пишутся в таблицу app_users.
Если PostgreSQL выключен или недоступен, backend использует memory fallback.
Отдельный frontend-проект
Чистый HTML/CSS/JS интерфейс для проверки backend, PostgreSQL, RabbitMQ, логов, health checks и инфраструктурных сценариев.
Frontend является отдельным проектом. Укажи адрес backend API без суффикса /api.
Текущий адрес: http://localhost:3000
Это проверка storage-слоя. При включённом PostgreSQL данные пишутся в таблицу app_users.
Если PostgreSQL выключен или недоступен, backend использует memory fallback.
Это учебная CRUD-сущность для проверки операций create/read/update/delete. При PostgreSQL используется
таблица app_tasks, без PostgreSQL — память процесса. Раздел удобен для проверки persistence,
backup/restore, миграций и прав на update/delete.
Это комбинированная проверка: событие сохраняется в storage app_events или memory store,
а затем публикуется в RabbitMQ exchange или memory bus. Раздел нужен для проверки связки backend + DB + MQ.
Эти кнопки не являются бизнес-функциями. Они нужны, чтобы руками создавать разные состояния приложения и проверять reverse proxy, firewall, CORS, health checks, readiness checks, логи, мониторинг, алерты, таймауты и поведение при отказах.
Что делает: показывает безопасную конфигурацию backend без секретов.
Зачем: проверить переменные окружения, режимы PostgreSQL/RabbitMQ, CORS, порт и лимиты probe.
GET /api/info
Что делает: проверяет, готов ли backend обслуживать трафик.
Зачем: тренировать readiness probe. Может вернуть 503, если обязательная DB или MQ недоступна.
GET /api/ready
Что делает: проверяет storage-слой: PostgreSQL или memory fallback.
Зачем: понять, подключился ли backend к PostgreSQL, и проверить сетевой доступ к БД.
GET /api/probe/db
Что делает: проверяет message bus: RabbitMQ или memory fallback.
Зачем: проверить подключение к RabbitMQ, exchange и поведение fallback-режима.
GET /api/probe/mq
Что делает: backend намеренно ждёт около 1 секунды перед ответом.
Зачем: проверять таймауты proxy, балансировщика, клиента, мониторинг latency и slow logs.
GET /api/probe/slow?ms=1000
Что делает: backend намеренно загружает CPU примерно на 300 мс.
Зачем: смотреть потребление CPU, реакцию мониторинга, autoscaling и деградацию под нагрузкой.
GET /api/probe/cpu?ms=300
Что делает: намеренно создаёт ошибку HTTP 500.
Зачем: проверять error logs, алерты, обработку 5xx на proxy и отображение ошибок во frontend.
GET /api/probe/error
Что делает: возвращает простые метрики в Prometheus-like text format.
Зачем: тренировать сбор метрик, scrape endpoint, dashboards и alert rules.
GET /api/metrics
Генерирует любой HTTP-код от 100 до 599. Удобно для проверки retry policy, health checks, proxy rules и алертов.
GET /api/probe/status/:code
Пишет structured JSON log на backend. Удобно для проверки stdout, journald, log shipper, log manager, фильтров и уровней логирования.
POST /api/probe/log
Возвращает method, path, headers и body, которые дошли до backend. Удобно для проверки reverse proxy, CORS, request headers и x-request-id.
POST /api/probe/echo
Раздел про БД/storage. Создание и чтение пользователей проверяет таблицу app_users в PostgreSQL
или memory fallback, если БД не подключена.
Раздел про CRUD и состояние данных. Здесь можно создать задачу, переключить completed и удалить её.
В PostgreSQL это таблица app_tasks; без БД данные живут только в памяти backend-процесса.
Раздел одновременно про storage и message bus. Создание события сохраняет его в PostgreSQL app_events
или memory store, а затем публикует сообщение в RabbitMQ или memory bus.