-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected behaviour with transport 'level' option #33
Comments
P.S. While this probably affects the |
Here is an example where |
Yes, I noticed this as well when writing tests for the last change. I feel that the Winston name of I'll propose that the constructor here gets 2 "new" parameters: maxLogLevel: 'fatal' // "level" for winston--it will not log above this level
logdnaDefaultLevel: 'info' // the current "level" param for the logger |
I definitely agree that the WinstonJS |
Ugh, you're right, so confusing. |
I'm wondering if we put "winston" in the name? We don't want people to think that |
Heh, yeah, "naming" is definitely one of the hardest things in computer science 😉. On one hand, would it be bad if people do think |
Similarly, does the |
Well yes, that's a fair point. Lines won't go to LogDNA without first going through that For the default, it feels like the same situation where Winston doesn't use a default. If you're level isn't supported, it throws. I think most developers (including us) would frown on proper names being in var names, so I think that should be avoided. I think we can disambiguate with the |
Re-reading the winston docs, they say this for
So the initial suggestion for the parameter name was correct. Thus, the name will be |
Whoah, that's interesting, and definitely hasn't been my understanding/experience (at least, not that I can remember)... But now that I think about it, this is because of the different ways to view ordering of log levels (numeric vs effect). For example, consider the following log level mapping: // log level: "info"
{
critical: 0,
error: 1,
warn: 2,
info: 3,
debug: 4
} In this case, |
yes, exactly. The numerical (ordinal?) values representing the "levels" is really what matters, so they can be configured in a variety of ways. This will come down to proper documentation to make clear. |
Both Winston and LogDNA have a "level" parameter, but they mean different things. In Winston, it represents a "max" level wherein anything logged above that level's rank will not be logged (and thus sent to LogDNA). To disambiguate this logger transport, the parameter will be called `maxLevel`, and will only apply to Winston. LogDNA's `level` parameter is actually not usable with the implementation of this transport since all logs will be specifying a level value. Fixes: #33
@kendallroth, after diving into the code, it became clear that the LogDNA This effort also exposed a bug wherein, if |
Both Winston and LogDNA have a "level" parameter, but they mean different things. In Winston, it represents a "max" level wherein anything logged above that level's rank will not be logged (and thus sent to LogDNA). To disambiguate this logger transport, the parameter will be called `maxLevel`, and will only apply to Winston. LogDNA's `level` parameter is actually not usable with the implementation of this transport since all logs will be specifying a level value. Fixes: #33
🎉 This issue has been resolved in version 4.0.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
@darinspivey I did not previously "realize" that WinstonJS is actually what is responsible for setting a level for each log entry (makes sense in hindsight though). As long as Good point about the missing |
Yes, I think that'd be the case if |
We recently noticed some unexpected behaviour with the
level
option provided as an option to thelogdna-winston
transport. The current behaviour seems to be that thelevel
provided will be used for two (occasionally conflicting) purposes:This leads to unexpected behaviour in some cases, such as when attempting to send
debug
level logs to LogDNA but wanting the default level to be something likeinfo
(orwarn
to "pop out").In our case, we had the LogDNA transport options set to
debug
originally, which meant that debug logs were being sent to LogDNA but the the default level being used for undefined log levels was alsodebug
. We didn't want this behaviour, so we modified the transport options to useinfo
; however, this caused WinstonJS to no longer senddebug
level logs (since this tranport inherits from Winston transport, which also defines alevel
option).TL;DR: The underlying Winston transport uses the
level
option to define the minimum log level for a transport (docs, but LogDNA uses the samelevel
option to define a default log level if missing/invalid (docs).The text was updated successfully, but these errors were encountered: