Billing is one of the most critical and complex components in OpenStack‑based cloud business. For public clouds, billing is tied directly to revenue and customer trust. For enterprise clouds, metering and billing are essential for internal chargeback, cost allocation, and audit compliance.
This blog outlines the core requirements of a modern OpenStack billing system, then dives deep into the technical realities of metering, rating, and invoicing. It concludes with a comparison of metering architectures and how Uniview builds a sustainable, production‑grade billing platform.
The Three Pillars of Billing: Metering, Rating, Payment
A complete billing system consists of three major processes: Metering - Collecting raw usage data from OpenStack services; Rating -- Applying pricing logic to the metered data; Payment / Invoicing --Generating invoices, handling currency, and integrating with payment gateways.
Among these, metering is the hardest and most technically demanding. Rating and invoicing are relatively straightforward compared to the challenges of extracting accurate, complete, deduplicated, timestamp‑consistent usage data from a distributed cloud.
Deep Technical Dive: Metering Approaches in OpenStack
Below is a detailed analysis of the three dominant metering architectures used in OpenStack clouds today.
Approach A — Ceilometer + Gnocchi (or Ceilometer + Prometheus)
The traditional upstream metering pipeline relies on Ceilometer agents that poll OpenStack APIs or listen to service notifications, then push the collected metrics into Gnocchi or Prometheus for storage and aggregation. This approach works reasonably well for basic, coarse‑grained billing because it is native to OpenStack, easy to configure, and requires no additional licensing. However, it suffers from several structural limitations: notification gaps across services, inconsistent metric formats between Nova, Neutron, and Cinder, and the operational complexity of tuning Gnocchi’s archive policies and rollups. Scaling Gnocchi’s indexer can also become a bottleneck in larger deployments, and upstream ecosystem activity has slowed, reducing long‑term sustainability. As a result, this method is best suited for small clouds or internal chargeback environments where customization needs are minimal and billing accuracy requirements are not stringent.
Approach B — API‑Driven Metering (Yuyu, FishOS Uniview hybrid mode etc)
API‑driven metering works by periodically polling OpenStack services such as Nova, Cinder, Neutron, Keystone, and Placement to extract usage information like instance hours, vCPU/RAM consumption, volume sizes, snapshots, floating IPs, and bandwidth. This architecture is straightforward, easy to maintain, and well‑suited for aggregated billing models where hourly or daily usage is sufficient. It avoids the complexity of message queue parsing and generally scales well for enterprise clouds with predictable workloads. Its limitations stem from the fact that it is not real‑time and cannot capture short‑lived workloads or transient lifecycle events. API inconsistencies across services can also lead to edge cases such as missed failed builds or partial resource states. This approach is ideal for MSPs and enterprise private clouds that prioritize operational simplicity over fine‑grained accuracy.
Approach C — Message Queue Interception (one main implementation by OpenStack Billing commercial business)
MQ‑based metering listens directly to RabbitMQ or Kafka for Nova, Neutron, and Cinder lifecycle events, capturing every state transition — from instance creation and resize to migration, shutdown, shelving, and deletion. These events are then correlated with Keystone, Placement, and Neutron data to reconstruct a complete, precise timeline for each resource. This method provides the highest accuracy, real‑time visibility, and the ability to meter short‑lived or bursty workloads that API polling and Ceilometer often miss. It also handles complex edge cases such as failed builds, live migrations, and evacuations. The trade‑off is a steeper implementation curve and the need for deeper OpenStack internals knowledge, as the system must handle message ordering, duplication, and idempotency. Despite the complexity, MQ‑based metering is the architecture of choice for public clouds, multi‑region deployments, and any environment requiring fine‑grained, cloud‑provider‑grade billing accuracy.
A side by side comparison:
| Feature / Requirement | Ceilometer + Gnocchi | API‑Driven Metering | MQ‑Based Metering |
|---|---|---|---|
| Accuracy | Medium | Medium | High |
| Granularity | Low–Medium | Low | High (per‑event) |
| Real‑time | No | No | Yes |
| Captures short‑lived VMs | Often missed | Missed | Captured |
| Handles edge cases | Weak | Weak | Strong |
| Scalability | Medium | High | High |
| Complexity | Low | Medium | High |
| Customization | Low | Medium | High |
| Ecosystem health | Weak | N/A | Strong (custom) |
| Multi‑region support | Hard | Medium | Strong |
| Best use case | Small clouds / basic chargeback | Enterprise / MSP clouds | Public & multi‑region clouds |
What a Modern OpenStack Billing System Must Deliver
Let's dive into each individual to elaborate what an ideal OpenStack billing solution should be.
A modern OpenStack billing system must satisfy several foundational principles to ensure accuracy, scalability, and long-term operational sustainability:
-
Highly customizable and versatile
The billing platform should be agile to adapt to the operator’s business. This includes support for custom pricing rules e.g. by CPU hour collectively, by flavor, new pricing item, GPU and other hardware acceleration metering, resource definitions, aggregation windows, invoice formats, and discounting logic. -
Technically sustainable with reliable components
Billing is mission‑critical. Its components must be stable, well‑maintained, horizontally scalable, and resilient to data spikes, avoiding fragile or experimental technologies. -
Backed by a capable team (vendor or strong internal engineering)
Billing requires continuous updates, integration with new OpenStack services, and ongoing compliance improvements. Clear ownership and long‑term support are essential. -
Metering must be solid
Accurate metering is the foundation of trustworthy billing. This includes precise measurement of compute, storage, and network usage, reliable event capture, deduplication, and consistent timestamping across regions. -
Flexible rating engine
The system must support both aggregated billing (e.g., hourly VM usage) and fine‑grained billing (e.g., per‑second or per‑request metering), allowing operators to define rating logic that matches their business model. -
Cross‑cluster, cross‑region rating
Large deployments span multiple clusters and regions. Billing must unify usage across these boundaries to produce a single coherent bill, requiring consistent metering formats and cross‑region aggregation logic. -
Platform unification
Billing must integrate seamlessly with identity, quota systems, tenant lifecycle, support systems, payment gateways, and customer portals. Unified design ensures billing reflects the true state of the cloud.
Uniview’s Billing Architecture
Uniview implements a hybrid metering architecture to stay comprehensive, concise, full control and agility. It complies the princples with: MQ‑based event capture, For accuracy, real‑time billing, and fine‑grained usage; API‑based reconciliation, to ensure consistency and recover from missed events; Multi‑region aggregation layer, ro unify usage across clusters and regions; Flexible rating engine, supporting aggregated and fine‑grained billing models; Unified platform integration, with tdentity, quota, lifecycle, invoicing, and customer portal all in one platform;
This combination gives Uniview the reliability of MQ‑based metering with the operational simplicity of API‑based reconciliation — a sustainable architecture for both public clouds and large enterprise clouds. Uniview billing solution is comprehensive from metering, rating engine to the invoicing and payment gateway. On other hands, Uniview is also well backed by developer to meet high end demand of billing, when agility is required. Uniview is sustainable by adopting only organic integration.
Authored by Jack Dang · At Toronto Apr 2026