It's the main reason why I'm thinking about migrating everything to Caddy.
It's the main reason why I'm thinking about migrating everything to Caddy.
In this particular case, the ngx_http_api module offers way more monitoring options but is gated behind nginx Plus.
Only "serious" companies need that (as a hobby project maintainer you probably don't need it)... and if you really want to make sure you don't give them a cent, you can build your own monitoring on top of nginx easily enough.
But if Caddy can serve metrics which I can then collect with for example Grafana, that’s very interesting!
But caveat: we don't have maintainers who understand metrics currently, so it's nowhere near as good as we'd hope it to be. Help wanted!
That said, I've been running it since the early days, on super heavy production loads and never felt the need to have some more "decent" metrics out of it. I assume you're referring to real time metrics here.
Most if not everything can be gathered from the logs, which nginx is very flexible with.
I fail to understand why some missing metrics in a great product make you think to migrate everything to Caddy?
My tests in controlled environments show that caddy is absolutely fine for my workload and has perks that make my life easier. Some have been mentioned in this thread already.
Metrics is a must have in our case as we have many things to manage, few people to maintain things and alerts are the only way to grow. For alerts you need metrics.
No product would ever cater to each and every need, and that's fine.
You have choice, if something doesn't satisfy you, you can sometimes fix the problem, improve the product or write your own module (when its opensource), or switch to another solution. Look at the opentelemetry comment below as another possibility to get what you want done.
There are so many choices today, and you enjoy the freedom of choice. If something else works better for you, use that other something.
There's no need to complain.