-
Notifications
You must be signed in to change notification settings - Fork 147
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
/metrics
should also provide repository stats
#176
Comments
It would be nice to have this extra data, but currently rest-server does not have all of this information and it could be expensive to collect from the spinnings disks that typically serve as the storage. It would be useful to have, but the implementation does require some careful consideration and we may want to make this opt-in. When quota are enabled, we do keep track of the total size, but not per user or repo (see also #65). There is also the issue of potentially leaking too much information. We probably want to move the /metrics to a different port for this reason (see also #116) and then this would not be an issue. |
Could also allow for a different .htaccess / password for the /metrics endpoint. 'Cheap' statistics should should be trivial to cache and would be extremely useful would be disk free space and repo disk size, so people could make simple alerts like 'disk about to run full'. |
Adding simple disk usage and disk free space would be a good idea, indeed. It's cheap and does not leak sensitive information. |
A new gauge metric `rest_server_repo_last_update_timestamp` was added to monitor each repository's last write access. This allows a basic monitoring for each repository's freshness. This might be related to the feature request in restic#176.
A new gauge metric `rest_server_repo_last_update_timestamp` was added to monitor each repository's last write access. This allows a basic monitoring for each repository's freshness. In order to have this metric available at startup, a basic preloading for Prometheus metrics has been implemented. This operates by scanning the file system for restic repositories and using their last modified time. Subsequently, each write access updates the last update time. If scanning each repository takes too long, it can be disabled through the `--prometheus-no-preload` flag. This might be related to the feature request in restic#176.
Output of
rest-server --version
What should rest-server do differently?
Currently the metrics reported in the
/metrics
endpoint are the default metrics for go programs and actually more about the runtime and process behavior, which is totally fine and important data, still it is missing the interesting things like number of users, number of repositories, size of them, user quotas, snapshots (per user/repo), etcWhat are you trying to do? What is your use case?
I want to collect meaningful metrics about the repository.
The text was updated successfully, but these errors were encountered: