Hey there,
this topic is regarding the scm-metrics-prometheus-plugin v1.0.
I need some help to find the right position for the authorization. I tried to create a new user - prometheus/[pw] and gave him just read rights for the beginning.
As I´m unsure which right to give just providing the right to read the metrics.
In prometheus log I can see that the connection details are correct - aside the authorization:
ts=2023-02-06T15:18:59.723Z caller=scrape.go:1328 level=debug component=“scrape manager” scrape_pool=scm-manager target=https://url:443/scm/api/v2/metrics/prometheus msg=“Scrape failed” err=“server returned HTTP status 403 Forbidden”
After login to ces and using the url, I´m able to see the metrics. So the browser is using my current user logged in, I guess.
If I start an anonymous browser page and using that prometheus url pasted before, I run into the ces login screen. But the user I created for a test is inside the user management of SCM-Manager - not in CES user management.
Is there maybe an option to provide the metrics without any user for test - even if I would prefer one.
Maybe you can give me some more information how or where to create the user and which rights are enough just for the metrics. Your help would be very welcome.
Many thanks and best regards,
Sascha
Hi Sascha,
thank you for your post. We will need more time to reproduce and to test several if there’s a ways to access the data without a user/credentials.
In the meantime you could try to create an user via the User-Management dogu of your CES instace. This user is automatically create in SCM-Manager and you need to give the rights for read metrics.
Hi Christoph,
many thanks for your answer. After creating a new user in the User-Management and adding the rights reading metrics in SCM-Manager, the user can be used to provide the metrics to prometheus.
Finally, we are providing the password via vault to prometheus to prevent having the clear password in git.
May I ask for some documentation which values might be useful to monitor?
Or, are there metrics to visualize the mirror situation, e.g. when was the last working or broken mirror attempt of a git repository?
Many thanks and best regards,
Sascha
Hey Sascha,
there is no specific list of use cases. I depends on what you want to measure / visualize. But there are some use-cases that we are currently using for monitoring:
With “Access failed” and “Access Success” we are keeping track of who wants to access our instances.
For tracking mirrors we would recommend the build-in log for the Mirror-Plugin in the SCM-Manager UI.
All the best,
Christoph
Closed because there was no activity in the last 30 days or longer