cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

problem analysis - problem duration and fast xxx mins anaysis

hiroshi_aoki
Dynatrace Organizer
Dynatrace Organizer

Can someone explain definition of problem start-end (duration) and "first time" for business impact analysis.

Why analyze for 54 mins for an issue opened for 39 mins?
Why only analyze for first 34 mins for an issue opened for 49 mins?

9 REPLIES 9

wolfgang_beer
Dynatrace Leader
Dynatrace Leader

We do analyse several minutes before the actual problem start timestamp, as in case of errors and session drops we would also like to catch those that began in front of the problem. The problem itself then is the ultimate peak but real users surely experienced the incident earlier than an event is open. Then we limit the max business impact analysis time as a problem can be open for days and we dont want to keep collecting the data for such long periods.

But you are right the times here are a bit confusing, I will talk with the dev team to consolidate those limits so that the exact analysis times can be better explained.

Best greetings and Merry Christmas,

Wolfgang

@Wolfgang B.

After reading your answer, I wondered it was analyzing the impact on users from that time if the same thing happened before the problem happened (even if it wasn't Problem time). However, looking at various Problems, it seems that is not the case. Is there a concrete calculation to determine the time frame to check the impact on the user?

Also, is there any progress on the following answers?

> I will talk with the dev team to consolidate those limits so that the exact analysis times can be better explained.

Best Regards,

Yuki Ito

Hello @Wolfgang B.

I'm on the same team as Yuki Ito.

The customer is still waiting for the answer to the above question.
Did you get any new information from the dev team?

Thank you very much for your time.

Best regards,
Kohei Otsuka

wolfgang_beer
Dynatrace Leader
Dynatrace Leader

Hi,

Sorry for the late reply I just saw that another message was posted on the thread. Yes I did define a dev story to consistently limit the analyse timeframe to:

- Either the problem timeframe from start to end (in case the problem duration is shorter than 30min)

- Or limit the analysis timeframe to a max of 30 min from problem start, in case a problem is open for a longer period of time.

That change should make it much simpler to understand the analysis timeframe.

Expect that change to come into the product around Q2 this year.

Best greetings,

Wolfgang

kohtsuka
Visitor

HI @wolfgang_beer 

I know this is a bit of an old thread, but I was told that the fix regarding timeframes would be done in Q2.
Has this been accomplished?

BestRegards,

Kohei Otsuka

Yes there was a lot of change in the business impact analysis section in the last months. We did change some wording, adapted the drill downs to be more precise and we also adapted the timeframe so that it is better explainable. 

yito
Newcomer

Hello, @wolfgang_beer 

I received your comment and I had checked the business impact analysis section. Yes, the time frame difference problem was solved, but I noticed new problem.
That is Impacted users on business impact analysis section.
Could you check following image?

yito_0-1632969791841.png

The number on the first page was "10", but when I moved the page it became "1".
I think the number must be match for analyzing easier. Dynatrace's user may be confuse for not matching them.

 

Additionally, if clicking "Affected service calls" has also issue. Could you check following image, please?

yito_1-1632969821705.png

 

Even though only clicked "Affected service calls", time frame is not match first page and second page.
As I mentioned earlier, Dynatrace's user may be confuse for not matching them.

 

Yuki Ito

yito
Newcomer

If I should suggest these opinions as an RFE, please let me know.

Yuki Ito

wolfgang_beer
Dynatrace Leader
Dynatrace Leader

We can solve the issue with the mismatch with service flow drilldown, but I fear the first issue with the number of user sessions we can't change. Reason for that mismatch is that the problem collects the user ids from the running user sessions, while the session view does only show the user sessions that are within the selected timeframe. As the problem timeframe is narrow, we will never catch the exact match with problem collected user ids I fear.