+1 for this. Its critically important that the billing data show details about resources as of the time of usage/billing rather than providing a 'join' approach for the pieces of data.
We need the cluster id to show up in the billing data for cost allocation purposes. However, today, only the cluster name is provided and it would require us to call the clusters api to get the cluster ids. Here's the catch, that's not a viable approach since that API only provides a list of clusters that are currently running (and worse, doesn't show serverless clusters). There may be more complex workarounds like looking through events APIs (requires matching by time periods as clusters may use the same name after delete).
Like the items mentioned above or information like tags (mentioned in other feature requests), its important that billing data present as much detail as possible (almost like an event log) and not be depended on users having to 'join' other datasets which may evolve or be incomplete. This would unblock enterprises to perform standard FinOps use cases for MongoDB similar to what FinOps practitioners do for AWS, GCP, Azure etc.
+1 for this. Its critically important that the billing data show details about resources as of the time of usage/billing rather than providing a 'join' approach for the pieces of data.
We need the cluster id to show up in the billing data for cost allocation purposes. However, today, only the cluster name is provided and it would require us to call the clusters api to get the cluster ids. Here's the catch, that's not a viable approach since that API only provides a list of clusters that are currently running (and worse, doesn't show serverless clusters). There may be more complex workarounds like looking through events APIs (requires matching by time periods as clusters may use the same name after delete).
Like the items mentioned above or information like tags (mentioned in other feature requests), its important that billing data present as much detail as possible (almost like an event log) and not be depended on users having to 'join' other datasets which may evolve or be incomplete. This would unblock enterprises to perform standard FinOps use cases for MongoDB similar to what FinOps practitioners do for AWS, GCP, Azure etc.