question

菜津美 田. avatar image
菜津美 田. asked ·

Response time degradation problem did not occur as we expected

Hi!

We experienced over 10 seconds response time of a certain service on Feb 8th but Dynatrace did not detect it.

We could not find red zone on this graph.

There is no problem on this service detail page.

I confirmed the following 2 points but I am not sure why Response time degradation problem did not occur as we expected.

  1. I referred this document and found the description "Applications and services have to run for at least 20% of a week before slowdown and error rate alerts are raised"

    https://www.dynatrace.com/support/help/monitor/pro...

    However, I calculated the run ration and the result is over 20 %.
  2. I referred Settings > Anomaly detection > Services and found an option "To avoid over-alerting do not alert for low load services with less than 10 requests/min."
    However, I calculate the average value of requests to this service during 7 days before Feb 8th, then the result is over 10 requests/min.

Please see the result of calculation theresultofcalculation.xlsx

Do you think what I confirmed is beside the point?

Could you please let me know the other point I should confirm in order to enable Dynatrace to detect response degradation of this service?

Best Regards,

Natsumi Tanaka

dashboarddynatrace saasservices
10 |2000000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 50.0 MiB each and 250.0 MiB total.

Wolfgang B. avatar image
Wolfgang B. answered ·

The running time has to be more than 20% of 7 days and you need at least around 10 requests per minute load. If you would like to have a strict alert for low load infrequent running services you can set a static threshold. See help topic here:

https://www.dynatrace.com/support/help/monitor/problems/problem-detection/how-are-new-problems-evaluated-and-raised/

1 comment Share
10 |2000000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 50.0 MiB each and 250.0 MiB total.

Hi Wolfgang,

Thank you for your comment,

I will read the document you mentioned.

0 Likes 0 · ·
菜津美 田. avatar image
菜津美 田. answered ·

Hi Franz,

Thank you for your reply!

The document says 20% of a week, so I calculated the requests from Feb 1 to Feb 7.

Please see this graph.

This graph also shows the run time is higher than 20%.


feb-1-feb-7.png (31.6 KiB)
Share
10 |2000000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 50.0 MiB each and 250.0 MiB total.

Franz S. avatar image
Franz S. answered ·

Hi Natsumi,

you mentioned the point of "Applications and services have to run for at least 20% of a week before slowdown and error rate alerts are raised" and said that you calculated the runtime to be higher than that.

This service seems to have had it's first request at 9am though and the increase in response time started at 11am. That's only 2 hours and therefore less than 20% of a week. Am I missing something here?

best regards
Franz

Share
10 |2000000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 50.0 MiB each and 250.0 MiB total.

Space Topics

mobile monitoring dotnet synthetic monitoring reports iis chat kubernetes servicenow amazon web services mysql mainframe rest api errors cassandra dashboard oneagent sdk cmc application monitoring openkit smartscape request attributes monitoring developer community user tagging log monitoring services ufo syntheticadvisory activegate ip addresses auto-detection high five award oracle hyperion webserver uem usql iib test automation license web performance monitoring ios news migration management zones index ibm mq web services custom event alerts notifications sso host monitoring knowledge sharing reports browser monitors java hybris sap vmware maintenance window user action naming javascript appmon ai synthetic classic availability tipstricks automation extensions session replay diagnostic tools permissions davis assistant faq documentation problem detection http monitors server easytravel apdex aws-quickstart network docker tags and metadata cloud foundry google cloud platform synthetic monitoring process groups account usability dynatrace saas gui paas openshift key user actions administration user actions postgresql synthetic locations oneagent security Dynatrace Managed user management custom python technologies mongodb openstack user session monitoring continuous delivery citrix configuration alerting NGINX action naming linux nam installation masking error reporting database mission control jmeter recorder apache mobileapp RUM php threshold azure purepath davis scripting agent aix nodejs android