You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When there are many integrations, InfraWallet likely hits some rate limits (such as the AzureClient). If we have a scheduled task that fetches historical cost data and saves them into the plugin database, the rate limit issue can be significantly mitigated and also the performance is further improved.
Some thoughts before an actual implementation:
Different cost clients may generate cost reports with different fields, such as in MongoAtlasClient there are extra fields like project and cluster. How to design the database table properly?
We may only need to fetch costs at the daily granularity and for monthly costs, we use SQL aggregation queries.
When there is no record in the table for a specific wallet, the task should fetch as many historical records as possible (such as the last 12 months' costs), and then, the task updates the previous 30 days' cost.
This should be implemented in the base class (InfraWalletClient.ts) for all the providers whose type is Integration
The text was updated successfully, but these errors were encountered:
When there are many integrations, InfraWallet likely hits some rate limits (such as the
AzureClient
). If we have a scheduled task that fetches historical cost data and saves them into the plugin database, the rate limit issue can be significantly mitigated and also the performance is further improved.Some thoughts before an actual implementation:
MongoAtlasClient
there are extra fields likeproject
andcluster
. How to design the database table properly?InfraWalletClient.ts
) for all the providers whose type isIntegration
The text was updated successfully, but these errors were encountered: