It would be useful to have metrics about the number and types of requests made by galaxy-api to pulp via the galaxy_pulp bindings.
Each call to galaxy_pulp bindings in galaxy-api could get metrics accounting added to it, but it probably makes sense to extend the generated galaxy_pulp bindings to create and populate metrics about it's use.
The number of requests, latency histograms, return status, and error counts would be useful to have metrics for. Especially for cases like a pulp request causing a 500 response or spurious 404 or 400 errors.
Any large differences between galaxy-api/galaxy_pulp/pulp metrics could point to potential bugs.
Doing this likely means using a custom template for openapi-generator's python generators.
I have a branch that does that uses custom templates to add logging (https://github.com/ansible/galaxy-api/compare/master...alikins:galaxy_pulp_custom)
and something similar could be used for adding prometheus metric support to galaxy_pulp.
It would be useful to have metrics about the number and types of requests made by galaxy-api to pulp via the galaxy_pulp bindings.
Each call to galaxy_pulp bindings in galaxy-api could get metrics accounting added to it, but it probably makes sense to extend the generated galaxy_pulp bindings to create and populate metrics about it's use.
The number of requests, latency histograms, return status, and error counts would be useful to have metrics for. Especially for cases like a pulp request causing a 500 response or spurious 404 or 400 errors.
Any large differences between galaxy-api/galaxy_pulp/pulp metrics could point to potential bugs.
Doing this likely means using a custom template for openapi-generator's python generators. I have a branch that does that uses custom templates to add logging (https://github.com/ansible/galaxy-api/compare/master...alikins:galaxy_pulp_custom) and something similar could be used for adding prometheus metric support to galaxy_pulp.