<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Jeff,<div class=""><br class=""></div><div class="">There are some very good reasons for doing things in what sounds like a heavy inefficient manner.</div><div class=""><br class=""></div><div class="">The first point is that there are some big differences between application code/business logic and monitoring code:</div><div class=""><br class=""></div><div class="">Business logic, or what your nginx instance is doing is what makes you money. Maximizing uptime is critical.</div><div class="">Monitoring code typically has a different release cycle, often it will be deployed in a tactical reactive fashion.</div><div class="">By decoupling the monitoring from the application logic you protect against the risk that your monitoring code</div><div class="">break your application, which would be a Bad Thing, The converse point is that your monitoring software is </div><div class="">most valuable when your application is failing, or is overloaded. That's why it's good thing if your monitoring </div><div class="">code doesn’t depend upon the health of your plant’s infrastructure. </div><div class=""><br class=""></div><div class="">One example of a product that is in some ways comparable to nginx that did things the other way was the</div><div class="">early versions of IBM’s Websphere application server. Version 2 persisted all configuration settings as EJBs.</div><div class="">That meant that their was no way to view a web sphere instance's configuration when the app server </div><div class="">wasn’t running. The product’s designer’s were so hungry to drink their EJB Kool-Aid they didnt stop to ask</div><div class="">“Is this smart?” This why, back in 1998 one could watch an IBM professional services consultant spend weeks</div><div class=""> installing a websphere instance or you could download and install Weblogic server in 15 minutes yourself.</div><div class=""><br class=""></div><div class="">tailing a log file doesnt sound sexy, but its also pretty hard to mess it up. I monitored a high traffic email site with a </div><div class="">very short Ruby script that would tail an nginx log, pushing messages ten at a time as UDP datagrams to an influxdb.</div><div class="">The script would do its thing for 15 mins then die. cron ensured a new instance started every 15 minutes. It was </div><div class="">more efficient than a shell script because it didn't start new processes in a pipeline. </div><div class=""><br class=""></div><div class="">I like the scalar guide but I disagree with their advice on active monitoring I think its smarter to use real user</div><div class=""> requests to test if servers are up. i have seen many high profile sites that end up serving more synthetic requests </div><div class="">than real customer initiated requests.</div><div class=""><br class=""></div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 11 Apr 2018, at 12:19 AM, Jeff Abrahamson <<a href="mailto:jeff@p27.eu" class="">jeff@p27.eu</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="content-type" content="text/html; charset=utf-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""><p class="">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 ..."</p><p class="">Here's one of the better examples of that:</p>
<blockquote class=""><p class=""><a class="moz-txt-link-freetext" href="https://www.scalyr.com/community/guides/how-to-monitor-nginx-the-essential-guide">https://www.scalyr.com/community/guides/how-to-monitor-nginx-the-essential-guide</a></p>
</blockquote><p class="">Perhaps I'm wrong to find this curious. It seems somewhat heavy
and inefficient to put this functionality into log watching, which
means another service and being sensitive to an eventual change in
log format.</p><p class="">Is this, indeed, the recommended solution?</p><p class="">And, for my better understanding, can anyone explain why this
makes more sense than native nginx support of sending UDP packets
to a monitor collector (in our case, telegraf)?<br class="">
</p>
<pre class="moz-signature" cols="72">--
Jeff Abrahamson
+33 6 24 40 01 57
+44 7920 594 255
<a class="moz-txt-link-freetext" href="http://p27.eu/jeff/">http://p27.eu/jeff/</a>
</pre>
</div>
_______________________________________________<br class="">nginx mailing list<br class=""><a href="mailto:nginx@nginx.org" class="">nginx@nginx.org</a><br class="">http://mailman.nginx.org/mailman/listinfo/nginx</div></blockquote></div><br class=""></div></body></html>