| Date: | April 4, 2006 / year-entry #119 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20060404-00/?p=31673 |
| Comments: | 19 |
| Summary: | A common suggestion is that if a problem is detected which the system automatically recovered from but which an administrator might be interested in knowing about, then an event log entry should be created. Be careful, however, not to abuse the event log in the process. If the problem is not security-related and it can... |
A common suggestion is that if a problem is detected which the system automatically recovered from but which an administrator might be interested in knowing about, then an event log entry should be created. Be careful, however, not to abuse the event log in the process. If the problem is not security-related and it can occur, say, more than a few times a day, then generating an event log entry may do more harm than good. The event log has a maximum log size (default 512KB on Windows XP), and when the log fills, older log entries are discarded to make room. If you generate a lot of events, you can end up filling the event log with your events, pushing out all the other events that the administrator might have been more interested in. Even worse, the administrator may have disabled automatically discarding old event log entries, in which case the system will generate error messages once the event log fills. Network administrators make it a habit to go through the event logs of the machines on their network looking for unusual activity. If you fill the event log with chatter, this makes it harder for them to spot the real problems. |
Comments (19)
Comments are closed. |
Do you happen to know why the default event log size so small?
And would there be any mileage in being smart about what to discard, so that you discard younger "information" log items in favour of older "error" items?
(On some other systems, old copies of the "critical" log are kept longer than old copies of the "debug" log. If the "debug" log is kept at all)
Logging services on other operating systems notice when a particular message is getting logged repeatedly. Depending on the problem, applications may attempt to log messages thousands of times a second. In these situations, the logging service would, when the flood stops (or a different message is received), record how many times the previous message was repeated. This seems to be a good balance between recording the events accurately and preserving space.
I’ve seen several scenarios where the eventlog gets spammed with dozens of identical messages.
One thing that I like about syslog implementations is the way multiple identical messages in succession can be “collapsed” into “previous message repeated N times”.
That would seem to be a good solution.
If you use the MSFTP service at a busy site, you have probably seen hundreds of log-clogging "connection closed because of inactivity" messages every day. No way to keep the service from barfing those out, as far as I can tell.
Windows is guilty itself.
For a single scratched cdrom, it often fills entire pages of I/O read errors.
It’s not scratched! It’s passed on! This CD is no more! It has ceased to be! It’s expired and gone to meet its maker! It’s a stiff! Bereft of bits, it rests in peace! If you hadn’t stuffed it in its sleeve it’d be pushing up the daisies! Its decodable processes are now ‘istory! It’s off the twig! It’s kicked the bucket, it’s shuffled off its mortal coil, run down the curtain and joined the bleedin’ choir invisibile!! THIS IS AN EX-CD!!
-Wang-Lo.
Better yet (at least IMO): Let the admin configure what gets logged in the first place. (This would be per program, though, not a setting in the event log system itself.)
If everyone followed this, then I wouldn’t have to deal with Dell’s once-per-half-hour "OMG your chassis has been opened!!!1!1" messages, because I could disable them. (Yes, I can disable chassis intrusion in the BIOS, but not remotely, and I have to take the machine down to do it. These particular machines run our barcode labeling program, and usually can’t be taken down except in an emergency.)
I also wouldn’t have to deal with Microsoft’s "service X has been sent a start control" … "service X has successfully started" … "service X has been shut down" trio of events in the system log for *every service* at *every reboot* in XP. (Sigh.)
Ugh and SSHD which by default logs *five* messages for every failed connection attempt in the Application log…
I don’t read event logs. They are filled with irrelevent stuff. It’s also a mistake I made once, writing all status of a program to the app log so I could diagnose by phone. It made the app log useless for any other, say its normal, purpose. But then I only added to the useless clutter.
The errors I chased down in the log have all been irrelevent. I’ve learnt not to waste my time. Error notification is a flawed design.
If admin logged on errors should be reported (system notification area – I’m a pro tooltip and similar person – there are too few tooltips with too little extra info that take too long to popup). If not they should be either sent to the DC console or shown on next admin loggon (depending if wks or domain).
news:\msnews.microsoft.come0u97h$hjk$1@news1.completel.net
Above is a message from a thread today with someone’s bewilderment of getting info from XP.
Perhaps this is a chance for MS to develop a massively over-engineered solution with 5000 critical points of total system failure. The System Restore guys may be free.
Linux syslog doesn’t actually store collapsed messages, instead when you view the log (using logwatch perhaps?) a perl script kicks in to parse them and display them in the ‘blah blah blah – x times’ format.
I think that would make sense for the Eventlog, even if it is a ‘collapsed’ view where all multiple messages are collated under a collapsed treeview item. The disadvantage is that you couldn’t see the timeline of events, but it would make initial viewing of the log much easier.
Linux syslog actually DOES filter duplicate entries
# grep repeated /var/log/syslog
Apr 5 09:13:43 xxxx last message repeated 3 times
Apr 5 09:14:37 xxxx last message repeated 5 times
Apr 5 09:15:50 xxxx last message repeated 7 times
But if there are two programms spamming at the same time or the log line changes even one letter, you’re out of luck.
Ben Hutchings: There’s a team working on the next generation of event logging, called "Crimson". There’s a brief mention of it here: http://www.eweek.com/article2/0,1895,1826615,00.asp
That’s pretty much all I know about Crimson.
Writing a logging system worth a damn would make things better.
* Provide a generic message DLL, or make message DLLs optional. The requirement for message DLLs makes remote access to event logs nigh-on useless.
* Allow logs to grow larger and implement configurable log rotation.
* Allow exporting entire log files as plain text.
* Use the log consistently. Currently I often see message boxes for service failures, directing me to the event log, which doesn’t actually show me the messages.
Don’t forget that some people (or possibly governments) audit everything, and cannot afford neither losing events (full eventlog/overwrites) nor crashing when the eventlogs are full (crashonauditfail), so there is http://support.microsoft.com/default.aspx?scid=kb;en-us;312571 which implements AutoBackupLogFiles.
The default value on install is delete items older than 7 days. This is a pain as the event logs fail if 512k is reached. It’s on my checklist of changes for "things that are really irritating" on a fresh install.
PingBack from http://blogs.msdn.com/oldnewthing/archive/2006/07/13/664448.aspx
PingBack from http://blogs.msdn.com/ricom/archive/2006/07/19/671937.aspx