NGINX syslog-ing without breaking the bank or patching the code

http://syshero.org/post/68174083489/nginx-syslog-ing-without-breaking-the-bank-or-patching

by cassianoaquino • 13 years ago

78 41 13 years ago

alrs• 13 years ago

"Devops" can be considered a philosophy, a methodology, or a movement. It doesn't mean "ops monkey smart enough to code."

Referring to a human as a "devop" is equivalent to calling someone an "agile".

angersock• 13 years ago

s/philosophy/affliction

chc• 13 years ago

It seems like a reasonable shortening of "devops engineer." If we can call people "quants," I don't suppose "devop" is all that much sillier.

rhizome• 13 years ago

Operations Engineer/Developer

csmuk• 13 years ago

Actually it usually means a dev who knows ops stuff as well.

Realistically its just a job title that means paying technical architects less money...

staunch4• 13 years ago

You can also write a pretty simple program to do essentially `tail -F /var/log/nginx/access.log | logger --server some.host`. I'm doing something like that. It works, but I still don't like it. The idea of nginx hanging while trying to write to FIFOs I like even less.

pilif• 13 years ago

The issue of the article the OP was a response to is that the traffic they are expecting is too big for the disk nginx is running on to handle the log files.

Your solution works for centralising the log, but it doesn't solve the local i/o issue as the file is still being written (which was the problem of the original article).

staunch4• 13 years ago

Easily solved by writing the logs to a filesystem in RAM (e.g. tmpfs). Have your little program truncate them as often as you need.

radq• 13 years ago

Relevant comment: https://news.ycombinator.com/item?id=6799328

" CloudFlare generates 50gb/s of logs globally and have handled collecting this volume in two ways. Historically the logs are sent to a local syslog-ng through the use of a PIPE and the forwarded to central logger. This can be done with nginx with no patches by just treating the PIPE as file. Just make sure you do a little buffering inside nginx.

access_log /dev/nginx_access log_format_name buffer=64k flush=10s;

Since this is a pipe there is still some blocking IO, but no worse off then writing to local file."

otterley5• 13 years ago

If the pipe consumer (i.e. your syslog server) stalls, then it will be much worse than writing to a local file, as it could cause a denial of service.

I would still configure nginx to write to a file and have the consumer tail it to avoid this situation. Properly-configured log rotation can keep the file size within reasonable bounds.

jsmeaton2• 13 years ago

Related question - how do you configure logrotate to honour size immediately? In my (limited) experience, logrotate runs once overnight. If you have a log file that expands by 1gb per hour, and you want to rotate it every 500mb, how do you instruct logrotate to handle it?

Do you just crontab logrotate for short intervals, and will that trigger "daily" rotations each time for other configurations?

asdasf3• 13 years ago

If the pipe consumer (i.e. your syslog server) stalls, then it will be much worse than writing to a local file, as it could cause a denial of service.

But how likely is that to happen in any circumstance that doesn't also bring down nginx anyways? Obviously in the case of a large setup like that they don't care, it just gets removed from the pool regardless of why it is failing.

semiquaver• 13 years ago

This seems dangerous -- if rsyslog crashes then the pipe is left without a consumer and all writes to it block indefinitely, exactly the opposite of how you would expect syslog to work.

icebraining• 13 years ago

You can just send an USR1 signal to nginx when you restart rsyslog (hopefully with some kind of supervisor). With Upstart, you could use a post-start script in the rsyslog service configuration.

rodgerd2• 13 years ago

If you were using systemd, I'd imagine you'd tell it to restart your syslogger automagically, and use ExecStartPost or ExecReload to tickle nginx.

otterley5• 13 years ago

Perhaps, but there are plenty of scenarios where restarting won't help (e.g. daemon misconfiguration).

nasalgoat• 13 years ago

I'm a little concerned that these days to go-to answer for a crashing daemon is to have another daemon that watches it and restarts it.

Who watches the watchers? What happened to writing things that don't break?

dmourati• 13 years ago

Working on a similar problem in our stack and didn't know about the limitations on NGINX. I used syslog-ng years ago but now we're on rsyslog. I feel like this is squarely a devops problem and one where the software producing logs is deficient.

oogali• 13 years ago

Writing to a pipe is different from writing to a local file, only because you have to be aware of what's going on behind the scenes.

If the other side of the pipe closes (e.g. syslog-ng), your process will hang once the I/O buffer fills up, which is generally 4KB.

You especially need to keep this in mind, when syslog-ng restarts (pipe closed, pipe reopened). You'll probably glance quickly to see that syslog-ng is running, and the pipe is present, but wonder why nginx is not serving traffic.

Or worse, be fooled into thinking nginx is fine because it was serving traffic up until it served 50 requests (or however many reqs it takes to generate 4,000 bytes of access logs), then stopped.

Thaxll• 13 years ago

Use Logstash it's 10 times better than 'quick' hack for those problems.

Human_USB• 13 years ago

How are you using Logstash? I have NGINX write the log, then the log-shipper suck that log file up. If you have a better work flow, please share. :)

bashtoni2• 13 years ago

Nice work!

We write the logs to disk and then use rsyslogs imfile feature to read from there. Your approach has the advantage of not requiring disk writes.

BTW, we're not in Toronto, but we're hiring and happy to accept remote workers from that timezone :)

http://www.bashton.com/jobs/

blibble• 13 years ago

put your logs in /dev/shm

oh and don't remember to rotate them!

otterley5• 13 years ago

If you need guaranteed log delivery, I wouldn't do that. Unread logs won't survive a power failure or system crash.

nightfly• 13 years ago

I suggested moving syslog support into open source nginx, and it's been accepted. Maybe show some support for it here http://trac.nginx.org/nginx/ticket/409

tzury• 13 years ago

What about this one https://github.com/yaoweibin/nginx_syslog_patch ?

NGINX syslog-ing without breaking the bank or patching the code

Related Stories