I'm trying to figure out what I should expect to be instrumented with the Java agent (1.16.0) if I'm using a Spring Boot application that is just for a short-lived (less than a minute to run) batch type of job, and therefore, has no servlet container. It does make JDBC calls (via Hibernate), but I don't see anything logged for any sql that is being run?
It is sending data to the APM server and it's getting into Elastic, since I an entry in there for my context.service.name, but no information seems to be showing up there. I see this at the very end of the application run's logs.
2020-05-13 20:59:23.820 [elastic-apm-init-instrumentation-shutdown-hook] INFO co.elastic.apm.agent.impl.ElasticApmTracer - Tracer switched to STOPPED state
2020-05-13 20:59:23.907 [elastic-apm-init-instrumentation-shutdown-hook] INFO co.elastic.apm.agent.report.ApmServerReporter - dropped events because of full queue: 0
2020-05-13 20:59:24.006 [elastic-apm-init-instrumentation-shutdown-hook] INFO co.elastic.apm.agent.report.IntakeV2ReportingEventHandler - Reported events: 0
2020-05-13 20:59:24.007 [elastic-apm-init-instrumentation-shutdown-hook] INFO co.elastic.apm.agent.report.IntakeV2ReportingEventHandler - Dropped events: 0
2020-05-13 20:59:24.008 [elastic-apm-circuit-breaker] INFO co.elastic.apm.agent.impl.circuitbreaker.CircuitBreaker - Stopping the Circuit Breaker thread.
Also, I have to disable this instrumentation, otherwise I get an error like this at the outset: spring-service-name
INFO co.elastic.apm.agent.bci.bytebuddy.ErrorLoggingListener - org.springframework.web.context.support.GenericWebApplicationContext refers to a missing class
Unless you are using some supported scheduling framework, you will have to start, activate, deactivate and end a transaction yourself that encapsulates the batch processing from start to end using our public API
Don't disable instrumentation unless you see there is a problem. This is an INFO message. If you disabled all instrumentations, no DB data will be captured anyway...
Sorry, I was not clear on the way we schedule - this is scheduled with Kubernetes CronJob, so it's fine not to have any instrumentation around that - I don't expect any.
As far as that error, and I need to confirm - I think it prevented the application from even running. I will confirm, especially since I recently updated from 1.15.0 to 1.16.0.
Am I reading the information at the bottom correctly - that it reported 0 events - does that mean nothing was sent at all?
Ok, I confirmed - at least with 1.16.0, it does continue after logging that INFO message that contains a stack trace.
I updated to not disable any instrumentations (set it to blank), and also set trace_methods to our top-level package, and now I get plenty of events being sent.
I tried to suppress this INFO message by setting this in our logback config:
That did not work, so I suppressed by setting log_level to warn for the agent. That hides this INFO with the stack trace, but also suppresses other INFO messages from the agent, obviously. Is there any way to suppress just this class' INFO messages?
There is currently no way of doing that. I lowered the severity of the stack trace to debug, so it should be only a single info line in future releases. The reason we don't want to lower this line's severity is that it may tell us about the reason of why some classes were not instrumented. Do you get a lot of those?
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
