Error detection

[IgnacioAyerra]

The services being analyzed by dynatrace throw http 500 errors when a fetch returns with 0 results (no client with xxx id, for example). Now, this clearly isnt a server error but the devs of the plataform can't change how those requests http status codes are returned. How can I make it so that Dynatrace doesn't recognize them as errors?? Only though the Failure detection parameters? Can they be made more specific so that real 500 codes are not skipped??

[deni]

Hi @IgnacioAyerra ,

Check Settings -> Server-side service monitoring -> Failure detection parameters and Failure detection rules

This is the link to the documentation: https://docs.dynatrace.com/docs/observe/applications-and-microservices/services/service-detection-v1...

[IgnacioAyerra]

Hi @deni I've been using the Failure detection parameters but with no success. The Services are supposedly called Services:150**,154**(/T******/v1.0) ("*" are not "*", just cant be to cautious with privacy), but I dont know if this is how Dyna "sees" it or if it's just how ti shows it to me. Is there a different way to see the service names? Any idea why the failure detection parameters mught not be working?

[deni]

Hi @IgnacioAyerra ,

It looks like Dynatrace can’t detect a specific technology (such as Spring, PHP, etc.), so instead it falls back to naming the service as “Service + port number”. In such cases, your failure detection rule may not work as expected, because the rule depends on how the service is identified. If you’re trying to filter out certain 500 responses (which I understand is the goal), the mismatch in service naming could be the reason it isn’t applied.

Could you share a bit more info about the setup? For example:

• Do you have deep monitoring enabled, or only basic process monitoring?

• What’s the underlying technology (Java, .NET, PHP, Node.js, …)?

• What do you see in the Properties tab of the service?

That information can help decide the best way to configure failure detection. Sometimes it’s better to use service naming rules to give these services more meaningful and stable names.

Here’s an example from a demo environment: the service name initially looks “strange,” but when we check its properties, we can clearly see what it really represents.

[Julius_Loman]

@IgnacioAyerra, failure detection parameter as @deni mentions, is the solution here. Most likely, in your case, there is an exception along with the HTTP 500. If this is your case, then you need to add this exception in the failure detection as a success-forcing exception. Then the request will be marked as successful regardless of the HTTP status code. 

Please provide more screenshots and also details of failures (use the details of failures option when analyzing requests).