Add more capabilities for severity and priority

[kenperkins]

Figure out how to not hardcode <25> as part of our message to Papertrail. I presume there is a specification for this, perhaps as part of syslog. cc @eric for more info

[troy]

Sure is, it's RFC 3164 in section 4.1.1, "PRI part." You'll see the facilities and severities listed with names and IDs and how to calculating the resulting PRI.

I recommend retaining the same facility for all messages and only changing the severity. The challenge is deciding what messages are more critical severity. If event severity is exposed from Node and Winston, I'd make it 1-to-1 (or many-to-1 if it has lots of severities) with that.

If it's not exposed, a static value like exists today may be the best that the adaptor can do.

[kenperkins]

Winston supports log levels, i.e. debug, verbose, info, warn and error are common levels. Generally speaking error (and maybe crit) are considered the most severe.

[kenperkins]

Excerpt:

The Priority value is calculated by first multiplying the Facility
   number by 8 and then adding the numerical value of the Severity. For
   example, a kernel message (Facility=0) with a Severity of Emergency
   (Severity=0) would have a Priority value of 0.  Also, a "local use 4"
   message (Facility=20) with a Severity of Notice (Severity=5) would
   have a Priority value of 165.  In the PRI part of a syslog message,
   these values would be placed between the angle brackets as <0> and
   <165> respectively.  The only time a value of "0" will follow the "<"
   is for the Priority value of "0". Otherwise, leading "0"s MUST NOT be
   used.

So do we still want to use a hardcoded facility (25) and then map log levels to severity and formulate accordingly? That doesn't seem terrible. Does Papertrail make use of this information?

[troy]

Yes, though the current hardcoded 25 is the value of both severity and facility, so it will go away entirely. I'd recommend using Local0 or User for the hardcoded facility. With User, facility code 1, the resulting value would be 1 * 8 + the severity code, or 8 + 2 = 10 for critical.

All of these values have one major problem: they're set once by the framework developer, not by the app developer or ops staff, even though something that is critical in one environment is debug in another. Papertrail uses that as a design consideration and puts relatively little faith in these. They're usable as search attributes (for example, severity:error or severity:(err crit)) and retained in log archives, but don't appear in the interactive log viewer.

[kenperkins]

It wouldn't be hard to tell the transport what facility to use at transport creation time.

[kenperkins]

This appears to be resolved as part of #29

[kenperkins]

And of course I published this, without reconciling that @jahqueel's work on #29 is a different RFC than this one. I'll have to do some due diligence to see how these RFCs are different.

[eric]

Using the newer RFC isn't a problem at all (and is preferable) for Papertrail.

[eric]

I haven't reviewed the library in detail to ensure that it is compliant, but assuming it is, everything should be great.

[kenperkins]

I (probably not obviously) tested it against Papertrail, and was able to search on severity successfully. But, I didn't do any research beyond that before I published. I assumed (When it worked) that it was the same RFC.