4 ms·

"every possible use case" is a bit of hyperbole; there are plenty of non-load-balancer use-cases for nginx. Serving static files, relaying RTMP streams, and run

"every possible use case" is a bit of hyperbole; there are plenty of non-load-balancer use-cases for nginx. Serving static files, relaying RTMP streams, and running OpenResty applications, for example. But if load balancing is your killer feature, maybe it is the wrong choice.

user5994461 10y ago
The status page is indeed a mandatory feature for a load balancer, when something is down you simply look at the page to see what's down. Many days of downtime and debugging lost because of not having that page. It's less critical for a web server doing only one thing (a static folder or a single app). However, you still can't get metrics like time to load a page, connections per second, cache hits, error rates, etc... because nginx doesn't expose its metrics (for use by graphite/statsd and equivalent). Metrics are a paid feature, $1900 per server :D
- orf 10y ago
  > when something is down you simply look at the page to see what's down Or look in the logs. Or have your monitoring system tell you what is down, the moment it goes down? It's a good feature, it's not an absolutely critical stop the world women and children first feature.
  - user5994461 10y ago
    The status page is quicker and more readable than logs. By the way, nginx doesn't format logs properly. You think that a HTTP status code is a number? Nginx will give you "-" or "503,503" as well. Not sure if the paid edition have correctly formatted log. Your monitoring system can't integrate with nginx. nginx doesn't expose its metrics as I just said in the last message. You need to pay nginx plus.
    - orf 10y ago
      Your monitoring system has no need to integrate with nginx... It would monitor your actual systems, not nginx's ability to monitor your systems. Nginx shouldn't be the first to tell you system x is down. A poor man's solution could be a bash while loop with wget and sleep, hitting the actual servers or just the nginx frontend. A better solution would be any one of the hundreds of monitoring systems you can pick from that do exactly that, and integrate with nginx. And yes, those are valid values for status codes. A tad surprising at first perhaps. Nginx exposes logs. Your monitoring system can handle those logs. A simple tail and a grep for 'Upstream server failed' in the error log would be fine. Better than manually opening some custom gui that offers the same info, just in a worse format you can't work with.

user5994461 10y ago

The status page is indeed a mandatory feature for a load balancer, when something is down you simply look at the page to see what's down. Many days of downtime and debugging lost because of not having that page. It's less critical for a web server doing only one thing (a static folder or a single app). However, you still can't get metrics like time to load a page, connections per second, cache hits, error rates, etc... because nginx doesn't expose its metrics (for use by graphite/statsd and equivalent). Metrics are a paid feature, $1900 per server :D

orf 10y ago
> when something is down you simply look at the page to see what's down Or look in the logs. Or have your monitoring system tell you what is down, the moment it goes down? It's a good feature, it's not an absolutely critical stop the world women and children first feature.
- user5994461 10y ago
  The status page is quicker and more readable than logs. By the way, nginx doesn't format logs properly. You think that a HTTP status code is a number? Nginx will give you "-" or "503,503" as well. Not sure if the paid edition have correctly formatted log. Your monitoring system can't integrate with nginx. nginx doesn't expose its metrics as I just said in the last message. You need to pay nginx plus.
  - orf 10y ago
    Your monitoring system has no need to integrate with nginx... It would monitor your actual systems, not nginx's ability to monitor your systems. Nginx shouldn't be the first to tell you system x is down. A poor man's solution could be a bash while loop with wget and sleep, hitting the actual servers or just the nginx frontend. A better solution would be any one of the hundreds of monitoring systems you can pick from that do exactly that, and integrate with nginx. And yes, those are valid values for status codes. A tad surprising at first perhaps. Nginx exposes logs. Your monitoring system can handle those logs. A simple tail and a grep for 'Upstream server failed' in the error log would be fine. Better than manually opening some custom gui that offers the same info, just in a worse format you can't work with.