> Tina Bird <tbird@precision-guesswork.com> writes: > > > So maybe we could reach consensus on the categories of events that > > fall into different syslog priorities, for a start? > > Is this what you meant? - or is it a waste of time :-) > > Priority = (facility, level) > > Facilities are hard - they are so open ended, and how finely you cut > it depends on how much granularity your operation has in any area. > No solution wins for everyone. Sure - if you try to use a flat namespace. How about using facilities like:- system.kernel daemon.bind application.X.Netscape Allows easy filtering rules, and yet ensures that all facilities can be globally unique. The down side is that you have to use a string for the facility, not an integer. Seems like a small price to pay to me..... > > > Levels are much easier: > > For example take an ops point of view on the levels, classifying > events on the basis of what action should be taken when they occur. > Imagine flow of entries into a NOC and fielded by ops staff. > > Paraphrasing "man syslog" on my workstation: > > LOG_DEBUG info useful to developers for debugging the app, not useful > during operations > > LOG_INFO normal operational messages - may be harvested for reporting, > measuring throughput, etc - no action required > > LOG_NOTICE events that are unusual but not error conditions - > might be summarized in an email to developers or admins > to spot potential problems - no immediate action required > > LOG_WARNING warning messages - not an error, but indication that an > error will occur if action is not taken, e.g. filesystem > 85% full - each item must be resolved within a given time > > LOG_ERR non-urgent failures - these should be relayed to > developers or admins; each item must be resolved within > a given time > > LOG_ALERT should be corrected immediately - notify staff who can fix > the problem - example is loss of backup ISP connection > > LOG_CRIT should be corrected immediately, but indicates failure in > a primary system - fix LOG_CRIT problems before LOG_ALERT > - example is loss of primary ISP connection > > LOG_EMERG a "panic" condition - notify all tech staff on call? > (earthquake? tornado?) - affects multiple apps/servers/sites... > > --------------------------------------------------------------------- > To unsubscribe, e-mail: loganalysis-unsubscribeat_private > For additional commands, e-mail: loganalysis-helpat_private --------------------------------------------------------------------- To unsubscribe, e-mail: loganalysis-unsubscribeat_private For additional commands, e-mail: loganalysis-helpat_private
This archive was generated by hypermail 2b30 : Fri Aug 17 2001 - 08:33:59 PDT