23 Dec 2020 03:23 AM
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?
Solved! Go to Solution.
23 Dec 2020 05:48 AM
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
06 Jan 2021 12:23 AM
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
05 Feb 2021 12:24 AM
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
05 Feb 2021 08:07 AM
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
17 Sep 2021 02:58 AM
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
17 Sep 2021 05:41 AM
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.
30 Sep 2021 03:22 AM - edited 30 Sep 2021 03:43 AM
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?
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?
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
30 Sep 2021 03:32 AM
If I should suggest these opinions as an RFE, please let me know.
Yuki Ito
30 Sep 2021 06:29 AM
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.