How to pass custom ConfigurationClient to AzureAppConfigurationOptions?

[lissdy]

I need to define a custom ConfigurationClient to add more logs and metrics for the configuration fetch events, but found the Client method in AzureAppConfigurationOptions is "internal" protected level.
May I know how to pass custom ConfigurationClient to AzureAppConfigurationOptions?

Is this design for the purpose?

[zhenlan]

Is this what you are looking for? Basically, you can't pass in a custom ConfigurationClient, but you can customize the ConfigurationClientOptions of the ConfigurationClient instance that is used by the library.

https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.configuration.azureappconfiguration.azureappconfigurationoptions.configureclientoptions?view=azure-dotnet

[lissdy]

Thank @zhenlan for replying, checked the code and found ConfigurationClientOptions can be customed as AzureAppConfigurationOptions ConfigureClientOptions(Action<ConfigurationClientOptions> configure) is public. But unfortunately, it doesn't meet my requirement: add custom log/metrics once the sentinel value is changed or configuration reload happens.
Do you have any suggestions about this? Or do I have to implement my own provider library?

[zhenlan]

We are actually working on adding more logs for the scenarios you mentioned. Does this meet your need?

https://github.com/Azure/AppConfiguration-DotnetProvider/pull/354/files

[lissdy]

@zhenlan Want to add more information to logs, for example, as we are following configuration as code pattern. Would like to print the configuration commit version for troubleshooting as well.
The same for metrics, hope the metrics can tell us the Configuration store is throttling, or load data failed, etc.
Do you have the plan to support custom ConfigurationClient? So it's possible to define custom logging and metrics.

[zhenlan]

How does commit number get into your App Config store? As labels? If so, the label will be part of the log.

There will be logs from the provider library when either configuration is refreshed successfully or failed. So you can monitor the logs from the library. You can convert the logs to metrics if you have a system that supports it.

I'm afraid a custom ConfigurationClient won't help in your case. The individual failures on ConfigurationClient cannot tell the full story. The provider library orchestrates the whole refresh and failover (if geo-replication is enabled). Monitoring individual failures of ConfigurationClient can be very noisy because the whole refresh could work just fine with retries and failover.

[lissdy]

Thanks, @zhenlan for your input, we do consider enabling geo-replication once the feature is GA. It's a good point that
the custom ConfigurationClient log may be too noisy in this case and can't tell us the whole picture. I will try to convert the library log to metrics for monitoring.