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
Related
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.
Not able to run mongodb instance in ERROR log level. As defined by mongodb documentation, by default verbosity is 0 which includes information messages. But increasing verbosity to 1-5 will include debug level messages. I need only error messages to be logged in my log file. I am currently using mongodb-3.6.3 version with java driver at client side.
Is there any way to do it? If yes, how to achieve this? I've already tried reducing logs by adding quiet = true in the config file. But still, a lot of unnecessary logs are generated.
Add this line to your application.properties file and check the console output after running any MongoRepository query.
logging.level.org.springframework.data.mongodb.core.MongoTemplate=ERROR
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 have a web application, which uses log4j and slf4j as facade for logging. Logging is configured not from log4j.properties file, but from Java code.
Application is running on three different machines using Websphere Application Server.
Issue is that on two instances logging works as expected. But on the third one nothing is written in my logfile. Output goes to SystemErr.log instead (there are messages of ERROR and INFO levels).
Initially I thought that something is with Websphere server configuration, but later I found this link http://www.webagesolutions.com/knowledgebase/waskb/waskb004/ which says that such situation can be when log4j.properties can not be read.
But I am not using property file for this. And configuration form Java works OK on other two instances.
Any ideas what can be the issue?
Thank you in advance!
Please make sure that no alternative slf4j binding (such as simple) exists on the CLASSPATH.
I just read the gwt-log Getting Started guide and found it very helpful, however I have a few questions surrounding the Loggers:
The SystemLogger sends output to System.err and System.out - in the context of a client-side web app running inside a browser, where will this output eventually go? Browser logs?
Does RemoteLogger depend on JUL or log4j? I have a homegrown slf4j binding that I like to use for all my Java backends, and would like to use it, but not sure if RemoteLogger will be incompatible with it?
Is it possible to have RemoteLogger hit my own LoggingServiceServlet, which could then translate the log messages coming in on the HttpServletRequest into logging statements that are compatible with my custom slf4j binding? If so, what might this config look like?
Thanks in advance!
In this link, you have a most updated documentation about the GWT logging framework
Answers to your questions:
#1 Yes it works in client side, but only when running the app in DevMode (not in production nor superdev mode). Look for the log lines in the DevMode window, or in your terminal output if you run dev-mode from the command-line.
#2 It depends on java.util.logging, you can change it though (see #3)
#3 Yes you can change the logging framework extending the RemoteLoggingServiceImpl and overriding the logOnServer(LogRecord lr) method.