Три типовых боли после включения стриминга
1. Суммарный параллелизм узлов превышает глобальный бюджет шлюза: каждый Mac честно масштабирует воркеры, но общий лимит потоковых сессий не пересчитан под длинные ответы.
2. Очередь исходящих уведомлений растёт быстрее генерации чанков: без явных порогов вы не видите разницу между мягким замедлением и жёстким отказом.
3. Каждый канал Mattermost, Teams и почты запускает собственные ретраи к одному сбою шлюза, поэтому дежурный получает лавину одинаковых сообщений вместо одного объединённого алерта.
Контекст v2026.3.x: стриминг и несколько каналов
В ветке v2026.3.x шлюз может отдавать интерактивные ответы чанками или через SSE, а параллельно принимать события из CI и маршрутизировать исходящие статусы. Это увеличивает число долгоживущих TCP-сессий и нагрузку на буферы записи, особенно если узлы MeshMac делят один апстрим. Практичный подход — держать классификацию маршрутов в логах и сверять её с политикой из статьи про потоковую сводку Teams и балансировку в шагах по LB и failover.
Минимально воспроизводимые шесть шагов
- Шаг один. На стейдже поднимите шлюз до v2026.3.x с одного узла MeshMac, прогоните проверку состояния и включите потоковый режим только для тестового арендатора.
- Шаг два. Включите в лог постоянные поля route_class для интерактивных стримов, приёма CI и исходящих уведомлений, чтобы суммировать бюджет по типам трафика.
- Шаг три. Запишите два лимита: на арендатора и глобальный на кластер; убедитесь что произведение параллельных воркеров на число узлов не выходит за глобальный потолок одновременных стримов.
- Шаг четыре. Опишите три уровня backpressure: только рост p95 без HTTP-отказа, ответ 429 с Retry-After при превышении скорости и 503 при деградации зависимостей или провале health.
- Шаг пять. На клиентах исходящих вебхуков оставьте экспоненциальный backoff только для 429 и временных 5xx, полностью запретите цикл на 400 и 401 до правки секретов, логируйте provider_run_id и mesh_node_id.
- Шаг шесть. В мониторинге стройте incident_key из имени лимита и хоста апстрима, агрегируйте события ретраев в окне от пяти до пятнадцати минут и отправляйте в пейджер одну сводку вместо десяти копий.
Нагрузочный прогон делайте на фиктивном арендателе, удваивая число активных стримов и фиксируя первую точку отказа без продакшн-трафика.
Таблица решений: параллелизм, backpressure, алерты
| Симптом | Гипотеза | Действие |
|---|---|---|
| Рост задержки без 5xx | Мягкое давление на очередь | Сначала увеличьте интервал отправки на клиентах и снизьте локальный параллелизм, не трогая глобальный лимит. |
| Частые 429 | Превышен бюджет скорости | Соблюдайте Retry-After, уменьшите одновременные CI-джобы и пересмотрите классы route_class с высоким весом. |
| 503 и рост очереди | Деградация зависимости или нехватка FD | Остановите старт новых стримов, проверьте health шлюза и апстрима, затем масштабируйте реплику или память. |
| Дубли алертов | Независимые ретраи каналов | Единая шина исходящих сообщений плюс скользящее окно по incident_key перед IM и пейджером. |
Что фиксировать в логах и метриках
- route_class рядом с mesh_node_id и active_streams, чтобы отделить интерактив от CI и исходящих уведомлений на одном графике.
- outbound_queue_depth и retry_after_ms как пару для корреляции роста очереди с политикой клиента.
- limit_name и долю 429 к 503 на одном дашборде, чтобы не смешивать реакции дежурных на разные классы отказов.
Оценку «потолка» удобно аппроксимировать как произведение средней длительности стрима на одновременное число сессий; сравните с фактическими пиками перед повышением лимитов.
FAQ
Вопрос: Добавили второй узел и стало медленнее.
Ответ: Чаще всего выросла сумма параллельных воркеров. Проверьте глубину очереди, уменьшите семафор на каждом Mac и синхронизируйте конфиг с репликами балансировщика.
Вопрос: Объединённый алерт запаздывает.
Ответ: Делайте первое уведомление немедленно, а последующие по тому же incident_key склеивайте в окне; для 503 оставьте отдельный быстрый канал эскалации.
Вопрос: Нужны ли разные политики для чатов и почты?
Ответ: Да, но ретраи должны исходить из одной очереди шлюза с общими лимитами, иначе вы удвоите шторм при частичном сбое DNS.
Тарифы и выбор узла без входа
Потоковый шлюз нагружает прежде всего одновременные соединения и очередь исходящих, а не просто количество Mac в пуле. Перед продом зафиксируйте классы маршрутов, лимиты и политику алертов, затем сравните тарифы по запасу параллелизма. Страница goumai открывает каталог планов и типов узлов без авторизации, bangzhu даёт справку по доступу, главная Meshmac и хаб OpenClaw дополняют картину; список блога содержит смежные HowTo.
Сначала бюджет стримов и очередей, потом масштабирование узлов
Сравните тарифы и узлы на публичной витрине, затем откройте справку по SSH и VNC и вернитесь к блогу за соседними чеклистами.