-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Permissions required to collect metrics? #12
Comments
This issue has been mentioned on Image.sc Forum. There might be relevant details there: |
@ehrenfeu thanks for opening this issue. Yes, upgrading the user permissions is required as the moment for some of the queries. This is also something we have in our production deployments where the I agree with you that it would be great to work towards a more native/read-only integration between the server and Prometheus. Looking quickly at the existing integrations, one technical solution might be to develop and deploy a OMERO Prometheus micro-service that would expose metrics in a Prometheus compatible format. |
Thanks @sbesson - having a microservice for this sounds like the way of choice. Now we only need to wait until it manifests itself on github somehow I guess 😝 |
Turning around this question, is there a template / example somewhere on how to create an OMERO microservice? |
Hi all,
following a conversation with Claire Stoffel we were trying to incorporate more metrics into our Prometheus/Grafana setup, especially regarding data size.
Claire was referring to the image.sc thread on OMERO storage reports that gives some starting points on how to query OMERO for the necessary information.
Only when trying to add these queries to etc/prometheus-omero-counts.yml it is when I realized that my previous approach of simply adding a new user and group (that doesn't have any special permissions or other group memberships) for running the OMERO prometheus exporter doesn't work.
Digging deeper and using that said user on the command line to run an HQL query:
results in something like this:
Adjusting the user to be an "Administrator with restricted privileges" results in the group and username column being filled correctly.
The question is now: is this the way to go? My feeling is that having something more "read-only" would be a cleaner solution, but I'm not sure how to achieve this.
Cheers,
Niko
The text was updated successfully, but these errors were encountered: