Надёжность и эксплуатация

Индикаторы уровня обслуживания, дашборды и оповещения, что ограничено и сверяется, плавная деградация и рекомендации по ёмкости для установки на одном сервере

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

​

Индикаторы уровня обслуживания

Определены для каждой поверхности в Здоровье, метрики и логи, опираются только на метрики, реально существующие. У уведомлений сегодня нет индикатора — метрики доставки не существует, чтобы его построить; это сказано там, а не выдумано здесь.

​

Дашборды и оповещения

Omniflow не поставляет собственный Prometheus или Grafana — та же позиция, что и в отношении обратного прокси: два поддерживаемых, но необязательных артефакта лежат в deploy/observability/, чтобы вы импортировали их в собственный стек мониторинга.

• deploy/observability/prometheus-alerts.yml — каждый пункт из Оповещений, которые стоит настроить в виде настоящего правила alert:/expr:/for:. Длительности for: — разумные значения по умолчанию, выведенные из собственных значений по умолчанию APP_MAINTENANCE_FAILURE_STREAK и APP_MAINTENANCE_PROBE_SECONDS — настройте их под фактическую конфигурацию вашей установки, если вы их меняли.
• deploy/observability/grafana-dashboard.json — частота HTTP-запросов, частота ошибок и задержка; исходы задач выдачи доступа; классификации расчётов по платежам; сбои проверки подписи webhook; состояние здоровья зависимостей; состояние режима обслуживания. Каждая панель построена на метрике, которую Здоровье, метрики и логи подтверждает как реально пишущуюся — ни одна панель не обращается к мёртвому ряду.

Импортируйте оба файла через promtool / импорт дашбордов Grafana, указав на то, что снимает /metrics с api и worker в вашем развёртывании.

​

Внешние побочные эффекты: повторы, недоставленные задачи, сверка

Побочный эффект	Повтор / отсрочка	Видимость недоставленных	Сверка
Выдача доступа Remnawave	До 12 попыток, экспоненциальная отсрочка	GET /v1/admin/jobs?state=dead_letter, экран Jobs в панели	Плановые операции reconcile сравнивают локальное желаемое состояние с тем, что сообщает Remnawave, и записывают расхождение — Задачи и очереди
Доставка цифровых товаров	Та же политика повторов на River, что и у выдачи доступа	Тот же экран недоставленных	Идемпотентность по строке goods_deliveries; шлюз без ключа идемпотентности откладывается на ревизию оператора, а не повторяется вслепую — Задачи и очереди
Платёжные webhook	Подпись провайдера проверяется, дедупликация по ID события	/admin → System → Webhooks	Сверятель раз в минуту опрашивает до 100 платежей в процессе, поэтому пропущенный или задержанный webhook всё равно расчитывается — Платёжные провайдеры
Отправки Telegram	Повтор, обработка flood-wait и классификация сбоев доставки (поставлено в v0.4)	Не ряд Prometheus — omniflow_telegram_sends_total объявлена, но никогда не увеличивается	Ничего сверх повтора на отправку; сверять очередь не с чем
Транзакционный outbox (order.paid, wallet.credited, addon.purchased)	Н/Д	GET /v1/admin/outbox, вкладка Outbox в панели	Сегодня потребителя не существует — Задачи и очереди. Это честное исключение: сейчас ничто не читает эти события, поэтому нет внешнего побочного эффекта, который нужно ограничивать повтором/недоставленными/сверкой. Строки удаляются воркером очистки по срокам хранения независимо от того, прочитал ли их кто-нибудь, так что это отсутствующая точка интеграции, а не риск неограниченного роста

​

Плавная деградация

Зависимость	Что происходит при недоступности
PostgreSQL	Отслеживается автоматическим определением обслуживания; после серии отказов новые покупки приостанавливаются, а расчёты, возвраты и чтение продолжают работать
Remnawave	То же определение обслуживания; отозванный или истёкший токен панели тоже считается недоступностью, поскольку выдача доступа всё равно бы провалилась
Valkey	То же определение обслуживания. До достижения этой серии отказов ограничение частоты запросов и защита от повтора однократного использования сами отказывают закрыто — см. Ограничение частоты запросов
Telegram	Повтор, обработка flood-wait и классификация «бот заблокирован/аккаунт деактивирован» (v0.4) — но никакого предохранителя и никакой пробы, запускающей обслуживание. Продолжительный сбой Telegram виден через отказы доставки в собственных логах бота, а не через ряд в дашборде
Платёжные провайдеры	Приём webhook с проверкой подписи плюс сверятель раз в минуту покрывают провайдера, который медлит или теряет webhook, — но никакого предохранителя или обнаружения простоя провайдера сверх этого нет. Полностью недоступный провайдер просто накапливает неудачные попытки оформления заказа против него, видимые в omniflow_payments_total
Серверы MCP / AI-инструментов	Единственная поверхность с настоящим предохранителем — Подключения MCP — область действия ограничена только этой поверхностью, больше нигде не переиспользуется

​

Рекомендации по ёмкости

Omniflow поставляется как один стек Docker Compose — см. Развёртывание, — а конкурентность задач (16 воркеров очереди critical) сегодня вкомпилирована в internal/jobs/client.go, а не является настраиваемым через окружение рычагом. Планирование ёмкости на одном хосте поэтому сводится к тому, чтобы дать PostgreSQL и Valkey достаточно ресурсов, а не к настройке конкурентности очереди.

Уровень	Примерный масштаб	Рекомендация
Малый	Несколько сотен клиентов, низкий объём покупок	2 vCPU / 4 ГБ RAM достаточно для PostgreSQL, Valkey и всех трёх Go-процессов вместе. Запас по диску важнее CPU: закладывайте место под хранение резервных копий (APP_BACKUP_RETENTION_DAYS) поверх роста самой базы данных
Средний	Низкие тысячи клиентов, регулярные кампании	4 vCPU / 8 ГБ RAM, большая часть памяти отдана PostgreSQL (shared_buffers, настроенный примерно на четверть памяти хоста, — разумная отправная точка; см. собственные рекомендации PostgreSQL по настройке). Следите за omniflow_job_duration_seconds{kind="fulfillment"} — если растёт, фиксированная конкурентность очереди critical в 16 воркеров становится потолком для одного воркера, и его поднимает ещё одна реплика воркера
Крупный	Десятки тысяч клиентов, частые массовые действия и кампании	8 vCPU / 16 ГБ RAM как отправная точка, и в первую очередь следите за лимитами подключений PostgreSQL — пулы всех реплик api, bot и worker (APP_DATABASE_MAX_CONNS, см. Развёртывание) вместе должны помещаться в собственный max_connections PostgreSQL. Прежде всего рассмотрите перенос PostgreSQL на выделенный, более быстрый диск, поскольку это единственное долговременное хранилище и через него проходит каждая запись

Это отправные точки для планирования ёмкости, а не проверенный нагрузочным тестированием потолок — тест пропускной способности сегодня в репозитории не поставляется. Наблюдайте за индикаторами выше под собственной нагрузкой и корректируйте на этой основе.

​

Связанные страницы

Здоровье, метрики и логи

Пробы, метрики и оповещения, на которых построены эти индикаторы и дашборды.

Задачи и очереди

Политика повторов, экран недоставленных задач и транзакционный outbox полностью.

Режим обслуживания

За чем следит автоматическое определение и что оно делает, когда окно открывается.

Резервные копии, восстановление и аварийное восстановление

Учения по восстановлению и то, что нужно сверх них при катастрофе на уровне хоста.