I cannot control logging levels for my code in Websphere Liberty Profile server.
I have configured the server.xml on the server not to log hibernate and spring, since my logs will get flooded with activity from those two frameworks. I commonly do this using log4j and it works fine in standalone WAS.
<logging consoleLogLevel="INFO" copySystemStreams="true" traceFormat="ENHANCED" traceSpecification="org.springframework.*=off:com.ibm.ws.*=off:org.hibernate*=off"/>
In Liberty this does not work.
I get the following log when liberty updates the configuration (when I save server.xml with the changes):
[INFO ] TRAS0040I: The configured trace state included the following specifications that do not match any loggers currently registered in the server: org.hibernate*=off:org.springframework.*=off
Basically this message applies to any of my code and any third party code (Spring, Hibernate, etc).
However the traceSpecification levels work fine for the IBM classes, and I'm able to specify *=off, which effectively turns off all logging.
Has anyone experienced this?
IBM's documentation for TRAS0040I seems simple enough, but I can't seem to figure out why my loggers are not getting registered with the server.
Liberty doesn't have a rich control on logging. You should understand the difference between "logging" and "tracing". Check description of console.log, messages.log, trace.log files at the beggining of: http://www.ibm.com/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.wlp.doc/ae/rwlp_logging.html
Your configuration in "traceSpecification" - actually will do nothing, as spring and hibernate are logs from JVM and they doesn't go to trace, so trace configuration doesn't affect them.
All you can configure in liberty for jvm logs is consoleLogLevel (INFO, AUDIT, WARNING, ERROR, and OFF)
If you want to configure log levels for specific components in Liberty - you should use for example log4j with own configuration
Related
I hope you can solve this very mysterious puzzle!
After migrating to Java8 and Tomcat8, the logging info on the servers is ok, but there is no logging information on the developer laptops. Adding Spring-boot-starter-log4j2 there is logging info on the laptops but NOT on the servers. How come? How to fix?
In the parent.pom both the dependencies slf4j-api, the slf4j-log4j binding and the 'slf4j : jcl-over-slf4j' are used. In the project there are no log4j.properites files. In all places where spring boot is used, the spring-boot-starter-logging is excluded.
Scenario 1:
On laptops - the SLF4J combination produces NO logging. I guess that is because there are no log4j.properties files. On the servers this combination shows logging. How can this be? Can there be a provided Tomcat configuration that allows this logging?
Scenario 2:
When I add the spring-boot-starter-log4j2, then I get logging on my laptop. On the server there is no logging at all.
You can define general logging settings in your tomcat environment. This is for example shown in this article.
In short: (1) add an extra library and (2) add a default log4j.properties file.
I am building an application (Spring Boot 1.4.2) where i would like to offer an administrator the option to enable syslog but i want to avoid him/her having to manually edit any config files - in this case logstash-spring.xml.
Therefore i am trying to understand how i can achieve using a logback-spring.xml file as a baseline (e.g. define file based log options, levels etc. - settings i dont want the administrator to change) and on top of that provide a functionality at runtime where an administrator can add or change a syslog appender.
I have listed what i see as requirements:
The changes made to the Logger should be persisted after the Spring Boot application is restarted.
Ideally the syslog server info (name, port) are kept in my persistence layer (H2, hibernate) but i am not sure if that is possible as i guess the logging framework is being injected prior to my persistence layer?
The syslog appender that i want to add should be referenced by root logger so that all the packages i have configured logging for would go to syslog (not sure if this is just "how it works per default")
Also i dont know if i could simply treat logback-spring.xml as a regular XML object and use for example JAXB to manipulate that file and use the autoscan feature of Logback to simply read in the new changes?
I have played around with defining a Logger #Bean:
#Bean
public Logger logger() {
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
// excluded implementation
}
This is being picked up by Spring Boot but that brings me to the 2 items i have listed above that i dont know how or where i would store the syslog server information the administrator would provide.
UPDATE:
I wrote the following which meets the 3 requirements above however i would appreciate any feedback on the actual implementation as i am very new to Spring and Java.
GitHub repository with implementation - spring-boot-logback-syslog
I managed to use the example i posted in my Github repo in my designated application and with that i am answering my own questions based on the implementation in that repo.
Please refer to the README for full details on how it was implemented.
UPDATE: As part of Spring Boot 1.5.1 there is an actuator that can set the logging level during runtime: Production Ready Loggers
Not necessarily 100% related to this topic but this was one of the requirements i had for the implementation as well as changing syslog related settings.
I have a problem about logging in SystemOut.log with Websphere. Can someone help me?
I’m getting some unwanted warning written in the SystemOut.log file with Websphere Application Server (WAS). All of the warnings are being generated by OGNL (ognl.NoSuchPropertyException). These exceptions don’t affect the code flow. Hence I need to turn off the logging of these warnings.
Also I have configuration in log4j.properties file to control the filtration of the log messages to error.
It would be a great help if anyone can help what configuration I should do in WAS to avoid logging these warnings.
Regards
You can change the log level from WAS admin console. Servers->WAS->servername->troubleshooting->change log details level
Follow the path and you will see options to filter warning. For example to filer message from com.ibm.ws.*=WARN will filter all but WARN.
Hope this helps.
First, you have to determine what running component, inside your WAS instance, is generating these warning messages. Is it WebSphere itself, logging these warnings internally? or is it your code?
If the source is WebSphere, then perhaps, before setting the logging level to "error" or "severe", you may want to open a PMR with IBM. I never encountered OGNL warnings generated by WebSphere itself. These warnings, then, can be indicative of a problem in your WebSphere installation.
If the source is your application, then the way to cope with this situation depends on how OGNL, internally, is generating these messages:
If OGNL is simply writing log lines to System.out, then there's nothing you can do to suppress these lines.
If OGNL is logging through Log4J, then you should be able to set the log level of the OGNL logger(s) through your log4j.properties. If your log4j.properties changes aren't reflected, then it means that you have a classloading problem of some sort (the log4j.properties file being loaded by a different classloader than the one used to load your web application).
If OGNL is using a different logging framework (such as SLF4J or Commons Logging), then you'll have to read through the documentation of these frameworks to learn how to tune the logging level.
the glassfish application server provides a nice monitoring REST interface.
To use it u can enable several monitorable items in the admin console, for example the EJB container. The documentation says, you can retreive EJB-statistics for every deployed application.
If you request a URL like localhost:4848/monitoring/domain1/server/applications/APPNAME/EJBNAME you will get statistics for a given EJB of the application.
Further, there is a possibility to look more deeply into each bean-method of the ejb, for example the executiontime, about which the documentation says:
"Time, in milliseconds, spent executing the method for the last successful/unsuccessful attempt to run the operation. This is collected for stateless and stateful session beans and entity beans if monitoring is enabled on the EJB container."
The problem now is, monitoring is enabled on the EJB-container (Level set to HIGH), but nothing is sampled in any bean-method in any EJB in any deployed application.
Is there something special to do in the bean and/or the glassfish ?
Thanks in advance for help,
Chris
EDIT:
Ok, I noticed something more about that behaviour:
In the server log you get a log message for each deployed EJB like that:
INFO: EJB5181:Portable JNDI names for EJB DataFetcher // ...
If I set the ejb-container monitoring level to HIGH (which is what I want to do), I get the following warning for each deployed EJB, regardless which app I deploy:
WARNING: MNTG0201:Flashlight listener registration failed for listener class : com.sun.ejb.monitoring.stats.StatelessSessionBeanStatsProvider , will retry later
I googled the warning but none of the resulst really help me enabling EJB monitoring...
This seems to be a Bug in Glassfish.
EJB Monitoring is currently not working in 3.1.2.
JIRA issue is already raised: http://java.net/jira/browse/GLASSFISH-19677
There is nothing "special" to do.
http://docs.oracle.com/cd/E18930_01/html/821-2431/abeea.html
For me it seems as if you probably enabled the monitoring option on the wrong configuration. Please double check.
To get rid of this message you can disable the monitoring on ejb container option below in the image
From Monitor Data--->Configure monitoring--->make ejb container log off
I'm confused as to how the errors are logged without me implicitly catching them and logging out the error. All that I've done is put a log4j.xml file in my project defining appenders and now the logs catch and log everything from the frameworks.
If I say, try to query in Hibernate and the query fails, or I try to open a file that doesn't exist, or I get a null pointer exception, if the log4j.xml file defines a log file, and the error level is set correctly, then the error will be captured there?
How does my spring web app capture errors that I didn't catch and log? Is this a result of apache commons logging?
Or is this some magic that log4j knows how to deal with - catch stream to the console etc?
Any info appreciated.
From spring official documentation:
The nice thing about commons-logging is that you don't need anything else to make your application work. It has a runtime discovery algorithm that looks for other logging frameworks in well known places on the classpath and uses one that it thinks is appropriate (or you can tell it which one if you need to). If nothing else is available you get pretty nice looking logs just from the JDK (java.util.logging or JUL for short). You should find that your Spring application works and logs happily to the console out of the box in most situations, and that's important.
To make Log4j work with the default JCL dependency (commons-logging)
all you need to do is put Log4j on the classpath, and provide it with
a configuration file (log4j.properties or log4j.xml in the root of the
classpath).
Take a look for a complete explanation: http://static.springsource.org/spring/docs/3.0.x/reference/overview.html#d0e743