Understanding Server Log

Question

I am really grateful to members of this forum in helping and guiding me in setting up my first server. Everything appears to be running smoothly so far.  The monitoring strategy and understanding the server log will be critical. Can anyone point me to documentation that would help understanding the server log?

Answer 1

Nope.  Sorry.
There is no general documentation of the server logs (beyond scattered postings and web pages, and the associated source code for various associated component tools as that code is available, and details of logs and errors for some of the specific components from their respective maintainers), nor would I expect this sort of general console log documentation to be available due to the sheer breadth of componentry and the churn from the OS X updates and upgrades.  The process of learning the logs involves watching and learning what's normal operation for a specific server, and what sorts of patterns — blocks of repeated errors, daemons crashing and restarting, unusual delays or such — that indicate issues.   Some of the normal log chatter can look quite draconian and can spook readers, with the ClamAV warning being a popular example of this, as are various (paraphrasing) OMG OUTDATED API warnings for OS X components.
If you're starting to deal with a number of systems, then you'll be looking at implementing log analysis tools and rules, SNMP and syslog to manage the chatter.
As a more general discussion, learning the individual components from available resources is entirely reasonable and recommended, as might be learning the structure of the OS X kernel and maybe then looking at application crashes and such for more advanced understanding.  There are books and videos and various web pages on the components.  Once you know how the pieces work, knowing what's normal in the logs is a little easier.
Monitoring system activity can help, too.  It's fairly common to see a failure generate excessive disk I/O or processor activity, and spool up the fans.  Security breaches and DDoSes and such can generate similar loads.  The server gets, well, hot.  If you watch the server and network activity, you can know when your system is busy, and know when it's busy for no obvious or good reason.  At a more advanced policy and planning level, plotting activity over time can tell you when your server is headed toward an overload.
Monitoring the core server forum postings via RSS feeds (eg: this forum) can help spot trends and what become known bugs, as can be membership on the Mac Enterprise mailing list.  I also follow various security-oriented notification lists and RSS feeds, including those RSS feeds from Apple and those associated with components and tools I use.  (These can also help you learn the system and the tools, too.)
More generally, have backups, consider and potentially implement periodic off-site backups, learn IP networking and DNS and maybe managed switches and DMZs and the rest if and as you scale up, get onto notification lists for the tools and products that you use (particularly for security reports), and (generally) don't rush to upgrade OS X Server save for cases involving actively-exploited or critical security or stability problems — have your reasons for upgrading and consider the trade-offs against not upgrading, and "shiny" isn't usually one of the best reasons for an upgrade.