I have the following simple code
AmazonEC2 ec2 = AmazonEC2ClientBuilder.standard().withRegion(Regions.US_EAST_1).build();
DescribeInstancesRequest request = new DescribeInstancesRequest();
DescribeInstancesResult response = ec2.describeInstances(request);
While running this code I see the multiline debug output. I show only the beginning below. How to remove this output?
14:03:29.877 [main] DEBUG com.amazonaws.AmazonWebServiceClient - Internal logging successfully configured to commons logger: true
14:03:38.129 [main] DEBUG com.amazonaws.metrics.AwsSdkMetrics - Admin mbean registered under com.amazonaws.management:type=AwsSdkMetrics
14:03:38.480 [main] DEBUG com.amazonaws.auth.AWSCredentialsProviderChain - Unable to load credentials from EnvironmentVariableCredentialsProvider: Unable to load AWS credentials from environment variables (AWS_ACCESS_KEY_ID (or AWS_ACCESS_KEY) and AWS_SECRET_KEY (or AWS_SECRET_ACCESS_KEY))
14:03:38.482 [main] DEBUG com.amazonaws.auth.AWSCredentialsProviderChain - Unable to load credentials from SystemPropertiesCredentialsProvider: Unable to load AWS credentials from Java system properties (aws.accessKeyId and aws.secretKey)
14:03:38.580 [main] DEBUG com.amazonaws.auth.AWSCredentialsProviderChain - Loading credentials from com.amazonaws.auth.profile.ProfileCredentialsProvider#7fb9f71f
14:03:38.786 [main] DEBUG com.amazonaws.request - Sending Request: POST https://ec2.us-east-1.amazonaws.com / Parameters: ({"Action":["DescribeInstances"],"Version":["2016-11-15"]}Headers: (User-Agent: aws-sdk-java/1.11.135 Mac_OS_X/10.12.6 Java_HotSpot(TM)_64-Bit_Server_VM/25.144-b01/1.8.0_144, amz-sdk-invocation-id: 0a1303b3-16c0-b140-8d9b-b2e22dc685b1, )
14:03:40.160 [main] DEBUG com.amazonaws.auth.AWS4Signer - AWS4 Canonical Request: '"POST /
amz-sdk-invocation-id:0a1303b3-16c0-b140-8d9b-b2e22dc685b1
amz-sdk-retry:0/0/500
host:ec2.us-east-1.amazonaws.com
user-agent:aws-sdk-java/1.11.135 Mac_OS_X/10.12.6 Java_HotSpot(TM)_64-Bit_Server_VM/25.144-b01/1.8.0_144
x-amz-date:20171113T190338Z
Log4j Assumption
Under the assumption your application's logging system is configured via a property file like log4j.properties present at the base of your Java classpath, you can reduce verbosity of the loggers by including the line
log4j.logger.com.amazonaws=WARN
WARN or ERROR will guarantee you get the least amount of logs for the loggers inside the AWS SDK.
Should you wish to keep a more granular level of logging for a specific component of the AWS SDK, you can always override the level on a restricted scope (i.e. a subpackage of the com.amazonaws), e.g.
log4j.logger.com.amazonaws.request=INFO
Logging frameworks supported by AWS Java SDK
The AWS SDK documentation states "Supported logging systems include the Java Logging Framework and Apache Log4j, among others".
I refer you to Logging AWS SDK for Java Calls for further reference.
Checking which logging framework is used by the test
The Apache Commons logging library referenced from Gradle is an abstraction layer on top of logging libraries which provide actual implementations of loggers. It is not, in itself, the logging implementation used by your test. In the statement you provided, you are using the Java logging framework ( java.util.Logger a.k.a JUL). But is it really the logging implementation your test uses?
A quick check you could do to verify if log4j is on your test's classpath is to add the VM argument -Dlog4j.debug=true and launch your test. If log4j is on your classpath you will see some output from the library printed on the console.
You could also check the runtime classpath of your test, because there may be transitive dependencies (as opposed to direct) to logging libraries, which may not be visible from the list of compile-time dependencies.
One last resort possibility could be to put a breakpoint there and debug to see which logger is used from the SDK itself (this code is called in your test because it is shown in the logs you provided).
I have been using spring boot and use aws client to get some secrets before bootstrap spring boot environment, but all secrets go to debug messages then I tried a lot of methods but this is the one works for me:
LoggerContext loggerContext = (LoggerContext)
LoggerFactory.getILoggerFactory();
loggerContext.getLogger("org.apache.http").setLevel(Level.INFO);
loggerContext.getLogger("com.amazonaws").setLevel(Level.INFO);
Related
I am using Couchbase SDK along with Spring boot 2.6.x version. I am using the spring spring-data-couchbase:jar:4.4.0 which in turn has com.couchbase.client:java-client:jar:3.3.0 dependency. The issue, is when trying to execute cluster.query() methods, I need to see what query is getting executed. I need to enable debug logs. However, I have tried configuring it under properties for logging.level for the package com.couchbase.client to DEBUG level, nothing is showing up. I tried the similar config in log4j.xml as well and no luck either. Does couchbase uses any wierd property or is it not reading the properties specified from either log4j or spring's properties?
You may ask if raw query is passed then why log specifically, but this is required if using parameterised queries and to debug it.
How does one enable logging for couchbase if using plain sdk methods under spring's context ?
Can you enable couchbase specific properties of spring-data and not package within the application?
logging:
level:
org.springframework.data.couchbase.repository.query: DEBUG
This should help ! It won't require any external dependency or logging solutions
For the cluster, add ServiceType.QUERY to captureTraffic...
env.ioConfig(it -> it.captureTraffic(ServiceType.QUERY))
and also set the log level for the com.couchbase category to TRACE
We are using cas-client-core-3.3.3.jar for providing single sign on functionality in our application and we are trying to emit this jar library logs into our appliation logs.
Our application is a weblogic based application and we are using log4j for logging.
So to get cas-client-core-3.3.3.jar logs in our application log we have added this property in our log4j.properties
log4j.logger.org.jasig.cas=DEBUG
but we are not getting the logs which are expected from org.jasig.cas classes. I am attaching sample log here which is expected
2015-05-13 10:00:17,798 DEBUG [org.jasig.cas.client.validation.Saml11TicketValidator.<constructValidationUrl>] - Placing URL parameters in map.
2015-05-13 10:00:17,801 DEBUG [org.jasig.cas.client.validation.Saml11TicketValidator.<constructValidationUrl>] - Calling template URL attribute map.
2015-05-13 10:00:17,802 DEBUG [org.jasig.cas.client.validation.Saml11TicketValidator.<constructValidationUrl>] - Loading custom parameters from configuration.
2015-05-13 10:00:17,803 DEBUG [org.jasig.cas.client.validation.Saml11TicketValidator.<validate>] - Constructing validation url:
Disclaimer: I've never worked with Web Sphere but worked a lot with different logging systems, so my answer is based on my experience in this area.
First off, cas uses slf4j under the hood which is great.
Slf4j is only an interface (slf4j-api jar), and if you want to use it with log4j which is a concrete implementation of logging system that knows nothing about slf4j apis you should provide an implementation of sfl4j interfaces that will delegate the calls to log4j loggers.
So you should also include such an adapter in classpath as well Here is the link.
Now if this doesn't work, then probably the log4j.properties are not configured correctly, for example, the logger doesn't have any associated appenders/wrong appenders.
I've found the best way to check this is just to place a breakpoint on the logger's call (inside cas library) and see the following:
Which implementation of slf4j interface is actually used (as I've said before org.sl4j.Logger is just an interface and it has to be instantiated with real implementation object somehow, you know)
See the associated appenders to the underlying implementation.
Regarding the second item, depending on technology/frameworks you have, you might be able to get this information via JMX or some kind of web admin interface. Debugging is a "hardcore" general way to figure this out.
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 am using Jetty http client in my application. I am also using SLF4J with LogBack.
How to set Jetty's overall logging level to INFO?
I have followed the instructions on Jetty's documentation to provide jetty-logging.properties file with contents like this:
# Configure Jetty for SLf4j Logging
org.eclipse.jetty.util.log.class=org.eclipse.jetty.util.log.Slf4jLog
# Overall Logging Level is INFO
org.eclipse.jetty.LEVEL=INFO
Jetty is logging fine via SLF4J, but the LEVEL setting doesn't seem to work.
When I set the level from Logback configuration then it works, but I want my code to be logged in DEBUG level and Jetty in INFO level.
Jetty is very noisy in DEBUG level.
Any help is appreciated!
You need to set the Properties....
// change Jetty Logger
Properties p = new Properties();
p.setProperty("org.eclipse.jetty.LEVEL", "OFF");
org.eclipse.jetty.util.log.StdErrLog.setProperties(p);
I wasn't able to make Jetty to log at custom level. Because if Jetty finds SLF4J in my application then it will start using it with the logging level I have specified in logback.xml configuration file.
So I made a little hack. I specified Jetty to use Java Utils Logging and set level to INFO.
// Setting Jetty logger implementation and level (DEBUG | INFO | WARN | IGNORE)
System.setProperty("org.eclipse.jetty.util.log.class",
"org.eclipse.jetty.util.log.JavaUtilLog");
System.setProperty("org.eclipse.jetty.util.log.class.LEVEL", "INFO");
And for redirecting Java Utils Logging messages to SLF4J I used jul-to-slf4j-1.7.12.jar
That's how I got it working. If there is a better way I sure want to know.
I've looked through the entirety of the Spark documentation, but don't see anything at all about logging. I know that Spark uses an embedded version of the Jetty web server, but it seems like there may not be a way to enable Jetty logging without actually going in and changing Spark framework code.
I was hoping to have all HTTP requests to the server logged in the Common Log Format. Right now, when I start the server, I see this followed by silence no matter how many requests I throw at it:
[Thread-1] INFO spark.webserver.SparkServer - == Spark has ignited ...
[Thread-1] INFO spark.webserver.SparkServer - >> Listening on 0.0.0.0:4567
[Thread-1] INFO org.eclipse.jetty.server.Server - jetty-9.0.2.v20130417
[Thread-1] INFO org.eclipse.jetty.server.ServerConnector - Started ServerConnector#46f24fce{HTTP/1.1}{0.0.0.0:4567}
My best idea at the moment is to roll my own logging system in a before filter. For example:
before((req, res) -> {
System.out.println("Request from " + req.ip() + " received - " + req.userAgent());
});
But it seems that this functionality should be built-in to this framework, and I'm just not seeing it. I figure that a relatively popular web framework (with over 3,000 stars on Github) would have logging built-in for its web server, right?
I have no idea what spark is, but If Jetty isn't too old there, you should be able to provide a slf4j binding (and possibly logging implementation if not using Simple one) such as Simple SLF4J. (See http://www.slf4j.org/manual.html)
If you use Simple SLF4J binding you can configure it (including log level or logging file) through JVM system properties as documented in Javadoc: http://www.slf4j.org/api/org/slf4j/impl/SimpleLogger.html
Old question but for all coming around here: Just define a logger in you application class like this:
private static final Logger LOG = LoggerFactory.getLogger(YourCurrent.class);
now you are able to log your own messages with spark logging adapter.
LOG.error("missing whatever");