logrus
logrus copied to clipboard
sirupsen
Add the ability to override log level values
Not sure who the maintainers are anymore but could this be looked at please?
@dgsb @sirupsen @freeformz @freeformzSFDC
@michael-bud Please describe the use case(s) a little so that we can do our best to understand the problem(s) being solved by this change.
@freeformz We have a number of different technologies across our architecture which when get fed into a centralised logging system. In make it easier to search for things of 'warn' log level across Go, Python, PHP, Java etc. projects we try to standardise the log level values (e.g. all the same case) but this requires some flexibility in the terms used; similarly we use the functionality that already exists in logrus that allows for renaming of certain fields to standardise those too.
This doesn't apply to us but I've also seen places that want to use numbers for their log levels instead of words to allow easy handling of level hierarchy/ordering (e.g. notify if log.level <= 5).
I don't know any of the people who did the +1s on the original PR OP; they may have other use cases too.
@michael-bud Let me re-state this to make sure I understand:
You want to add the ability to customize the output of the log level values in the formatters supported by logrus. Example:
logrus.Info("hello") (with json formatter) => {...., "level": "InFo!!!", ....} (assuming you want Info to come out as InFo!!!).
If so... a) Have you tried doing this with a hook? b) If it's not possible to do with a hook (I'll try in a little)....What do you think of instead of creating a map type and the like, instead take an optional function? Example:
// FormatLevel to a string. If this function is set, the output of it
// will be used as the value output for the logged 'level' field.
// {..., "level": "outputOfFormatLevel",....}
FormatLevel func(Level) string
The advantage of this is that it doesn't tie the implementation to our preconceived implementation. Anyone can implement a function or type with a method that matches that function signature.
It doesn't appear to be possible with a Hook.
It is possible with a custom formatter, but that also doesn't seem great.
(a) Yep, as you've pointed out, it's only really possible by replacing the whole JSON formatter with a custom one (b) The reason I didn't do it as a custom function was to keep consistency with where we're doing this elsewhere in the JSON formatter, specifically where we allow customisation of the field names for things like the message, log level and timestamp.
@michael-bud That makes sense. I requested a few (minor) changes that I'd like to see before merging.
@michael-bud So... After I posted that, and was reading #463, I started to wonder if this is solely a function of the JSONFormatter or not. So now I'm not so sure about my statements above.
For instance Level currently hard defines the string definition used for the stock levels. Maybe that should be more flexible and could help finish off #463. Thoughts ?
@freeformz I'd rather not try and work that into this as I think it will make this significantly more complex than it needs to be and #463 looks like quite a massive change (potentially a whole new API) whereas this is relatively minor. The use cases are also quite different.
+1, i think having the ability to define custom levels is a necessary thing.
Hi, is this ready to be merged? I guess there are just minor fixes left, really looking forward for this feature 👍
Would really love to see this merged, but progress seems to have stalled.
I'm more than happy to pick it up and make the changes necessary to get it merged, if @michael-bud / @freeformz / @dgsb can confirm the current state of things?
