You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the solution you'd like
It would be great to have an endpoint ether built in (you can use https://github.com/prometheus/client_ruby) or using an API as a separate exporter, that exposes metrics and statistics of the running manyfold. By having this endpoint as ether way, It will allow people to use standard monitoring tools that they are use to for anything that can ingest Prometheus endpoints. The benefits of using a Prometheus based endpoint is that it is a pulling based monitoring solution and in such case will just need a page that pulls the more recent information from below on each scrape from the Prometheus sever. By having these metrics, we can have better insight into issues and throttling before it starts to effect the application running.
Some of the main metrics that would be great to have are
user count
Library count
model count
file count
tag count ( total amount of tags)
how many models are on each tag ( so we can see which tags have the most on say grafana)
creator count
everything listed under /admin/performance if possible
Nice to have metrics
downloads count of each model/file
disk space used for each library (not sure if this is tracked internally or not. if not it can be gotten using other tools easily enough)
Describe alternatives you've considered
I have started minor work on this feature myself using Nodejs using the database to get a few of features listed above into my monitoring stack. Having a REST API with an auth token for security, I can change paths on my design to use less resources over all and be easier on the system preventing deadlocks that may happen currently.
Additional context
some examples of well designed exporters are
Describe the solution you'd like
It would be great to have an endpoint ether built in (you can use https://github.com/prometheus/client_ruby) or using an API as a separate exporter, that exposes metrics and statistics of the running manyfold. By having this endpoint as ether way, It will allow people to use standard monitoring tools that they are use to for anything that can ingest Prometheus endpoints. The benefits of using a Prometheus based endpoint is that it is a pulling based monitoring solution and in such case will just need a page that pulls the more recent information from below on each scrape from the Prometheus sever. By having these metrics, we can have better insight into issues and throttling before it starts to effect the application running.
Some of the main metrics that would be great to have are
Nice to have metrics
Describe alternatives you've considered
I have started minor work on this feature myself using Nodejs using the database to get a few of features listed above into my monitoring stack. Having a REST API with an auth token for security, I can change paths on my design to use less resources over all and be easier on the system preventing deadlocks that may happen currently.
Additional context
some examples of well designed exporters are
The text was updated successfully, but these errors were encountered: