I try to send logs from a java application with the Logstash tcp socket appender to logstash. The java app. already works with logback 1.1.9 (slf4j) and other appenders.
Now I added the following lines to the logback-test.xml:
<configuration>
<appender name="logstash" class="net.logstash.logback.appender.LogstashTcpSocketAppender">
<destination>[IP]:5010</destination>
<encoder class="net.logstash.logback.encoder.LogstashEncoder">
<fieldNames>
<message>log_msg</message>
</fieldNames>
</encoder>
<keepAliveDuration>5 minutes</keepAliveDuration>
</appender>
<root>
<level value="info"/>
<appender-ref ref="logstash" />
</root>
</configuration>
But when I add the appender and start my java application, I get an error from the JVM Launcher "A Java Exception has occured" and I get the following console text:
Exception in thread "main" java.lang.IllegalAccessError: failed to access class ch.qos.logback.core.status.OnPrintStreamStatusListenerBase from class net.logstash.logback.status.LevelFilteringStatusListener (ch.qos.logback.core.status.OnPrintStreamStatusListenerBase and net.logstash.logback.status.LevelFilteringStatusListener are in unnamed module of loader 'app')
at net.logstash.logback.status.LevelFilteringStatusListener.setDelegate(LevelFilteringStatusListener.java:67)
at net.logstash.logback.appender.AsyncDisruptorAppender.start(AsyncDisruptorAppender.java:370)
at net.logstash.logback.appender.AbstractLogstashTcpSocketAppender.start(AbstractLogstashTcpSocketAppender.java:1009)
at ch.qos.logback.core.joran.action.AppenderAction.end(AppenderAction.java:90)
at ch.qos.logback.core.joran.spi.Interpreter.callEndAction(Interpreter.java:309)
at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:193)
at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:179)
at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:62)
at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:158)
at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:145)
at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:103)
at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:53)
at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:75)
at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:150)
at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:84)
at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:55)
at org.slf4j.LoggerFactory.bind(LoggerFactory.java:150)
at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:124)
at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:412)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:357)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383)
I included the logstash 6.3 jar-file and because of this error, I also tried it with an older version, 4.9. Does anybody know if that is compatible to logback 1.1.9?
I'm not using Spring-Boot.
---------Edit 17.02.2020-----------
My input of the logstash.conf file (because I don't get any log from my java application):
input {
tcp {
mode => "server"
port => 5010
codec => json
}
}
You can avoid the exception you encountered by applying any of the following solutions:
A) Use logback version >= 1.1.10
OR
B) Add <addDefaultStatusListener>false</addDefaultStatusListener> to your appender definition (see details here)
OR
C) Add a status listener to your logback configuration (which prevents logstash-logback-encoder from adding a default status listener).
The exception occurs because logstash-logback-encoder versions >= 6.0 reference logback's ch.qos.logback.core.status.OnPrintStreamStatusListenerBase class when adding a default status listener. OnPrintStreamStatusListenerBase was made public in logback 1.1.10, and was package-private before then.
Applying any of the above solutions will avoid the exception you encountered. However, keep in mind that logstash-logback-encoder versions >= 4.8 are compiled and tested against logback 1.2.x. Therefore, you might encounter other errors when using logback 1.1.x. The logstash-logback-encoder readme contains the following statement on this topic:
Older versions than the ones specified in the pom file might work, but the versions in the pom file are what testing has been performed against.
Solution:
I updated logback from 1.1.9 to 1.2.3. As I replaced the jar files and addeded them to the class-path, I got over 600 times the following error-message: Logger cannot be resolved to a type. I fixed this by opening the properties in Eclipse from the logback project, going on "Order and Export" and setting a marker in every checkbox --> Apply and close. Now I don't get the IllegalAccessError any more and my java application is running fine. And I also now can see the logs in Logstash and Kibana :)
I downloaded the following files:
jcl-over-slf4j 1.7.25
jul-to-slf4j 1.7.25
log4j-over-slf4j 1.7.25
slf4j-api 1.7.25
logback-classic 1.2.3
logback-core 1.2.3
I downloaded them from here:
https://mvnrepository.com/artifact/ch.qos.logback/logback-classic/1.2.3
Related
I'm trying to do some Logging modification on My Standard AppEngine Java 11 app using a logging.properties file, My app is a Jetty web-server which I run by adding the following entry-point to my app.yaml file
runtime: java11
entrypoint: 'java -cp "*" com.jettymain.Main webapp.war'
Now Google documentation here suggests that in order to use logging.properties. The path to the configuration file must be provided to your application as a system property: -Djava.util.logging.config.file=/path/to/logging.properties
I have tried setting that in the code, first thing in the com.jettymain.Main class which starts the Jetty embedded web-server by doing the following
System.setProperty("java.util.logging.config.file", "WEB-INF/logging.properties")
But that didn't work, modifying the entry-point in app.yaml did make the web-server load those configurations but it was failing to load the Google cloud logging handler class com.google.cloud.logging.LoggingHandler, which I need to write those logs to Google Stackdriver, I have the Google cloud logging dependency added to both my app and the web-server but that didn't help.
<dependency>
<groupId>com.google.cloud</groupId>
<artifactId>google-cloud-logging</artifactId>
<version>3.0.1</version>
</dependency>
modified entry-pint
runtime: java11
entrypoint: 'java -cp "*" com.jettymain.Main webapp.war -Djava.util.logging.config.file=WEB-INF/logging.properties'
logging.properties file, it is the sample file which can be found here plus few extra things
# To use this configuration, add to system properties : -Djava.util.logging.config.file="/path/to/file"
.level = INFO
# it is recommended that io.grpc and sun.net logging level is kept at INFO level,
# as both these packages are used by Cloud internals and can result in verbose / initialization problems.
io.grpc.netty.level=INFO
sun.net.level=INFO
handlers=com.google.cloud.logging.LoggingHandler
# default : java.log
com.google.cloud.logging.LoggingHandler.log=custom_log
# default : INFO
com.google.cloud.logging.LoggingHandler.level=FINE
# default : ERROR
com.google.cloud.logging.LoggingHandler.flushLevel=EMERGENCY
# default : auto-detected, fallback "global"
com.google.cloud.logging.LoggingHandler.resourceType=container
# custom formatter
com.google.cloud.logging.LoggingHandler.formatter=java.util.logging.SimpleFormatter
java.util.logging.SimpleFormatter.format=%3$s: %5$s%6$s
# Level for all logs coming from GWT client (can't filter by specific classes on client)
com.google.gwt.logging.server.RemoteLoggingServiceUtil.level = WARNING
com.beoui.geocell.level=WARNING
It might be an old question, but this answer still might help to someone having same issue.
I've managed to add custom logging.properties using Gradle for Java 11 Standard Environment:
First of all, you have to add dependency to the Cloud logging as it's no longer provided by the environment:
dependencies {
runtimeOnly("com.google.cloud:google-cloud-logging:3.11.3")
// your other dependencies
}
Then you need to specify a folder containing your logging.properties file to be uploaded by Gradle com.google.cloud.tools.appengine plugin:
configure<AppEngineAppYamlExtension> {
stage {
setArtifact("build/libs/server.jar")
// can be some other folder of your choice where logging.properties is located
setExtraFilesDirectories("src/main/resources")
}
deploy {
version = "GCLOUD_CONFIG"
projectId = "GCLOUD_CONFIG"
}
}
Then specify an entrypoint in app.yaml. The trick here is that properties file can be found in /workspace/ directory of the GAE container:
runtime: java11
entrypoint: 'java -jar -Djava.util.logging.config.file=/workspace/logging.properties server.jar'
Deploy application using
./gradlew appengineDeploy
My logging.properties file:
.level = INFO
# it is recommended that io.grpc and sun.net logging level is kept at INFO level,
# as both these packages are used by Cloud internals and can result in verbose / initialization problems.
io.grpc.netty.level=INFO
sun.net.level=INFO
handlers=com.google.cloud.logging.LoggingHandler
com.google.cloud.logging.LoggingHandler.formatter=java.util.logging.SimpleFormatter
java.util.logging.SimpleFormatter.format=%3$s: %5$s%6$s
Get the System.setProperty into any method. It can be the main method also. I think the problem is "the logging.properties must go in WEB-INF/classes directory" as per this link and not WEB-INF/ directory as mentioned in your code.
System.setProperty("java.util.logging.config.file", "WEB-INF/classes/logging.properties")
I am using log4j with very simple setup in an Eclipse plugin project, that I am building right now.
I call BasicConfigurator.configure(); in the main class and then just use log4j in every class like this:
private static final Logger logger= LogManager.getLogger(ClassName.class.getName());
That worked fine for a while but now I have problems with log4j. I am not sure what happened, but it seems the logging level is now Level.WARN. Also the console output is somewhat broken. The logging messages are logged two times each. One time normal, and one time really weird:
!ENTRY org.apache.log4j 2 0 2017-01-10 13:19:58.192
!MESSAGE package.ClassName - This is a logging message
0 [main] WARN package.ClassName - This is a logging message
I do not use a properties or xml file so I cannot imagine what I changed.
EDIT: I checked out an older point of the program and the problem still exists. That should mean it is not a problem of the code itself. Can Eclipse settings or something like that affect the console behavior?
EDIT 2: The idea of unchecking "Limit console output" did not help.
EDIT 3: These are my dependencies:
Require-Bundle: org.eclipse.ui,
org.eclipse.emf.ecore;bundle-version="2.12.0",
org.eclipse.emf.ecore.xmi;bundle-version="2.12.0",
org.eclipse.core.resources;bundle-version="3.11.0",
org.eclipse.core.runtime;bundle-version="3.12.0",
org.eclipse.jdt.core;bundle-version="3.12.1",
org.eclipse.jdt.launching;bundle-version="3.8.100",
org.junit,
org.apache.log4j;bundle-version="1.2.15"
EDIT 4: A clean Eclipse version fixes the output problem. But using the clean version would mean to install again all the plugins and tools. Also I would have to configure my preferences from scratch. Also perhaps that then causes the problem again, so I should rather find the cause of the problem.
Try removing the "trace_file" directive from the my_package logger statement.
Try this one
static {
PatternLayout layout = new PatternLayout();
String conversionPattern = "%d %-5p [%t] %c{2} (%2F:%M(%L)):%m%n";
layout.setConversionPattern(conversionPattern);
ConsoleAppender consoleAppender = new ConsoleAppender();
consoleAppender.setLayout(layout);
consoleAppender.activateOptions();
Logger rootLogger = Logger.getRootLogger();
rootLogger.setLevel(Level.INFO);
rootLogger.addAppender(consoleAppender);
}
I understand that the question can sound a little funny, but how do I disable logging in neo4j-ogm? I have added an logback.xml file to my conf directory which is in my classpath. The logback.xml looks as follows:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<!--
~ Set the required log level for the OGM components here.
~ To just see Cypher statements set the level to "info"
~ For finer-grained diagnostics, set the level to "debug".
-->
<logger name="org.neo4j.ogm" level="OFF" />
<root level="off">
<appender-ref ref="console" />
</root>
</configuration>
which is taken from here . The loglevel=off is taken from here
I want to deploy my program for production and I need logs from console. But with neo4j logging the logfile increases 1GB per day with the following type logs:
14:20:13.281 [Thread-14] DEBUG o.n.o.d.http.request.HttpRequest - Response is OK
14:20:13.289 [Thread-14] DEBUG org.neo4j.ogm.MetaData - looking for concrete class to resolve label: Leaf
14:20:13.289 [Thread-14] DEBUG org.neo4j.ogm.MetaData - concrete class found: com.mycompany.Leaf. comparing with what's already been found previously...
14:20:13.289 [Thread-14] DEBUG org.neo4j.ogm.MetaData - Page resolving class: com.mycompany.Leaf
14:20:13.290 [Thread-14] DEBUG org.neo4j.ogm.MetaData - looking for concrete class to resolve label: Root
etc...
Details:
The program is a jsvc daemon which logs console to log/log.txt.
neo4j-version: 2.0.0 - M01
java -version : oracle java 7
The question was raised years ago, but for all using Stack Overflow as knowledge database, I want to record an additional solution for current environments. Most of the Neo4j log entries concern query statements and the already mentioned "unwind" messages. So, you are using a Spring Boot environment (2.0.3.RELEASE) in conjunction with the spring-boot-starter-data-neo4j artifact? Just add the following line to your /src/main/resources/application.properties file to disable the messages:
Using the Bold driver
logging.level.org.neo4j.ogm.drivers.bolt.request.BoltRequest = WARN
Using the embedded driver
logging.level.org.neo4j.ogm.drivers.embedded.request.EmbeddedRequest = WARN
I don't know if this would help your case but I had exploding "UNWIND" logs issue and found this hacky way to fix it. It just disables an internal logger I found in the source code. You could do something similar if your found the logger class in source code:
java.util.logging.Logger.getLogger("org.neo4j.ogm.drivers.bolt.request.BoltRequest").setLevel(Level.WARNING);
After hours working on it, I finally find the problem!
I was using the wrong dependencies of "slf4j".
Wrong dependency:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
<version>1.6.4</version>
</dependency>
Correct dependency:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.25</version>
</dependency>
And I just use the file "log4j2.xml" to make the correct level of logs.
I hope this can help anyone!
I'm trying to use raven-log4j to send youtrack's exception to the Sentry.
/etc/youtrack/log4j.xml:
<appender name="sentry" class="net.kencochrane.raven.log4j.SentryAppender">
<param name="dsn" value="https://publicKey:secretKey#host:port/1"/>
<filter class="org.apache.log4j.varia.LevelRangeFilter">
<param name="levelMin" value="WARN"/>
</filter>
</appender>
<root>
<priority value="INFO"/>
<appender-ref ref="SYSLOG"/>
<appender-ref ref="sentry"/>
</root>
A part of the original upstart file:
exec java -Xmx{{ heap_size }} -XX:MaxPermSize=250m
-Djava.awt.headless=true -Djetbrains.youtrack.disableBrowser=true -Djava.security.egd=/dev/zrandom -Djetbrains.mps.webr.log4jPath=/etc/youtrack/log4j.xml -jar /usr/local/youtrack/{{ jarfile }} 8082
and I changed it to:
exec java -Xmx1g -XX:MaxPermSize=250m -Djava.awt.headless=true
-Djetbrains.youtrack.disableBrowser=true -Djava.security.egd=/dev/zrandom -Djetbrains.mps.webr.log4jPath=/etc/youtrack/log4j.xml -cp /usr/local/youtrack/youtrack-6.5.16853.jar:/usr/local/youtrack/lib/*
jetbrains.youtrack.standalone.YoutrackStandalone 8082
to specify the classpath (/usr/local/youtrack/lib/*).
Without copying raven-log4j-6.0.0.jar to /usr/local/youtrack/lib, I will get an error like this:
log4j: Class name: [net.kencochrane.raven.log4j.SentryAppender]
log4j:ERROR Could not create an Appender. Reported error follows.
java.lang.ClassNotFoundException: net.kencochrane.raven.log4j.SentryAppender
but after put it into that lib folder, another error appear:
log4j: Class name: [net.kencochrane.raven.log4j.SentryAppender]
log4j:ERROR Could not create an Appender. Reported error follows.
java.lang.ClassCastException: net.kencochrane.raven.log4j.SentryAppender cannot be cast to org.apache.log4j.Appender
Sure, there is no log4j-*.jar in the lib folder:
ls -l /usr/local/youtrack/lib/
total 88
-rw-r--r-- 1 root root 79444 Jan 7 14:13 raven-6.0.0.jar
-rw-r--r-- 1 root root 6798 Jan 7 14:35 raven-log4j-6.0.0.jar
Why and where was it loaded twice?
This was resolved on GitHub
One thing worth noting is that you'll still need to include manually add the additional dependencies of both raven (https://github.com/getsentry/raven-java/tree/master/raven#manual-dependency-management) and raven-log4j (https://github.com/getsentry/raven-java/tree/master/raven-log4j#manual-dependency-management) that are not already included by YouTrack (e.g. Jackson, Guava, etc.) since we don't assemble or shade these dependencies with the raven JARs. I don't that think this would be causing the issue, though.
Also, from what I could tell, log4j was also initialized twice by the application (log line: Init web application log4j location: /tmp/youtrack-example/log4j.xml.) The first invocation would always fail with a ClassCastException, while the second would fail to initialize a Raven instance via the RavenFactory (included below.) Both using the automatically registered factory provided by ServiceLoader and explicitly providing a factory yield the same result.
I'm using Eclipse 3.5, with my Tomcat runtime set as Tomcat 6.0.26. My Java VM is JDK 1.6.17 (Mac OS X).
When I try to run a web application from an Eclipse Java EE perspective I keep seeing this error in the console:
Caused by: java.lang.ClassCircularityError: java/util/logging/LogRecord
at com.adsafe.util.SimpleFormatter.format(SimpleFormatter.java:11)
at java.util.logging.StreamHandler.publish(StreamHandler.java:179)
at java.util.logging.ConsoleHandler.publish(ConsoleHandler.java:88)
at java.util.logging.Logger.log(Logger.java:458)
at java.util.logging.Logger.doLog(Logger.java:480)
at java.util.logging.Logger.logp(Logger.java:596)
at org.apache.juli.logging.DirectJDKLog.log(DirectJDKLog.java:165)
at org.apache.juli.logging.DirectJDKLog.info(DirectJDKLog.java:115)
at org.apache.catalina.core.ApplicationContext.log(ApplicationContext.java:644)
at org.apache.catalina.core.ApplicationContextFacade.log(ApplicationContextFacade.java:251)
at org.apache.catalina.core.StandardWrapper.unavailable(StandardWrapper.java:1327)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1130)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4187)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4496)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:785)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at org.apache.catalina.core.StandardService.start(StandardService.java:519)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:581)
... 6 more
java/util/logging/LogRecord implements Serializable, so I am not sure where the circular reference could have creeped in.
Has anyone seen this before and know how to fix this?
I was able to circumvent this problem by moving the <contextListener ...> to the very end of the configuration file (previously, I had it at the beginning of the file). The error remains really weird, though.
The problem is solved if you insert this snippet into your logback configuration:
<!-- LEVEL CAN NOT BE DEBUG -->
<logger name="org.apache" level="INFO"></logger>
I'm not sure why this resolved the problem, but setting the default level to INFO made this go away for me
.level = INFO
In had the same error when using Logback.
In my case, the problem was I used JUL LevelChangePropagator in my Logback configuration file.
So I just had to remove the following listener
<contextListener class="ch.qos.logback.classic.jul.LevelChangePropagator">
<resetJUL>true</resetJUL>
</contextListener>
First of all, a bit of context: I personally see this message when adding a listener in my web.xml to install the SLF4JBridgeHandler to bridge java.util.logging (JUL) calls to SLF4J. I started to see this as soon as I increased the JUL root logger level from the default (INFO) to FINE, in order to forward all (well, almost all) messages to SLF4J.
user2543253 comment above was indeed useful, it's a problem that happens at classloading time. I personally solved it by adding a fake direct JUL log call (using a LogRecord) before installing the SLF4JBridgeHandler, in order to trigger classloading of JUL classes early. So my listener now does:
java.util.logging.Logger rootLogger = LogManager.getLogManager().getLogger("");
rootLogger.log(new LogRecord(Level.ALL, "bridging of java.uil.logging to SLF4J requested"));
SLF4JBridgeHandler.removeHandlersForRootLogger();
rootLogger.setLevel(Level.FINE);
SLF4JBridgeHandler.install();
By the way: it's not strictly a Logback problem, I experience this while not using Logback at all (I'm using the Log4j 1.2 binding).