Сейчас админ панели видит только агрегированный онлайн и трафик по ноде/инбаунду — и не может ответить на базовые эксплуатационные вопросы:
- каким конкретно инбаундом реально пользуются клиенты (актуально для разных CDN);
- какой из нескольких протоколов на профиле востребован, а какой можно смело выпилить, не сломав никому доступ.
Это напрямую:
- мешает саппорту (при жалобе конкретного пользователя нельзя проверить, к какому инбаунду он реально подключён и есть ли там трафик);
- планированию нагрузки (перераспределять нагрузку между инбаундами/нодами приходится вслепую, потому что неизвестно, какой инбаунд реально тянет нагрузку, а какой простаивает).
Помимо немедленной пользы для диагностики и планирования, эта же инфраструктура данных — необходимая предпосылка для будущих продуктовых решений (дифференцированные лимиты, биллинг или аналитика per inbound), которые сейчас архитектурно невозможны в принципе, независимо от того, будут ли они реализованы сразу или позже. То есть даже если единственным результатом этого изменения останется только видимость — она уже закрывает реальный кейс в эксплуатации панели, которого раньше не было и не могло быть без правки самого xray-core.
Причина этого не в недоработке панели, а в архитектурном ограничении: восполнить эту гранулярность снаружи, на уровне сети, невозможно в принципе — многие инбаунды проксируются через L3-балансировщики (HAProxy, nginx stream), которые работают на уровне TCP/UDP passthrough и не видят прикладной протокол. Единственный источник данных с нужной гранулярностью — сам xray-core на ноде. Однако и xray-core не умеет считать трафик и присутствие в разрезе “юзер X на инбаунд Y”: счётчики per user и per inbound независимы и не пересекаются.
Я предложил добавить такое измерение в StatsService (PR #6494), но мейнтейнер отклонил PR, предложив использовать разных юзеров на разных инбаундах вместо правки API. Это неизбежно даёт N x M identity (N — юзеров, M — инбаундов на юзера) — но эту сложность не нужно решать через N x M новых сущностей в БД панели: можно переиспользовать уже существующее поле email в конфиге клиента, которое и так гоняется “панель->нода->ответ статистики”. Сейчас панель кладёт туда просто id пользователя; если изменить значение на {id}@{идентификатор инбаунда}, это добавляет нужное измерение поверх уже существующего StatsService.
Отдельно стоит обсудить использование дополнительного короткого идентификатора инбаунда для добавления в email, так как uuid может раздуть их или использовать производное от уже существующего.
Поскольку оба измерения — и онлайн, и трафик — в xray-core завязаны на один и тот же email-based счетчик в StatsService, один и тот же трюк с {id}@{идентификатор инбаунда} закрывает обе задачи одновременно: и присутствие пользователя на конкретном инбаунде, и объём его трафика именно на этом инбаунде — без отдельного механизма под каждую метрику.
Готов взять на себя реализацию, если предложение будет одобрено.