I have a java server application running that uses Logback as its primary logging library. Recently I asked a developer to remove the extra console logging they had added for a non-development environment and when they asked me why realized I didn't have solid reasoning for it.
The extra logging I believe would cause more I/O operations but does it also add more memory usage? How large is the buffer that it's writing to in stdout and when is that cleared?
Our standard logging is to a file which we can view or also have it piped into monitoring tools. The application is deployed via an automated process and is headless so generally no one is on the VM looking at things.
Example logging appenders (Dropwizard configurations)
logging:
level: INFO
appenders:
- type: file
currentLogFilename: /var/log/myapplication.log
archive: true
archivedFileCount: 5
- type: console
target: stdout
Essentially, is there a detriment to logging to the console when not using it and what does that take the form of?
Unless you are logging millions of records, logging has no noticeable impact on performance.
Logging to the console is more ephemeral than logging to a file--the log messages are not saved anywhere. This makes it impossible to track down errors and troubleshoot problems, especially in production.
Logging to STDOUT can be useful if you run your application inside a container like Docker. Docker can fetch anything written to STDOUT and STDERR in any container it runs using docker logs or can redirect to a different server. If the application would write to a logfile local to the container it runs it, it would be much more difficult to access this file from outside the container.
Related
It is about java project logging, currently log4j1 is used and logging is stored in Tomcat log files under C Drive.
I'm plannig to use graylog2 (gelf.jar) from now onward. I have started and achieved to write my logs to docker host. But whole logs is writen both docker host and tomcat log files. What is my question is that I want to write logs to docker host which is under 2mb and I want to keep logging my logs under the tomcat files which is bigger than 2 mb.
Is it possible, how is it possible, can anyone give me help?
in log4j.xml, I used appender logger tags to seperate them from each other, I used additivity=false function, in java log class I tried to seperate them from each other
I'm used to using log4j and whenever there were setup/config problems I'd enable "-Dlog4j.debug" and all the config info would be dumped out at startup.
This was very useful on a number of occasions.
Now I'm working on a Spring boot application, which I've found uses:
Commons logging Logger statements in the client code
A bridge jar (jcl-over-slf4j-xxx.jar) which translates the commons logging calls into slf4j more info here
Finally slf4j uses "logback" as the underlying logging framework
I found it rather painful to figure all this out.
Is there an equivalent of -Dlog4j.debug which can show me how this is all hanging together at startup time?
This is the best/only option I've found so far, and it's logback specific.
Use this -D on the command line:
-Dlogback.statusListenerClass=ch.qos.logback.core.status.OnConsoleStatusListener
Taken from here
This essentially is the logback equivalent of log4j's -Dlog4j.debug.
It dumps the logback startup sequence to the console at startup time, as the logging system is initialised.
This is not a true answer as I'd like some messages to show before this to show why logback is being used, but I haven't found anything like that yet.
Aside: This may also be useful for Spring Boot:
-Ddebug
Taken from here and here
If you are using logback, I assume you are using the logback.xml file? Then if you start that file with <configuration debug="true"> then it should dump the status information. More information in the documentation under status data section.
I use HSQLDB on OSGI framework. And it is common solution to use pax-logging that support many logging frameworks (java logging, slf4j, jboss logging etc).
I don't have problems with pax-logging, however, I have problems with HSQLDB logging messages. HSQLDB logging component is very tricky - some messages go to pax-logging system, some go to console.
Could anyone explain what messages where must go and why.
There are separate logging components in HSQLDB.
The Server uses separate writers for log and error messages. The logs default to stdout and stderr but you can set each one to use a custom PrintWriter.
The optional SQL log is always a file. It can be turned on and off live for checking the SQL statements being executed.
The optional event log is a file or an external logging framework. The latter is used when the database is in-process in an application. In both configurations, it reports general persistence events at different levels of detail selected by the user.
Using JBoss EAP 6.4 (AS 7.x I guess).
By default, JBoss' logging service is capturing all application output to stdout (and presumably stderr) and wrapping it in its own log4j-based logs. When running locally I want to totally disable this (annoying) feature1, but the references I've found on the Interwebs all either don't work or are for older versions of JBoss. I've tried excluding every possible logging framework in the jboss-deployment-structure configuration, passing -Dorg.jboss.logging.per-deployment=false as a system property, but still JBoss captures stdout.
How can I disable it in this version of JBoss?
[1] If you must know the reason, it's because we have detailed logging configuration via logback and when running locally in an IDE want to be able to see and control that log output in the console without JBoss' logging service getting in the way.
It's hard-coded in the entry points to capture stdout and stderr. This is done so both streams are written to the defined log handlers. Because of this there is no real clean way around it. However there are ways to make it at least look a little better.
You can create a new console-handler and define a stdout logger to ensure only the simple message is written though.
Here are some CLI commands to configure a logger named stdout to just print the message it receives.
/subsystem=logging/pattern-formatter=plain-formatter:add(pattern="%s")
/subsystem=logging/console-handler=plain-console:add(autoflush=true, target=System.out, named-formatter=plain-formatter)
/subsystem=logging/logger=stdout:add(use-parent-handlers=false, handlers=[plain-console])
Note: It could be my test logback.xml configuration, but I had to use a pattern of %s%n for the plain-formatter.
The only other option I can think of would be to write your own logback ConsoleAppender that creates an output stream based on java.io.FileOutputStream.out rather than using System.out.
I am using zookeeper successfully. It keeps printing status updates and warnings to the shell, which is actually making it harder to debug my program (which is not working as well as zookeeper). Is there an easy way to turn that off in zookeeper without going into the source? Or is there a way to run a java program so that only the executing program gets to print to the shell?
Isn't 'logging' chapter of Zookeeper administrator's guide what you actually want?
ZooKeeper uses log4j so it is pretty standard logging approach with lot of configuration flexibility available.
By default zookeeper emits INFO or higher severity level messages and it uses log4j for logging. So define logging level to a higher severity in your log4j.properties (assuming you provided the path to the .properties or it's in the working directory)
there is a similar post on avoiding ZooKeeper log messages - like this:
zoo_set_log_stream(fopen("NULL", "w"));
This will turn of all output from ZooKeeper