Post by tophercantrell on Jul 12, 2018 14:25:46 GMT
The current schema (LogEntry.v1_3_0.json) includes only three event severities: OK, Warning, and Critical.
That gives us just one "everything is ok". But even "OK" messages have differing importance.
Using SYSLOG, for instance, a user logging in might be a NOTICE (Normal but significant). As opposed to a user fat-fingering their password (invalid login attempt) which might only be INFORMATIONAL. Five consecutive login failures on the same session -- likely a WARNING. If the login code reports it fell back on LDAP to check the credentials -- that's probably just DEBUG. If the Line Printer is on fire -- let's get an ALERT.
Any chance of getting additional severities added to this enum so we can better filter/route events?
What's interesting about this is while LogEntry defines Severity to follow the "Health" enum, other properties in the data model (like Severity in Message and in Event) all define it as a string, but the LongDescription points to the Status definition (where Health is defined). What's also interesting is in our published message registry files, we're following the Health enum (OK, Warning, and Critical).
Changing Severity in LogEntry to simply be a string like in other portions will likely cause interoperability issues (since vendors have the chance to define their own terms).
We may want to preserve the Health enum for the sake of keeping Status clean, but add a new enum definition to use for Log (and probably Event, Message, and some other locations) that contains the Health enum plus some more members (like Emergency and Notice). Will need to see if this breaks existing implementations though; the LongDescription language does at least call out "Status", but it's not a hard tie to the Health enum.