Other ideas:<br><br>1. What about having haproxy send to multiple syslog servers? One for logging and one for processing?<br><br>2. If rotating the log files causes it to restart, then don't rotate. Either remove the log file or send them to /dev/null. Let your program that watches the pipe do the logging.<br>
<br>3. You could write your own syslog daemon that captures the syslog
stream, handles the logging, and does the processing of log files. With
off the shelf modules, it's probably not that complicated.<br>
<br>4. Another high end method for what you are doing is to have your logging daemon break the logs apart and insert then in a structured SQL database. Then of course your methods for processing, alerting, reports, and rotating will be completely different.<br>
<br>~Travis Sidelinger<br><br><br><br><div class="gmail_quote">On Thu, Aug 2, 2012 at 11:32 PM, Jeff Frontz <span dir="ltr"><<a href="mailto:jeff.frontz@gmail.com" target="_blank">jeff.frontz@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm not sure I completely understand the intent/implementation but wouldn't this work?<br>
<br>
while true<br>
do<br>
processPipeContents < namedPipe<br>
done<br>
<br>
The alternative would be to (if I remember the FIFO semantics) write something that opens the FIFO in non-blocking mode and then poll/select it.<br>
<span class="HOEnZb"><font color="#888888"><br>
Jeff<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Aug 2, 2012, at 19:50, Rick Hornsby <<a href="mailto:richardjhornsby@gmail.com">richardjhornsby@gmail.com</a>> wrote:<br>
<br>
> Curious about opinions/thoughts. I have haproxy logging activity via<br>
> syslog. HAproxy logs contain lots of useful information about HTTP<br>
> transactions (request, timing, result code, etc). I'd like to process<br>
> the logs in real time, so I set up syslog to not only write the log to<br>
> a file, but also to a named pipe, /tmp/haproxy.log.pipe. I figured<br>
> this would be the ideal way to peel off and process log data as it<br>
> happened (using awk, etc) - realtime.<br>
><br>
> Except for one thing - when syslog restarts for logrotate, the pipe is<br>
> broken for a moment. Anything reading from the pipe dies, because<br>
> that's how pipes work. So the script that was processing the log data<br>
> coming off the pipe goes away.<br>
><br>
> One alternative is to tail -F /var/log/haproxy.log |<br>
> /path/to/processor, but boy that just seems hackish - and not in the<br>
> good way.<br>
><br>
> Is a named pipe the right tool? Does it make sense to somehow trap<br>
> the signal that is causing the script to bail? It isn't critical that<br>
> every single log event be processed, but we want to make a best effort<br>
> so that we're not losing information.<br>
> _______________________________________________<br>
> colug-432 mailing list<br>
> <a href="mailto:colug-432@colug.net">colug-432@colug.net</a><br>
> <a href="http://lists.colug.net/mailman/listinfo/colug-432" target="_blank">http://lists.colug.net/mailman/listinfo/colug-432</a><br>
<br>
_______________________________________________<br>
colug-432 mailing list<br>
<a href="mailto:colug-432@colug.net">colug-432@colug.net</a><br>
<a href="http://lists.colug.net/mailman/listinfo/colug-432" target="_blank">http://lists.colug.net/mailman/listinfo/colug-432</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>"A careful reading of history clearly demonstrates ...<br>that people don't read history carefully.”<br><br>“We can't solve problems by using the same kind of thinking we used when we created them.”<br>
—Albert Einstein<br><br>