21–30 of 47 posts
Earlier quoted context omitted.
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.
Perhaps, but there are plenty of scenarios where restarting won't help (e.g. daemon misconfiguration).
Earlier quoted context omitted.
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.
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?
The major difference between a thing that might go wrong
and a thing that cannot possibly go wrong is that when a
thing that cannot possibly go wrong goes wrong it usually
turns out to be impossible to get at or repair.
Earlier quoted context omitted.
put your logs in /dev/shm oh and don't remember to rotate them!
If you need guaranteed log delivery, I wouldn't do that. Unread logs won't survive a power failure or system crash.
"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".
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.
Earlier quoted context omitted.
If you need guaranteed log delivery, I wouldn't do that. Unread logs won't survive a power failure or system crash.
Aren't you also not ensuring delivery when using remote syslogging in default mode? I believe this is all logged via UDP, so if the network or syslog host is overloaded your syslog messages will be silently dropped.
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_l…
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.
Do you just crontab logrotate for short intervals, and will that trigger "daily" rotations each time for other configurations?
Earlier quoted context omitted.
If you need guaranteed log delivery, I wouldn't do that. Unread logs won't survive a power failure or system crash.
Aren't you also not ensuring delivery when using remote syslogging in default mode? I believe this is all logged via UDP, so if the network or syslog host is overloaded your syslog messages will be silently dropped.
Earlier quoted context omitted.
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.
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?