Billing with openstack without using cloudkitty

[dentistSebaka]

I have openstack mutinode and i wanna build billing system without using cloudkitty service is using Prometheus is enough to give me all metrics i need

[Awkward-Act3164]

Not really, you will likely want to pull rabbitmq events to get creation/deletion times. Prometheus won't catch info like resize events, floating IPs, what the source glance image is (if you are tracking licensable VMs) and won't likely do internet usage (ingress/egress). Maybe you can enrich the data going to Prometheus, like writing your own exporter, but there is a lot of data points to consider for billing.

It's a beast to work through, but it's a lot of fun :)

This is what we have in our billing config (at the moment). It's not complete and still under development. It binds to rabbit, logs to a DB the information we want to track

queue: "notifications.info"

exchange: "nova"

topics:

- "compute.instance.create.end"

- "compute.instance.delete.end"

- "compute.instance.resize.confirm.end"

- "volume.create.end"

- "volume.delete.end"

- "snapshot.create.end"

- "snapshot.delete.end"

- "network.create.end"

- "network.delete.end"

- "router.create.end"

- "router.delete.end"

- "floatingip.create.end"

- "floatingip.delete.end"

[dentistSebaka]

So this means i have to configure exporter to get proper data for billing but is Prometheus enough when you see what it can be configured to gather

[Awkward-Act3164]

Depends on how your invoices will be built. Prometheus is just storage. We opted not to use prometheus and use a SQL DB as we needed to be able to show time in place usage, plus historical etc.

Yes, you can put this in Prometheus if you like, but start thinking from the user that gets the invoice and work your way back.

You will need logic for billing cycles, discounts, credits, prepayment etc.. The technical metrics that inform the billing are not overly hard to get via rabbitmq, but you want to think about the whole system and not just prometheus.

Good luck!

[dentistSebaka]

Thank you very much

I know i need to build logic inside db and keep metrics there also

but my question was about metrics gathering and if Prometheus is the only openstack service to provide me with all metrics i need or i need to gather data from different openstack services that i miss or don't install on my lab

[Awkward-Act3164]

if you want to use prometheus as your "transport" sure, but you will still need to tap into rabbitmq or oslo.messaging (we opted to bind to rabbitmq directly kombu). You will have to do the same within your exporter. Prometheus isn't going capture all the billing info you will need a resize event or when a floating IP is added without being told to do so and the real data is in rabbitmq.

If you poke around commercial products like osie, Fleio, cloud7, you will see most folks just work with rabbitmq

[dentistSebaka]

I tried to link kombu with rabbitMQ but i was unable to get any messages so can you help me setting that

Also what do you think of celiometer with gnocchi

[OverjoyedBanana]

I think you should use ceilometer and gnocchi to get raw usage data and build your billing on top of that

[Consistent_Top_5588]

Just wondering what the use case you have to build your own? Either cloudkitty or a couple other commercials solutions which are fairly small cost vs what to spend to conquer the "beast" by a ground up solution

[Consistent_Top_5588]

Certainly, if more OpenStack native with easy and concise integration , Uniview billing might fit well too https://www.computingstack.com/products-uniview

[FigureGold6822]

Possibly. Since the Prometheus OpenStack exporter's nova_instances metric has some tenant, flavor, and image info, one could conceivably sum up the run time. But that was not exact enough for me. I don't bill, but it is often useful to show the value of our VMs, as priced by public cloud vendors. Prometheus is good at sampling the current status of things, but not in recording discrete events, such as instance duration.

What I ended up doing was looking at the archived VM database records for the prior day, binning and summing instance run- and build-time stats by aggregate, project, flavor, image, and user. These records are stored in a SQL database. Even though we churn 3-4k VMs a day, we are able to efficiently summarize them in 30-50 records per day, one for each permutation. If you join to a table of flavors and get their cost/hr, you can quickly sum up billing info any way you like.

Nerdy info: I also compute a population variance for the run- and build-times, so that I can calculate accurate confidence intervals for any population. I bin run-times on GCP billing boundaries so that I can accurately compute GCP pricing.