-
-
Notifications
You must be signed in to change notification settings - Fork 204
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
feat: OpenMetrics / Prometheus / metrics endpoint (monitoring) #773
Comments
Thanks, I love the idea! Moreover, these metrics should also be shown in the root web ui, and possibly even allow Ratatui CLI UI (via a cli flag). Obviously all these should not be in a single PR. I think it should be enabled by default (this way only those who want to use Martin as a library would disable it), and there could be a CLI flag like |
Cool, I'm starting a POC with the nlopes/actix-web-prom lib. |
@lefuturiste you may also be interested in charming crate to produce some nice graphs. This way we can have an endpoint like |
I will prioritize the instrumentation of the software. Your ideas sound cool, but I personally don't think that including software to visualize the data is a good idea. I think that we should separate this kind of features and let the user have the choice on how their want to view the data. At least for my use case, I don't need it since I will be using grafana to visualize the data and analyze how martin behave in production. |
Fair point. Technically the charming crate uses Apache javascript library too, so as long as Martin can provide some statistics via an api of sorts, javascript could do all of that. Martin can bake-in various javascript libs during the build step if needed. |
Okay, now for the main issue, which is getting the metrics out. I have a problem.
but for my need I still want to have different metric families for each {source_ids} variants. For that, I will need to change the implementation of the actix-web-prom crate. I imagine some sort of attribute macro on the route, I'm currently trying out to find out what's the best method for a dev to tell to actix-web-prom: "Hey for this route I will need to keep the cardinality for the {source_ids} param". I will open an issue upstream and may be open a MR. But depending on the time it will take to merge it, we may have to use a workaround or not have this feature at all, or use our own version of the crate for more flexibility. |
Hello, I will be interested to use a monitoring endpoint on martin. Of course I'm ready to work on it.
The need is to have some sort of monitoring endpoint to retrieve some metrics.
I would be interested for:
I'm thinking this can be behind a feature flag in order to give the user a choice.
What are your take on this?
Implementation details:
we have the choice between two prometheus instrumentation libraries
the https://github.com/tikv/rust-prometheus library is compatible with the actix web instrumentation library https://github.com/nlopes/actix-web-prom
The text was updated successfully, but these errors were encountered: