-
-
Notifications
You must be signed in to change notification settings - Fork 49
feat: remove /metrics from the website #703
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
base: main
Are you sure you want to change the base?
Conversation
215a9df to
84d461f
Compare
cliffmccarthy
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me, and appeals to my "negative lines of code" sense.
84d461f to
a933411
Compare
|
@link2xt this was a point of confusion for some relay operators, glad it's being factored away. the mtail works quite well as it is. |
|
fsreport doesn't tell you how many accounts, only login stats. But it would be easy to update fsreport to add it. |
a933411 to
a27adb1
Compare
a27adb1 to
3381424
Compare
3381424 to
b4a027d
Compare
This was brought up on the forum again: https://support.delta.chat/t/userbase-information/4567/4 So rebasing it. |
|
in the spirit of reducing unnecessary external metadata, let's just do this if there aren't any blockers |
|
I just stumbled across this today; but it did not seem the metrics where equivalent to the ones from mtail: vs mtail (and there seems to be something weird going on with that mtail output) Maybe we should just output the metrics to |
|
Don't know why your output looks like this, something is probably wrong with the terminal. |
b4a027d to
d9e0f3a
Compare
|
I understand, mtail is providing the rate of account creation; I think it would be helpful to be able to monitor total accounts on the relay continuing removal of the public /metric. Incorporating it into fsreport would be sensible I suppose, ideally with openmetrics-compatible output. If I understand correctly, fsreport is already running by systemd-timer regularly? Re output, I indeed can't reproduce this issue atm. |
|
So far, /metrics allows to get an outside impression how many addresses are on a server.
CLI/systemd fsreport run only gives it to admin.
I skimmed the chain of referenced issues, but i didn't see a clear rationale
why we don't want the number of addresses to be publically visible outside.
…On Wed, Oct 29, 2025 at 05:15 -0700, l wrote:
Similar data is already generated by fsreport
available for the relay operator
and metrics for prometheus are generated by mtail.
Closes <#431>
You can view, comment on, or merge this pull request online at:
#703
-- Commit Summary --
* Remove /metrics from the website
-- File Changes --
M ARCHITECTURE.md (2)
M README.md (3)
M chatmaild/pyproject.toml (1)
D chatmaild/src/chatmaild/metrics.py (32)
M cmdeploy/src/cmdeploy/__init__.py (17)
D cmdeploy/src/cmdeploy/metrics.cron.j2 (1)
M cmdeploy/src/cmdeploy/nginx/nginx.conf.j2 (4)
-- Patch Links --
https://github.com/chatmail/relay/pull/703.patch
https://github.com/chatmail/relay/pull/703.diff
--
Reply to this email directly or view it on GitHub:
#703
You are receiving this because you are subscribed to this thread.
Message ID: ***@***.***>
|
Similar data is already generated by fsreport available for the relay operator and metrics for prometheus are generated by mtail. Closes <#431>
d9e0f3a to
3b852b0
Compare
|
Why do we want to expose the number of addresses to everyone on the internet? What is the usecase for knowing the number of addresses on servers that are not run by you? |
Similar data is already generated by fsreport
available for the relay operator
and metrics for prometheus are generated by mtail.
Closes #431