Prometheus metrics #311

New Issue

OVERLORD · 2026-02-04T19:28:13+03:00

OVERLORD commented

2026-02-04 19:28:13 +03:00

Originally created by @Skeen on GitHub (May 31, 2019).

Hi,

If I was gonna implement metrics importing using https://github.com/sd2k/rocket_prometheus or https://github.com/pingcap/rust-prometheus would such an addition be welcome to the project;

Behind a feature flag, or
In general build in, but enabled by an environmental variable, or
Always enabled, or
Not at all

Originally created by @Skeen on GitHub (May 31, 2019). Hi, If I was gonna implement metrics importing using https://github.com/sd2k/rocket_prometheus or https://github.com/pingcap/rust-prometheus would such an addition be welcome to the project; 1. Behind a feature flag, or 2. In general build in, but enabled by an environmental variable, or 3. Always enabled, or 4. Not at all

OVERLORD closed this issue

2026-02-04 19:28:21 +03:00

OVERLORD commented

2026-02-04 19:28:34 +03:00

@mprasil commented on GitHub (May 31, 2019):

Personally I'd love to see Prometheus metrics being available behind environment variable. (or generally as any other setting we have) Even better if there was some option to enable authorization.

@mprasil commented on GitHub (May 31, 2019): Personally I'd love to see Prometheus metrics being available behind environment variable. (or generally as any other setting we have) Even better if there was some option to enable authorization.

OVERLORD commented

2026-02-04 19:28:53 +03:00

@dani-garcia commented on GitHub (Jun 2, 2019):

Personally any addition is welcome as long as it's easy to enable/disable and doesn't complicate the code a ton or impact performance.

About how to activate the feature, the best way is hiding it behind an environment variable. The only exceptions I can think of are when:

the new features add external dependencies and link to system binaries
it's impossible to switch the feature on and off at runtime

Sadly both exceptions apply to adding new database support but I can't imagine they would for this case.

Out of curiosity, what kind of metrics are you interested in collecting?

@dani-garcia commented on GitHub (Jun 2, 2019): Personally any addition is welcome as long as it's easy to enable/disable and doesn't complicate the code a ton or impact performance. About how to activate the feature, the best way is hiding it behind an environment variable. The only exceptions I can think of are when: - the new features add external dependencies and link to system binaries - it's impossible to switch the feature on and off at runtime Sadly both exceptions apply to adding new database support but I can't imagine they would for this case. Out of curiosity, what kind of metrics are you interested in collecting?

OVERLORD commented

2026-02-04 19:29:08 +03:00

@Skeen commented on GitHub (Jun 2, 2019):

Okay that sounds good, I'm thinking I'll add 4 environmental variables then, something like:

METRICS_ENABLE
METRICS_USERNAME
METRICS_PASSWORD
METRICS_URI

Where's enable will be the feature toggle with a default to false, username and password will be optional, and if provided will ask for http basic auth before providing metrics and finally metrics uri will be the suburl where metrics are served, defaulting to /metrics

The metrics I'm planning to expose are general http request cycle stuff, numbers of syncs potentially labeled by uuid and database metrics such as the total number of ciphers, ciphers by organization and user, etc.

I'm very open for input on specific metrics you'd like to see included too though.

@Skeen commented on GitHub (Jun 2, 2019): Okay that sounds good, I'm thinking I'll add 4 environmental variables then, something like: METRICS_ENABLE METRICS_USERNAME METRICS_PASSWORD METRICS_URI Where's enable will be the feature toggle with a default to false, username and password will be optional, and if provided will ask for http basic auth before providing metrics and finally metrics uri will be the suburl where metrics are served, defaulting to /metrics The metrics I'm planning to expose are general http request cycle stuff, numbers of syncs potentially labeled by uuid and database metrics such as the total number of ciphers, ciphers by organization and user, etc. I'm very open for input on specific metrics you'd like to see included too though.

OVERLORD commented

2026-02-04 19:29:18 +03:00

@MarsWarrior commented on GitHub (Jun 3, 2019):

I would like to see failed logins, so I can set an alarm on that event in Grafana!

And maybe:

Nr of ogranizations
Nr of users
Nr of folders
Nr of entries
Nr of collections
Nr of attachments
Nr of lookups for username/password

@MarsWarrior commented on GitHub (Jun 3, 2019): I would like to see failed logins, so I can set an alarm on that event in Grafana! And maybe: - Nr of ogranizations - Nr of users - Nr of folders - Nr of entries - Nr of collections - Nr of attachments - Nr of lookups for username/password

OVERLORD commented

2026-02-04 19:29:23 +03:00

@Skeen commented on GitHub (Jun 3, 2019):

Hi @MarsWarrior, I already have the database metrics set up. Including number of users per organization, and such, some of which may have to go behind an environmental variable or be toggleable for people with larger userbases, if they want to avoid too many metrics.

For instance the number of ciphers per user, which can produce a lot of metrics on a busy server.

Number of lookups will be hard, as you cannot see when a user makes a lookup after synchronizing. - You can however potentially track synchronizations.

@Skeen commented on GitHub (Jun 3, 2019): Hi @MarsWarrior, I already have the database metrics set up. Including number of users per organization, and such, some of which may have to go behind an environmental variable or be toggleable for people with larger userbases, if they want to avoid too many metrics. - For instance the number of ciphers per user, which can produce a lot of metrics on a busy server. Number of lookups will be hard, as you cannot see when a user makes a lookup after synchronizing. - You can however potentially track synchronizations.

OVERLORD commented

2026-02-04 19:29:30 +03:00

@mprasil commented on GitHub (Jun 3, 2019):

I would like to see failed logins, so I can set an alarm on that event in Grafana!

I'd love to see that one as well!

@mprasil commented on GitHub (Jun 3, 2019): > I would like to see failed logins, so I can set an alarm on that event in Grafana! I'd love to see that one as well!

OVERLORD commented

2026-02-04 19:29:39 +03:00

@mprasil commented on GitHub (Jun 6, 2019):

I'm going to close this @Skeen now. If you have more questions, maybe hop onto the chat. We can also discuss under WIP PR once you get there as that's probably more appropriate place to discuss these things.

@mprasil commented on GitHub (Jun 6, 2019): I'm going to close this @Skeen now. If you have more questions, maybe hop onto the chat. We can also discuss under WIP PR once you get there as that's probably more appropriate place to discuss these things.

OVERLORD commented

2026-02-04 19:29:44 +03:00

@Skeen commented on GitHub (Jun 6, 2019):

@mprasil that's fair, let's discuss the PR once it's ready and submitted.

@Skeen commented on GitHub (Jun 6, 2019): @mprasil that's fair, let's discuss the PR once it's ready and submitted.

OVERLORD commented

2026-02-04 19:29:50 +03:00

@bclermont commented on GitHub (Mar 1, 2021):

There is no other task to keep track of this feature? been implemented?

@bclermont commented on GitHub (Mar 1, 2021): There is no other task to keep track of this feature? been implemented?

OVERLORD commented

2026-02-04 19:29:58 +03:00