Author here :) Thanks Oscar.
With `accounting` module, the metrics such as status codes, rates, and
response time are logged,
you can let it write to a local file, or (by default) via syslog to forward
them to remote host/app.
Another way is use ELK stack, document here:
https://translate.google.
Perhaps this can be useful for you:
https://github.com/Lax/nginx-http-accounting-module
Kind regards,
Oscar
On Wed, Apr 11, 2018 at 6:19 AM, Jeff Abrahamson wrote:
> I want to monitor nginx better: http returns (e.g., how many 500's, how
> many 404's, how many 200's, etc.), as well as request r
Just to be clear, I’m not contrasting active synthetic testing with monitoring
resource consumption. I think that the highest value variable is $, or those
variables that have highest correlation to profit. The real customer experience
is probably #2 after sales. Monitoring things like active c
So under the covers things are rarely as pretty as one hopes. In the example
quoted the influxdb instance was actually a pool of different pre 1.0
instances- each of which had different bugs or fixes. The log script actually
pushed 15:30 worth of data to intentionally overlap.
The most surprisi
On Wed, Apr 11, 2018 at 01:17:14AM -0400, Peter Booth wrote:
> There are some very good reasons for doing things in what sounds
> like a heavy inefficient manner.
I suspected, thanks for the explanations.
> The first point is that there are some big differences between
> application code /busine
Jeff,
There are some very good reasons for doing things in what sounds like a heavy
inefficient manner.
The first point is that there are some big differences between application
code/business logic and monitoring code:
Business logic, or what your nginx instance is doing is what makes you mon
This module can get you started:
https://github.com/gfrankliu/nginx-http-reqstat
On Tue, Apr 10, 2018 at 9:19 PM, Jeff Abrahamson wrote:
> I want to monitor nginx better: http returns (e.g., how many 500's, how
> many 404's, how many 200's, etc.), as well as request rates, response
> times, etc.
I want to monitor nginx better: http returns (e.g., how many 500's, how
many 404's, how many 200's, etc.), as well as request rates, response
times, etc. All the solutions I've found start with "set up something
to watch and parse your logs, then ..."
Here's one of the better examples of that: