Errors are not displaying in the Errors view

Elastic Observability APM
1

I have connected my Java application to Kibana and it is working correctly. My app runs in tomcat, if that matters. However, when I trigger an exception in the Java code, it is not showing in the Kibana "Errors" section. What are the requirements to make this work?

I tried searching for help first, but you have to imagine that searching for something like "Kibana show errors" is not going to give me what I'm looking for.

Thanks for any help!

2

I have connected my Java application to Kibana

I'm assuming that by "connected" you mean you've configured the Java APM agent in your application code?

If so, you may not be using one of the supported technologies that come with exception tracing out of the box. You may need to integrate directly with the agent's Public API in order to make sure that any exception handlers in your application are sending the exceptions to the agent. This integration is typically quite easy!

3

Thank you for the reply!

Yes, I configured my app to use the Java APM agent.

My technology stack should be supported according to that link. It is a Java 8 Jersey application running on Tomcat 8.5.

The only thing is, we are using AdoptOpenJDK rather than the versions listed. Since Kibana seems to properly be monitoring JVM level stuff, I feel like that is fine, though.

So there is nothing I should need to do to monitor my Tomcat logs?

4

I moved this over to the APM category to see if someone more knowledgeable over there has more specific advice.

I would recommend double checking that you don't have any data in the .apm-error* indices already. That will help narrow down the problem on whether or not this is a Kibana issue or a problem with the APM agent. You may also want to try configuring the agent's logging to verify whether or not it is receiving exception events.

5

Hi @Noah_Troncoso,

Can you elaborate a bit on the type of exceptions / errors that you need to monitor ?

  1. exception thrown during request lifecycle that might result in a 500 status response (or similar)
  2. exceptions thrown by calling a third-party library that we instrument (for example making an HTTP request to another service, or calling a database with JDBC).
  3. exceptions thrown somewhere else in the application

Our agent captures 1) and 2), and those should be reported respectively as transaction errors and span errors (and both should be available in the Errors view in kibana).

In some cases, exceptions are caught by an intermediate layer, like a Servlet filter, in that case even if they are written to Tomcat standard output (and thus visible in the catalina.out log file, they aren't visible by APM agent because application already "took care of them".

6

Thank you Sylvain, I believe that clears things up a bit. The errors I'm mentioning are what we consider "unhandled exceptions" but we are doing processing on them and wrapping them during the request lifecycle, so I guess that'd cause a problem with the agent logging these.

I also have since found out that we are not reporting these unhandled exceptions with a 500 status code. I couldn't tell you why, but all our requests are returning a 200, even if the payload includes an exception. That's probably part of the problem as well.

Would I be right in saying that if we reported a 500 for these unhandled exceptions that the APM agent would pick it up?

For other exceptions I'm guessing I would have to use the Public API as recommended by @joshdover?

7

Reporting those with 500 error status won't make the agent pick them up, also it would not be ideal to change your application behavior for that purpose.

Also, agent is not able to detect that those exceptions are written to the response payload, it just detects them when an uncaught exception is thrown while a transaction or span is active.

As a side note, once you are able to capture and report those exceptions, it might be a good idea to remove them from the response payload as any error will expose your application stack trace, thus it's implementation, which could be a security risk if your service is publicly available.

I confirm that using agent API will allow you to report those exceptions, you should use the captureException(...) method to attach exceptions to the current transaction, here is the link in the documentation..

8

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.