hs.logger set Default log level for new logger instances to INFO instead if Warning - haskell

I'm using hs.logger and the default behaviour is to display only the WARNING Level by default.I would like to set it to DEBUG or INFO when I'm developping locally... I found this function hs.logger.defaultLogLevel on the documentation (http://www.hammerspoon.org/docs/hs.logger.html#defaultLogLevel) but I'm not able to find this function in the Library ! If you think there is a better Library to use in haskell, please say it to me as well :-)

I have no experience with hslogger, but this part from the docs seems relevant:
-- Now we'd like to see everything from BuggyComponent
-- at DEBUG or higher go to syslog and stderr.
-- Also, we'd like to still ignore things less than
-- WARNING in other areas.
--
-- So, we adjust the Logger for MyApp.BuggyComponent.
updateGlobalLogger "MyApp.BuggyComponent"
(setLevel DEBUG)
-- This message will go to syslog and stderr
debugM "MyApp.BuggyComponent" "This buggy component is buggy"

Related

Python logging, get DEBUG message from only my code

You know when you set the root logger in Python to DEBUG, and annoyingly it prints debug messages from whatever libraries you're using (Pytorch, Numpy, Matplotlib, whatever)? And then you have to manually turn them off in-code, only for more debug logs from other libraries that you install later to appear?
What I want is a switch that turns all of my loggers (that I got from logging.getLogger(__name__)) to level DEBUG, but not anything else. I initially thought about having a "root" logger for all of my code, named my_root, say, and defining my own get_logger() that wraps around logging.getLogger() by prepending my_root to the names of all the loggers. But then, my "root" logger my_root is still the child of the real root logger, and I can't switch my_root to DEBUG without also switching the root logger to DEBUG (as far as I understand), which I don't want to do. Is there a (preferably elegant) way to get what I want?
I guess the equivalent question is, can I set a child logger's level lower than its parent logger?

Structlog different ways to log: msg versus info and debug

I see different ways to use Structlog and I was wondering what the exact difference is.
Let's say I want to log something using Structlog, you could for example use:
logger.msg("My log message")
But there are other ways to log, like info, debug (as in the standard Python logging library) which give you the possibility to say something about the importance of a message (which you can filter using loglevel):
logger.info("This is an info message")
logger.debug("This is a debug message")
The question is: what is the advantage of using logger.msg as compared to the other ways to log like info and debug? Why would I choose logger.msg?
msg() is a remnant from the original generic BoundLogger that tried to have both stdlib and Twisted log methods (msg() hailing from the Twisted end).
If you use structlog's internal filtering system via structlog.make_filtering_bound_logger(), it's equivalent to the info log level.
You can safely ignore it.

Rsyslog replace newline to <br/> in message part

I am using rsyslog to relay events from a machine to Loggly (cloud log management). I have an application running on that machine that logs to the local rsyslog by using the SyslogAppender of log4net. However, since some of the events are multi-line, thus contain new lines which are then replaced by the escape sequence #012. However, I would like to replace the newlines in the message part to <br/>. I have looked at rsyslogs property replacing [1] feature but I am not really sure if this is the right way. Furthermore, changing the implementation of the application would require some effort so I would like to avoid this way. So I am looking for a way to solve this issue "outside" of my application.
Thanks in advance for any help or suggestions!
[1] http://www.rsyslog.com/doc/property_replacer.html
It seems that the #12s is getting produced by log4net - not by syslog. If you don't want to change the application, you can use sed to replace the #12 by <br/>:
sed 's/#12/\n/g' logfile

Making my module's printk's print to my own logfile

I'm doing some Linux module programming. I typically printk little error messages and stuff for debugging - I then exit out of my module and use "dmesg" to see what's up.
That method of debugging is no longer sufficient. I would like to pipe my "printk" text into my own logfile - preferably local, but I understand if that's impossible and I need to put it somewhere like var/log/*.log.
I've looked into editing syslog.conf - but I'm not sure what to do there. I want just my module's printk's in its own files. Is there a simple way to do this that my Google-fu cannot catch?
You'll need to start every printk's with the module's unique token:
printk("MyModule: ....", ....);
Use syslog-ng (for example) match rule to catch all the module's output
Use `tail -f /var/log/messages | grep MyModule to see the live kernel's output

Log level in tests for PlayFramwork 1.x

When I launch my tests in localhost:9000/#tests# in console I can see long-long log with DEBUG log-level. I want to get rid of that. I tried to put to my application.conf
line like:
application.log=INFO
or even this line:
application.log.system.out=off
But it does not work. Maybe I should put log4j setting specially for test context somehow..?
You can simply prefix those two rules with the "test" id.
%test.application.log.system=off
%test.application.log=ERROR
And by the way log levels are : trace -> debug -> info -> warn -> error -> fatal
So when displaying info, you are displaying a lot of information.
What's your log4j.properties configuration? Most likely you have Debug enabled in there.
If you have this setting enabled:
application.log.path=/log4j.properties
try to disable it and run the tests to verify this is changing the logs. If that's the issue then modify that line to:
%test.application.log.path=/log4j-test.properties
%dev.application.log.path=/log4j-dev.properties
and create the 2 versions of log4j.properties, so you have the right logging level in each.

Resources