Appconfiguration: How to report on key use?

[osudude]

It would be helpful if we could report on the last time a given key / keys were used and from what user / ip address. Is there any way to accomplish this?

[drago-draganov]

@osudude

Can you provide some details on how do you see such feature serving you? Is it from auditing/security prospective or do you have something else in mind?

[osudude]

Over time we will want to retire settings in favor of new settings but need to see who (if anyone) is still using a given key. Usage report can show us the apps / users that are still using a given key. We can contact that team and instruct them to quit using that key and switch to a new key.

[drago-draganov]

Thanks, @osudude. We also think that tracking stale configuration is important and we are looking at related issues.
Technically, we can provide the last-accessed time, but I'm concern that it may not be enough to solve the root problem. Applications (as well as portal/cli/ci-cd, etc.) will most likely request key-values at bulk (ex: get all keys that start with '/myservice'). It doesn't directly correlate to real usage of each individual item, unless stricter discipline is imposed.

[osudude]

One way I have seen the bulk retrieval tackled in similar apps, have keys that can be assigned to one or more assigned packages (container). The consumer then resolves settings through packages of keys.

[HashTagDotNet]

We too would like to see which keys are being read (perhaps by security key) and perhaps how often. While not giving concrete usage, it might be something. Having an access count might also be helpful.

[sslepova]

I would like to be able to query such things as:

• requests total for the given period of time,
• requests made by a certain identity (this could be a user, an app, or a service connection),
• requests count by a key prefix, label.

This functionality should be accessible both ways: via the portal and programmatically. I believe this is very important especially since app config requests count is limited by definition.

[gsgvijay]

Hi @sslepova,

Regarding Question1:

We currently support metrics which should give you the request count over a given period of time (Metric name: HttpIncomingRequestCount in this case). You should be able to view the metric directly on the Config Store's overview blade in Azure Portal.

You can also retrieve the metric programmatically as documented here.

You can also get the metrics from a REST API (ARMClient is recommended, but it should work with Curl or Postman or Fiddler too):
armclient get "/subscriptions/<subscription id>/resourcegroups/<resource group>/providers/Microsoft.AppConfiguration/configurationStores/<config store name>/providers/microsoft.insights/metrics?api-version=2017-05-01-preview&$filter=(name.value eq 'HttpIncomingRequestCount') and startTime eq 2020-08-02T23:09:00Z"

You can view the list of supported metrics for App Configuration here.

For Questions 2 and 3, we're currently working on it, but it's not supported yet.

[sslepova]

Hi, @gsgvijay! Thank you very much for the update and links. Could you share some info/resources regarding how exactly requests are counted? I mean how many requests it takes reading one value or all values from the store and so on.

[drago-draganov]

@sslepova
The number of requests depends on the client scenario and the number of the key-values that match.

Bulk fetch examples:

• To fetch all key-values, the client sends HTTP request like https://<store name>.azconfig.io/kv/key=*&label=*
• To fetch all key-values for specific label abc, the client sends HTTP request like https://<store name>.azconfig.io/kv/key=*&label=abc
• To fetch all key-values that key name starts with specific prefix xyz, the client sends HTTP request like https://<store name>.azconfig.io/kv/key=xyz*&label=*

Each of the above variants counts as one request and they can deliver up to 100 key-values. If the result set contains more than 100 items, the pagination continues in the same fashion to retrieve the next 100 key-values.

_number_of_requests = number_of_matching_key_values / 100_

That is used in our configuration providers.

Single fetch examples:

• To fetch a specific key-value with key name xyz and label abc, the client sends HTTP request like https://<store name>.azconfig.io/kv/xyz?label=abc

This counts as one request and delivers one key-value. This is used in configuration provider to implement Watch functionality (sentinel leys).

[sslepova]

Thank you, @drago-draganov for the answer regarding number of requests. I believe all this worth mention in the documentation, not only here in discussion.
And there is another question - this was about reading keys, but what about writing? Does these rules apply to writing operations?

[drago-draganov]

@sslepova Thanks for the feedback! We should always do better with docs.

Write operations are always related to individual key-value, therefore there isn't a bulk write (set/update/delete). Each write is considered single operation. Basically each independent HTTP request is counted towards throttling. Read request can deliver up to 100 key-values within a single HTTP request. Write request is always bound to one key-value at a time.