Request Attribute in Dynatrace definitely makes life easier when configure something analogous to Business Transaction in AppMon.
However, as of right now I can see there is still some limitation, so thought I better look at it right now in case any future customer asked about it. This would sharpen my understanding, and also useful for all of us in the future.
I've drafted a hypothetical situation below, and think of a few typical use-cases of it, with its feasibility in the bracket.
Any comment, insight, or correction are warmly welcomed 🙂 Also, if you can think of any other use-case, please do let me know!
Say, I have 4 req attr which corresponds to Race, Gender, Age Group, Product Price
AS OF RIGHT NOW:
1. Chart the resp-time, or fail-rate, or thro'put of page/s where any of these req attr are present. (Able to)
2. Chart the resp-time, or fail-rate, or thro'put of page/s where any specific splitting of these req attr are present. Say for example, instead of response-time for overall 'age group', I want to chart 'age group=18-25' (Able to)
3. Know the min/max price of product purchased by certain race and gender. (Able to. But requires manual inspection of the value of 'product price' attribute by scrolling up&down, after apply the filter of 'race=malaysian chinese' and 'gender=male')
4. Know the count of male/female of certain age group (Able to. But requires manual inspection of the throughput of 'gender' attribute by scrolling up&down, after apply the filter of 'age group=26-35')
5. Know the sum/average of product prices sold (Not able. The sum/average option when we configure request attribute is only the summation/average of various value within a single purepath, but if I want the summation/average of all splitting, that is not possible in Dynatrace.)
TLDR of all the use-cases: As far as capturing and splitting, Dynatrace makes life easier compare with AppMon; But as number manipulation goes, Dynatrace still has to catching up.
Solved! Go to Solution.