To syslog, or not to syslog? That is the question.

At $WORK we have a simple application which acts as a wrapper around common account management tools. Its purpose is to ensure that all account move/add/change implementations are logged with who did the work and what ticket authorized it, etc. The method for this logging is currently syslog. I'm not sure sure that I would have chosen that design, and that is the topic of this post.

In general I'm made to suffer by observing the slow decay of UNIX practitioners. That's not to say that use of UNIX is in decline, but rather that people who understand UNIX are becoming fewer and farther between. Note that in this case, I lump Linux and UNIX together. So many people are hopelessly tainted by their knowledge of Windows that it creates a prism through which the light of every operating system is split between reality and perception.

UNIX is more than an operating system. It is a development platform. It contains the tools you need to handle many application components including logging, messaging, file parsing, etc. And yet, we find people frequently turning to proprietary (or sometimes open) tool kits to solve problems the OS is well equipped to handle. It frustrates me.

Given that I'm a strong proponent of using the Operating System's features to solve problems, why wouldn't I like the idea of a local script using syslog to handle its logging? The biggest reason is that today's Solaris syslog facility remains tightly constricted in its use of facilities and levels. Yes, I'm well aware that syslog-ng can open those doors. I'm all for it! However, someone at Sun (Oracle) doesn't seem to be all for it yet, and I'm not a big fan of re-plumbing core OS features. So, until Sun sees the light and modernizes the syslog facility I believe in sticking with the standard.

One approach that may be acceptable is combining all Operational logging into a single facility. The trouble with that approach is that we have some logs which fall under tougher security policies than others, so you end up needing destination files with different attributes. So, what's the answer to the engineer's dilemma?

If an application needs to send its output for Enterprise-wide real-time processing for something like a log watcher, then it may be appropriate to use syslog in order to leverage its ability to forward log streams to syslog servers. But if you are writing a simple application which diligently generates log files for audit or troubleshooting purposes, you may be better off in the long run by writing a simple log function that dumps to a configurable destination file. Of course, your log files will be stored under /var/opt/something and will integrate with logadm(1M), right? Of course. After all, you are a Jedi...