I now actually have 2 separate customer environments where I've run into this: several processes are making connections towards http://www.terracotta.org/kit/reflector, which are then visible under requests executed in background threads. As there's no outbound connectivity to terracotta.org, the GET goes to timeout and is regarded as a failed request. When I'm sorting all the services based on failure rate, this of course messes that up when I have dozens of "Requests executed in background threads of XYZ" services with 100 % failure rate.
As a first step I tried to edit the Deep Monitoring settings:
Exclude specific incoming web request URLs
Exclude unimportant or 'noisy' incoming web requests from monitoring and alerting.
...But I couldn't get it to work; I tried several rules, but they had no effect. I suppose the magic word there is "incoming" requests - these are of course originating from the server side. Any suggestions how I could fully just exclude terracotta.org from the monitoring data? One (bad) idea is that I could manually edit the error detection settings for each and every service (there are more than 200) and classify java.net.SocketTimeoutException as an exception to be ignored. Then of course if I get "real" issues with that exception, they would also be ignored. So it's maybe not the preferred way to do it. Does anyone have any good ideas?
Solved! Go to Solution.
Hello @Kalle L.
I faced the same issue. The URL is part of the background thread, therefore, deep monitoring is not going to work in this situation. Also, you may notice that the background service has only the URL you mentioned.
We had some discussion in the below RFE thread for the option to exclude the service.