Giters

NYPL / engineering-general

Standards, values, and other information relevant to the NYPL Engineering Team.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Log Level Integer is inconsistant

nodanaonlyzuul opened this issue · comments

commented

Hi.

Our current logging guides address an optional levelCode key and gives a guide to how those integers map to the level key.

That mapping is different across programming languages:

In Ruby it looks like this:

# Logging severity.
module Severity
  DEBUG = 0
  INFO = 1
  WARN = 2
  ERROR = 3
  FATAL = 4
  UNKNOWN = 5
end

In Python it looks like:

Level Numeric Value
CRITICAL 50
ERROR 40
WARNING 30
INFO 20
DEBUG 10
NOTSET 0

So - I feel weird that our existing documentation calls out the log levels that we do.
I'm not sure what the answer is:

  1. A conspicuous caveat saying that the levels vary from language to language?
  2. Making the MAY of the logLevel key more conspicuous?
  3. 1 & 2?
  4. Removing mention of logLevel all together?
commented

#3 sounds like a good option.

Does it make a difference to say that even though logging is different across programming languages, that they all get aggregated into our AWS CloudWatch account and so we would want them to be consistent there?

commented

I think it would be really hard / weird fight languages and get them to use the same integer.
Maybe a line saying to be aware of the language / library you're using and to setup metrics using its numeric scale?

commented

I think the whole point of calling out levelCode in a standard is so that it can be relied on consistently across applications/platforms/languages. That, to me, is where the value lies. For example, when I'm searching CloudWatch for an app that I might not be 100% familiar with for errors, I can consistently do a search for { $.levelCode <= 3 } and see actionable errors. Also, we can see consistency across metric filters.

With that said, I acknowledge you will have to fight to conform different languages and libraries to this standard. As we had to do in the Node world.

I think the question for me is: is this "fight" worth it? i.e. is the effort required to have a consistent levelCode across all applications warrant the effort?

I'm happy to have a conversation about this question as it's a fair question.

My inclination is for 2: perhaps make the MAY more noticeable (maybe even make a mention to this discussion/issue) and leave the standard as-is, reserving levelCode for explicit values as defined by this standard and, if other engineers want to use another key for different integer codes, they can. This is allowed by the current standard:

Additional key/values of any type MAY be included and MUST NOT break functionality.

FWIW, these values are not arbitrary and based on a very established standard: Syslog / RFC 5424.

commented

I will add this: I'm guessing the "fight" generally isn't a ton of effort and will require some kind of creation of a one-time switch statement translation which most logging libraries should facilitate.

commented

@kfriedman! It's a real shame that all languages haven't conformed to this standard.
The strings of the codes are more consistent than the numeric values across languages.
That's a shame.

I don't think it's worth bucking a language's convention (bad as the convention is) for our own uniformity. Okay, I'm going to take a stab at making the messaging more conspicuous and including a link to this issue. Sound good to folks?

commented

@kfriedman - yeah but, at least in Ruby the "fight" is overwriting constants in a standard library.
Maybe this is a strawman argument - but I'd be afraid that some other dependency would build it's logic against the numbers in the standard library.

Also - gotta take a break to acknoledge that I'm LOVING the fact that you & @EdwinGuzman took the time to think about this and have such thoughtful answers.

commented

Thanks @nodanaonlyzuul and @EdwinGuzman! I'm very glad we are able to have such a great conversation too! These are the conversations us engineers should be having. 😉

Just to be clear: I'd never advocate overwriting a constant. I might advocate maintaining the standard Ruby-ish value and translating that into an additional levelCode value. I think even the naming of the key in the standard is somewhat intentional (i.e. levelCode is less likely to conflict with an existing key).

But, again, the standard says you MAY want to do this.

commented

This issue is quite old, over a year. Closing, with a tag of archived.