Hacker News new | ask | show | jobs
by mkelly 5431 days ago
Depends on how much you care about latency, right?

The easy solution is just, y'know, write the log to a file and scp it back to some central place every so often. But then you have to either (a) keep track of how much of a file you've copied, which is a pain; or (b) only grab files that you're no longer actively writing to (as determined by naming scheme or something), but that introduces some latency, depending on how often you rotate.

1 comments

I prefer sending the logs to some other computer over UDP.
Why do you want to send logs over UDP?

I get that you were making a snarky allusion to syslog, but what part of the syslog UDP protocol do you feel beats Redis' TCP protocol?

I don't, really (you can use syslog pretty successfully, I guess, if you don't mind it), but UDP has certain advantages over TCP, namely that your code keeps running even if the server you're sending to goes down or is unable to respond to messages, it's faster, etc.

Ideally, I'd use a function that sent things to a small server over UDP, which would then put them in Redis. This assumes you don't mind losing a few lines, of course.

If you continuously send UDP messages to a server that isn't accepting them, you will eventually get an error from the sendto() system call; the uninterested receiving host is generating ICMP messages saying "I don't want these". It's true that there is a flavor of sloppy socket coding where that error doesn't manifest itself. But if you're writing good code, TCP is no less fire-and-forget than UDP.

UDP is marginally faster than TCP, but the tradeoff for that is that under heavy load, UDP imposes more costs on the rest of your traffic. Since we're talking about logging, though: who gives a shit how fast it is? With either transport, if logs are taking more than hundreds of milliseconds to clear, you have a problem you need to fix.

This only works if you can tolerate loss of some log items.
Very true. If you can, then it's a great way to log things.
Yikes, losing messages? If anyone designs a system that knowingly makes itself harder to diagnose under stress by destroying evidence, I only hope it's themselves and not their successors who are there to endure the pain.
As I said, it depends. If you're logging cycle completion times or web page visits, you don't care about losing a few.