There’s a command listed in the docs, which I saw referenced at the post linked to before, that’s supposed to allow you to log memory stats for the hugo application
hugo server --memstats mystats.txt
However, running that command started my server and when I stopped my server, there was no output in mystats.txt
Is it a command that logs continuously while the server is running? or is it done once after the server stops (which wouldn’t make sense to me)
Can anyone explain
Yea,
That flag is a leftover (I forgot to remove it, now it is deleted).
There is a --printMemoryUsage flag, but it only prints at interval during the initial build. I recently tried to let it run while the server was running, but it had some side effects that I would not explain, so I reverted.
In the latest source there is a
--pprof enable the pprof server (port 8080)
Flag on hugo server that can be useful if you know what you’re doing. I would say that it’s mostly useful for Hugo development and not so much site development.
Thank you for your reply.
It would be very useful to expose server metrics to connect to services like Prometheus. Go has a package (expvar) that does this on the debug/vars endpoint and it wouldn’t have the side-effects of printing runtime.Memstats every N interval.
Would you be open to a pull request to add the expvar import in the server package
_ expvar
The only issue is that there are no conditional imports in Go, so everyone would have these metrics exposed on their server but not everyone would want/use them. In that case, you could do the following so people can opt-in to the expvar package.
_ expvar as an import in every builddebug/vars to the homepage so, by default, the debug/vars endpoint is not exposed--useExpvar etc) during the build, then don’t include the redirect.So, the redirect would have to check for the expvar flag (or whatever you called it)
What do you think? Prometheus and DataDog etc are very popular these days. Having some metrics exposed during the server run would be very nice.