-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cloudcost-exporter: support GCP c4a compute and local hyperdisks #337
Comments
Now that GCP has publicly unveiled the C4A family, let's update the pricing map to handle both ARM and AMD chipsets. - refs #337
Now that GCP has publicly unveiled the C4A family, let's update the pricing map to handle both ARM and AMD chipsets. - refs #337
Handling the ARM chipset was fairly straight forward(#341). The hyperdisk requires a bit more thinking. I pushed an MVP PR(#344) that will emit cost metrics just for the capacity. This is ideal because our initial attempts at using hyperdisks will be limited to configurations where throughput and IOPS and the default values, which are effectively free. @jjo posed an interesting question, which is how do we expose the other pricing dimensions? I did a bit of a deep dive of Grafana's internal usage of the metrics. Most of our calculations for TCO of storage boil down to this type of PromQL expression represented in jsonnet:
Note that the only calculation we're making is finding pod's that are running, then joining that against the hourly cost of persistent volumes associated with that volume. In previous iterations, the cost metric would emit the list price for a specific volume. In our current approach, we bake that in to the metric so that we don't need to put more pressure on Prometheus to make the calculations. Because of that design decision to calculate the total hourly cost for the metric, I believe we can also add the cost of the other dimensions necessary for Hyperdisks. This would require a subtle change to our storage pricing map(
We'd need to expand that from simply being a float64 to being something like type StoragePriceDimensions struct {
Capacity float64
IOPS float64
Throughput float64
HA float64 Then the disk would need a method that gets the associated metadata for each dimension and calculates the cost based upon those dimensions. What do you think @jjo? |
💯 indeed we'd "just" need to change In that sense, is interesting to realize that cost has always been "provisioned ", previously only one (
Just to play with an example, disk provisioned with:
|
Very strong plus one on the calculations. The only very minor nit to be added @jjo is that GCP charges for usage after a certain point. So it would be closer to
|
+1 math-wise just be careful to not go negative on those factors (i.e. |
Great call out! Effectively we need to do |
I think that's actually |
First attempt at handling hyperdisk balanced volumes. The primary goal was to update the pricing map logic in such a way that would parse of hyperdisks balanced and include only the cost of capacity. Hyperdisk Balanced pricing is done in such a way that if you don't configure IOPS and Throughput, you use a free tier. In the future IOPS, Throughput, and High Availability costs need to be saved and calculated as well. - relates to #337 Co-authored-by: JuanJo Ciarlante <[email protected]>
I'm going to place this back into TODO until we are closer to adopting hyperdisks. For now we handle the storage costs, and the remaining task is to attribute costs for IOPS and the other dimensions. One key bit I learned from this is that we'll need to handle the SKU similar to what we do with CPU/Memory, and write out regex's to match properly. See https://github.com/grafana/cloudcost-exporter/compare/feat/hyperdisk-price-calculator?expand=1 for where I stopped. Specifically, https://github.com/grafana/cloudcost-exporter/compare/feat/hyperdisk-price-calculator?expand=1#diff-c58feeadbe3b07fb5e4ff69378e1db9ed311c68e971e6bcdc2d91828c7226089R196-R197 is where things started to break down and the naive implementation no longer works. |
Follow up from #182992.
Add GCP
c4a
compute and local storage support tocloudcost-exporter
:Tasks
The text was updated successfully, but these errors were encountered: