SeverityLevels

This is how Severity Levels are usually treated in SysLog and jachLog uses the same severity levels.

Is up to each application to define what each severity level log message means to its staff, take the following table as a guide to match what is considered standard in the industry.

---

SEVERITY LEVEL	EXPLANATION
EMERGENCY	A panic condition - the entire application may not work due to this condition. Notify all tech staff on call?
ALERT	Should be corrected immediately - notify staff who can fix the problem - example is loss of backup ISP connection or loss of secondary database connection.
CRITICAL	Should be corrected immediately, but indicates failure in a primary system - fix CRITICAL problems before ALERT - example is loss of primary ISP connection or loss of primary database connection.
ERROR	Non-urgent failures - these should be relayed to developers or admins; each item must be resolved within a given time.
WARNING	Warning messages - not an error, but indication that an error will occur if action is not taken, e.g. file system 85% full - each item must be resolved within a given time.
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.
INFORMATIONAL	Normal operational messages - may be harvested for reporting, measuring throughput, etc. - no action required.
DEBUG	Info useful to developers for debugging the app, not useful during operations. Usually is filtered out, except when developers ask to include it while fixing problems on the source code.

---