Recently Diego complained with me about the mod_accesslog I quickly drafted for Feng.
I didn’t check much about supporting bare files log but I just used syslog since that’s what I use for all the services that support it. Luckily he fixed the glitches I left since his usage patterns are quite different than mine.
Bare file logging usually is used by default in certain applications mostly because:
- You want to keep per-usage/per-user/per-deploy logs (think certain apache deploys)
- Your application doesn’t support syslog at all
- You didn’t knew about syslog and/or your logger daemon is a pain to configure
- You are fond of logrotate and/or you like to get your disk full of historic data
Having syslog based logging usually has some disadvantages over bare file just because you have to configure both the logger and the application, but gets quite handy when you need to tune all the logs in particular ways like sending them over the network or having the server automatically notify critical issues over email.
I really dislike bare file logging, mostly because I’m quite fond of metalog (so I’m not afraid of configuring my logger) and while deploying gluster for Stack! Studios render farm I really hated having those stupid bare files around while the rest of the well behaving applications would had their log correctly routed from the storage nodes to the almost centralized logging facility.
Having proper centralized logging is surely useful when you have to admin a system with a large number of applications, but for a big and increasing number of nodes it gets a boon.
Moreover if you plan to have read-only netbooted root images and almost zero local storage (more on the crazy solution I’m baking with bartek at Stack! could appear sooner or later) you really start to love it (and have a love-hate relationship with syslog-ng for its less than crystal clear documentation)