ApplicationInsights-Java icon indicating copy to clipboard operation
ApplicationInsights-Java copied to clipboard

Operation name empty in exception table for scheduled operations.

Open Sachin1O1 opened this issue 3 years ago • 6 comments

Expected behavior

It will be very useful if we have relevant data related to the scheduled operation in the operation_name column in the exception table. As these exceptions don't have any end-to-end traction detail so it makes sense to have some data in the operation name instead of keeping it empty.

Actual behavior

NO data in operation_name in exception table.

To Reproduce

When Scheduled operation through an exception.

Sample Application

If applicable, provide a sample application which reproduces the issue.

System information

Please provide the following information:

  • SDK Version: 3.4.7
  • OS type and version: Linux
  • Application Server type and version (if applicable):
  • Using spring-boot? yes
  • Additional relevant libraries (with version, if applicable):

Logs

Turn on SDK logs and attach/paste them to the issue. If using an application server, also attach any relevant server logs.

Be sure to remove any private information from the logs before posting!

Screenshots

If applicable, add screenshots to help explain your problem.

Sachin1O1 avatar Feb 03 '23 12:02 Sachin1O1

hi @Sachin1O1!

I tested this out with:

  @Scheduled(fixedRate = 1000)
  public void fixedRateScheduler() {
    throw new RuntimeException("test");
  }

For each job execution, this captured:

  • Request telemetry "A" for the scheduled job execution
  • Exception telemetry "B" which is parented to "A" and does have operation_name
  • Exception telemetry "C" which has custom dimension "SourceType=Logger" and is not parented to "A" and does not have operation_name

The reason for this is that "C" is logged by Spring Framework after the scheduled job has run, and so there's no "current span/request" anymore when it is logged, and so there's nothing to correlate it with.

I think we need a (hopefully easy, even better automatic) way to suppress this "duplicate" (and uncorrelated) exception somehow, need to think on this a bit still...

trask avatar Feb 07 '23 23:02 trask

@Sachin1O1 does the exception telemetry "C" above have LoggerName org.springframework.scheduling.support.TaskUtils$LoggingErrorHandler?

would it work for you to update your logger configuration to set the level for this particular logger to OFF?

trask avatar Feb 09 '23 19:02 trask

Hi @trask ,

I checked and it's not the above logger you mentioned. Most of the logger name contains our own defined logger that we use for logging.

I also forgot to tell you that we use our homemade schedular. we are not shifting to spring schedular as it's a monolith project and can be a big change.

Sachin1O1 avatar Feb 10 '23 09:02 Sachin1O1

I also forgot to tell you that we use our homemade schedular. we are not shifting to spring schedular as it's a monolith project and can be a big change.

can you describe a bit more where the span(s) and exception(s) are coming from in your case similar to my example above for spring scheduling?

trask avatar Feb 10 '23 16:02 trask

Hi @trask,

I am not able to share much from the code but the schedulars that we are using are too old and the root of the exception is the run method of the schedular class. for example

at com.xx.xx.xx.xxScheduler.run(xxScheduler.java:750)

Sachin1O1 avatar Feb 16 '23 12:02 Sachin1O1

@trask any update here?

Sachin1O1 avatar Apr 27 '23 11:04 Sachin1O1