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
Is your feature request related to a problem? Please describe.
Feature Request:
Currently, in FeatureHub SaaS site, there is a useful Billing page which shows the total API Request usage for the account, which is used to inform billing and capacity planning decisions. The values presented there are total number for the account, but nothing to show the administrator which Service Accounts are being used and how much of the account usage totals are attributable to each of them.
Describe the solution you'd like
In some cases, it would be extremely useful to see which Service Account are actually being used (based on API Requests) and how much requests those Service Accounts are generating.
Here is a mock-up of what I dreamt up as being useful.
On hovering over the icon, it could show the API Request count for a specific service account under the Manage service accounts page.
Alternatively, an even better, IMO, way to show it would be to have utilization counts against each individual API-Key, giving the highest level of granularity, but that may be too onerous from a performance standpoint. Rolling the API key would reset the counter, and a disclaimer would say that per-api-key counts may not always add up to the totals in the Billing page.
On hovering over the icon, it could show the API Request count for a specific API Key under the API Keys page.
Describe alternatives you've considered
I could not find alternatives methods to obtain this information.
Additional context
This information is useful for administration purposes, rather than operational. We need to have a way to identify unused service account, and also identify any excessive use by a service account if it were to arise. Currently, short of having a different subscription with a single Service Account in each (defeating the purpose of having multiple environments), I could not find a way to achieve this.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Feature Request:
Currently, in FeatureHub SaaS site, there is a useful
Billing
page which shows the total API Request usage for the account, which is used to inform billing and capacity planning decisions. The values presented there are total number for the account, but nothing to show the administrator which Service Accounts are being used and how much of the account usage totals are attributable to each of them.Describe the solution you'd like
In some cases, it would be extremely useful to see which Service Account are actually being used (based on API Requests) and how much requests those Service Accounts are generating.
Here is a mock-up of what I dreamt up as being useful.
On hovering over the icon, it could show the API Request count for a specific service account under the
Manage service accounts
page.Alternatively, an even better, IMO, way to show it would be to have utilization counts against each individual API-Key, giving the highest level of granularity, but that may be too onerous from a performance standpoint. Rolling the API key would reset the counter, and a disclaimer would say that per-api-key counts may not always add up to the totals in the
Billing
page.On hovering over the icon, it could show the API Request count for a specific API Key under the
API Keys
page.Describe alternatives you've considered
I could not find alternatives methods to obtain this information.
Additional context
This information is useful for administration purposes, rather than operational. We need to have a way to identify unused service account, and also identify any excessive use by a service account if it were to arise. Currently, short of having a different subscription with a single Service Account in each (defeating the purpose of having multiple environments), I could not find a way to achieve this.
The text was updated successfully, but these errors were encountered: