[
https://issues.apache.org/jira/browse/UNOMI-958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18094515#comment-18094515
]
Serge Huber commented on UNOMI-958:
-----------------------------------
h2. Implementation in progress
PR: [https://github.com/apache/unomi/pull/811|#811 UNOMI-958: Extend tenant
usage API and add event retention purge]
Branch {{UNOMI-958-usage-rest}} · pushed · awaiting CI / merge.
h3. Delivered scope (expanded beyond original ticket)
* {{GET /cxs/tenants/{tenantId}/usage}} — monthly event counts, scope totals,
per-scope segment/rule breakdown, active API key count, {{periodStart}} /
{{periodEnd}}; {{period=current-month}} (default), {{YYYY-MM}}, legacy {{24h}}
* {{POST /cxs/tenants/{tenantId}/purge/events?retentionDays=N}} — tenant-scoped
event retention purge (minimum 7 days)
* Removed unreleased {{ResourceQuota}}, {{TenantQuotaService}},
{{TenantMonitoringService}}; consolidated into {{TenantUsageService}}
* {{@RequiresTenant}} on tenant-scoped REST routes; SecurityFilter class/method
role resolution
* Multitenancy manual updated
h3. Tests
* {{TenantUsageServiceImplTest}} — 19 tests
* {{TenantEndpointTest}} — 7 tests (new)
* {{TenantIT}} — usage + purge integration coverage (CI)
h3. Follow-up after merge
Close this ticket as Fixed with link to #811. Quota *enforcement* remains
upstream (gateway / control plane); Unomi only *measures* and exposes purge for
retention.
> Operators cannot read per-tenant usage through the Unomi REST API
> -----------------------------------------------------------------
>
> Key: UNOMI-958
> URL: https://issues.apache.org/jira/browse/UNOMI-958
> Project: Apache Unomi
> Issue Type: Sub-task
> Components: unomi(-core)
> Affects Versions: unomi-3.1.0
> Reporter: Serge Huber
> Priority: Major
> Fix For: unomi-3.1.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h2. Summary
> Multi-tenant operators and upstream control planes cannot read per-tenant
> usage (profiles, storage, API volume) from Unomi over REST. Limits should be
> enforced above Unomi, but there is no supported REST API to measure usage per
> tenant.
> h2. What is going wrong today
> * Usage is collected in background services but not exposed on REST endpoints.
> * Documentation refers to monitoring endpoints (e.g. API call counts) that
> are not implemented.
> * Quota-related code (limits on \{{Tenant}}, \{{TenantQuotaService}})
> suggests Unomi enforces limits, but nothing blocks operations — misleading
> dead code.
> * Upstream gateways or billing systems cannot poll Unomi for per-tenant usage
> to enforce plans (profile caps, request limits, etc.).
> h2. Impact
> * Platform teams must query the search backend directly or build custom
> tooling.
> * Product quotas cannot be enforced consistently at the layer above Unomi
> without a supported usage API.
> * Contributors may assume \{{ResourceQuota}} on \{{Tenant}} is enforced
> inside Unomi when it is not.
> h2. Who is affected
> * Operators running shared multi-tenant Unomi clusters
> * Teams building a control plane or API gateway in front of Unomi
> h2. What good would look like
> * Unomi exposes *read-only* per-tenant usage via REST: \{{GET
> /cxs/tenants/\{tenantId\}/usage}} (optional \{{period}} query param, e.g.
> \{{24h}}).
> * Response includes profiles, events, segments, rules, storage, and requests
> for the requested period, plus \{{collectedAt}} so callers know metrics are
> cached/refreshed.
> * Endpoint is protected with existing tenant access rules (tenant admin for
> own tenant; platform admin for any tenant).
> * In-Unomi *quota enforcement* is removed or clearly deprecated; limits
> remain the responsibility of the layer above.
> * \{{ResourceQuota}} on \{{Tenant}} is deprecated or removed so operators are
> not misled.
> * \{{TenantQuotaService}} is removed; monitoring consolidated into a single
> usage service (evolve \{{TenantMonitoringService}}).
> * Multi-tenancy manual updated: usage REST API documented; enforcement
> described as upstream responsibility.
> * Integration test covers the REST usage endpoint for at least one tenant
> with known data.
> h2. Out of scope
> * GraphQL usage exposure (separate follow-up ticket).
> * Enforcing profile, request, or storage limits inside Unomi.
> * Storing plan limits on \{{Tenant}} unless kept strictly as non-enforced
> metadata (prefer removal).
> * Exact N+1 profile rejection on implicit profile creation via
> \{{/context.json}}.
> h2. Context
> * Follows PR 4 ([#809|https://github.com/apache/unomi/pull/809]): UNOMI-941,
> UNOMI-938, UNOMI-942 (TenantService robustness + per-tenant count accuracy).
> * PR 5 remains UNOMI-943 (migration scripts). This ticket is a follow-up PR
> after PR 4 merge.
> * Architectural decision: Unomi *measures* via REST; control plane / gateway
> *enforces*.
> {panel:title=Technical notes (for implementers)|borderStyle=solid}
> * Remove \{{TenantQuotaService}} and blueprint wiring.
> * Evolve \{{TenantMonitoringService}} → \{{TenantUsageService}} in \{{api}}
> with \{{TenantUsage}} DTO.
> * Add route on \{{TenantEndpoint}}: \{{GET /tenants/\{tenantId\}/usage}} with
> \{{@RequiresTenant}}.
> * Request counting: lightweight per-tenant counter on REST path (in-memory
> buckets for period), not persisted \{{apiCall}} items unless needed later.
> * \{{calculateStorageSize}}: expose document count clearly; add
> \{{sizeBytes}} only when implemented correctly.
> * Deprecate/remove \{{ResourceQuota}}; update \{{TenantIT}} and shell CRUD
> accordingly.
> {panel}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
