Hacker News Reader

Comment by christophilus | Hacker News Reader

You just need fast print strings. Leave log rotation up to the OS and it’s tools.

I wish I could tell you how many times I've seen a machine run out of disk space because logrotate had been failing since the last time someone pushed out a config, or a new log file appeared with a software upgrade. It's gotten to the point where I give /var/log its own disk partition now, and hunt down any logs in /opt and bind mount them into /var/log. Screw the logs, I want my system to keep running.

I am 1000% in favor of apps managing their own logs. Generic system agents can collect and ship arbitrary logs remotely for storage/processing.

That's why you set your OS to rotate everything inside /var/log. And yes, chase down the other logs and place them there.

> It's gotten to the point where I give /var/log its own disk partition now,

Putting /var on its own partition has always been recommended.

When default installer/partitioners fail to do so, I assume it's a habit picked up from desktop-oriented Linux distros.

Logging to /opt would clearly be a bug of the brown M&M variety -- it would make me question other decisions made by the developers.

If you have a standard cloud image and want it to use all the disk given to it, one big xfs partition is easier than a bunch of various little partitions for the sake of not filling the root partition. Hopefully everything log rotates well and you have disk full metrics/alarms when they don't. And the architecture should be if the node goes bad for any reason just replace it (with hysteresis so you don't kill all the zookeepers at once when new traffic and bad rotation/rentention fills the disks all at once)

Your "easier" has a lot of complicating qualifications. :)

I'd describe single-partition as "slightly simpler, but requiring additional support mitigations, and less effective at the primary job of keeping systems running".

I prefer:

One partition for / which is required to have an operable system for diagnosis of problems

One partition for /var which is expected to grow with limited predictability

One partition for the rest, which should be largely static depending on function, but sometimes surprises you regardless.

...

With elastic scaling compute nodes and centralized logging, most of these issues are subsumed into the enormous support infrastructure and can be ignored. But some applications don't map well to that environment.

How does it work? Do I need to close/reopen file after every log message?

No, just close and re-open the file when you receive a specific signal, generally SIGHUP, from logrotate or any equivalent tool.

I don't think that Java can handle UNIX signals, at least without some internal API.

Reply on news.ycombinator.com