Just a note of log consolidation issues.

There are numbers of tasks around sysadmins and security engineers at the data centers, which include log management and monitoring the servers/clients to check if there is an unusual thing happening/ongoing.

I have begun to think of this one year ago when around me there were many of "untouched" or unmanaged as for the system environment. With such a server, when a trouble happens there is no one who could trace what is wrong or what should be done, or worse, when the box downs. It is not cool....

So, to trace the anomalies I am now heading in log consolidation/management to have evidence enough for troubleshooting and detection of problems.

What I have completed:

1. consolidating logs and alerts of network appliances, routers, (managed) switches, firewalls.
   This means I have to collect both syslog messages and SNMP traps.
   
   To do this I am using WinSyslog from Adiscon as a central location for storing syslog messages and Kiwi Syslog Daemon to collect SNMP Traps. From Kiwi SNMP traps are translated into syslog and be poured in the syslog storage.
   
2. consolidating Event log entries from Windows Machines.
   For this I am using NTSyslog I got from SourceForge. I am still in a half way as it cannot handle multi-byte languages properly, especially around  (what do you say in English? We say this "kaigyo code" in Japanese) and Chinese characters.
   
   Another point here is the future possibilities of using of Log Parser, which is written by a guy in Microsoft.
   We can handle eventlog messages in multi-byte languages without a fear with the current versions of the tools released, as it handles those characters as Unicode.
   We engineers in regions with multi-byte languages welcome this tool very much as we do not have to think about "how to localize this cozy tool?", etc, etc.
   
   I am not yet planning utilizing this very kewl and cozy tool in my framework because I want to design "effortless and yet cohered" design, though.
   I emphasize here that I am planning to improve/change the whole design so there is such a high possibility that I will be using this tool.
   
   In the MVP Summit 2004 some of us Japanese MVPs had a chance to discuss on the tool with the author, in which we have heard there will be much improvements in severals of the coming versions. I promise he is so dedicated and is so enthusiastic. ;-)
   
3. Choosing the base platform.
   I chose the following stuffs for this system:
   A. Log consolidation
   Windows 2000 Server/Server 2003
   IIS 5.0 and later
   Active Server Pages
   Microsoft SQL Server 2000
   Adiscon WinSyslog 4.2 or later
   Kiwi Syslog Daemon (to just translate SNMP Traps into syslog messages, without an effort.)
   Softether (as providing the VPN way to collect logs of servers in several segments of different locations on the Internet.)
   
   B. MRTG and some other system monitors
   For this I am using several up to now, and I am planning to consolidate the monitors in just a few nodes, as I want to include links for the graphs of MRTG in the system A. above. I intentionally have several nodes, as in such a way I can troubleshoot more precisely where the bottle neck/system down occurs.

What I am not yet doing:

1. Consolidating logs scattered around the system and messages written in other forms
   As for these logs I am imagining api.log, setup.log, and so on which are written in the text format and scattered around the whole system for Windows OSes.
2. Consolidating Backup and Task Scheduling logs of Windows NT-Based OSes
3. Consolidating HFNETCHK/MBSA resultant texts.
4. Consolidating MRTG results
5. Consolidating results from tools for penetration testings like NIKTO, Syhunt, N-Stealth, Nessus, and so on.
6. Merging and consolidating /var/log/messages and so on in Unix platforms including FreeBSD and Linux.
7. Merging the logs of crond and the texts of logwatch from Unix platforms.
8. Consolidating results of system monitoring softwares like those released from Dell, HP, and so on.
9. Visualize the results to make it easier to confirm what is going on.
10. Issuing alerts via e-mail and web monitor pages.
11. The site design as a whole. (I am using IIS as a web server to show the results.)
12. Designing a fault-tolerant system for both SoftEther and the server.