Right now, we use the same instrumented client for all chart repositories. This is great because we expose some metrics about our requests to the chart repos, but it's not great because when these metrics change, we don't know which chart repository is acting up.
Using a different client per repositories allows us to be able to track these per repository, instead of globally. However, we will also need to register the metrics of each client as we construct a new Repository object.
This changes the structure a little bit because we don't register all our metrics in the very beginning just by calling instrumentedclient.GetMetrics() and registering the results. However, as chart repositories are discovered and constructed in runtime, there's no way to know and register these metrics ahead of time.
Right now, we use the same instrumented client for all chart repositories. This is great because we expose some metrics about our requests to the chart repos, but it's not great because when these metrics change, we don't know which chart repository is acting up.
Using a different client per repositories allows us to be able to track these per repository, instead of globally. However, we will also need to register the metrics of each client as we construct a new Repository object.
This changes the structure a little bit because we don't register all our metrics in the very beginning just by calling
instrumentedclient.GetMetrics()
and registering the results. However, as chart repositories are discovered and constructed in runtime, there's no way to know and register these metrics ahead of time.