Customer created few KUAs and ask to create SLO on each one of them.
So we wanted to create a metric for counting KUA invocations with visually complete faster then the median and another metric for the total invocations of this KUA, in order to divide the first with the second.
But there is no way to create a metric for visually complete for key user action, only action duration is available.
Then we thought on setting the APDEX for each KUA manually but we have found that there is no APDEX metric for KUA only for application....
So question here is: Is there a way to create SLO on Key User Action visually complete times?
Thanks in advance
Solved! Go to Solution.
Yep that was our first step to get the total number of call to this KUA, but for the next step on how to count the fast invocations (i.e. faster then 90 percentile) we did not find a way to do that .... 😞
Hi @Yosi_Neuman ,
not sure if that helps, but in the Application itself you can create calculated metrics. you can select visually complete there and specify a limit/filter on time which would only count the ones above a certain time (your SLO target).
Then also create one that counts all key action invocations regardless of the VC time and use both metrics in the SLO to determine how many were above and below (effectively calculating the SLO target). That's how I do it.
We tried that too, but the issue with this one is that the only filter here is action duration and there is no visually complete filter 😞
So we are back in square one
I don't think that's possible at the moment as the metric is calculated on the flight and you don't have percentiles in it.
You can do the query for good user actions using USQL, but then you won't be able to use SLO.
It seems that for monitoring user-oriented objectives USQL is a more flexible way to go, albeit not usable for real-time monitoring and SLO input.
Eventually we will use here APDEX metric for KUA
It's not perfect but it's better than nothing 🙂
Late reply, sorry... This is essentially what I did, except that I multiplied the metric by 100 because it's an SLO (range 0-100%) based on an Apdex, not a pure Apdex (range 0-1), and I included only real users:
(100)*(builtin:apps.web.action.apdex:filter(and(eq("User type","Real users"))):splitBy())
Obviously, the Target/Warning percentages also get multiplied by 100 (in effect), meaning 80 and 90, rather than 0.8 and 0.9.