@ChadTurnerI have had to take some interesting approaches but nothing conclusive that can be tracked all the way through to the target system easily. I think i have solved Scenario #1 in my original post. But #2 is elusive.
Non-Dynatrace Approach
Use a standalone environment or request headers. Log in as a user, filter and dump the logs. Check manually how many times certain apis are called during this rime frame and interaction type.
Dynatrace
Use request headers? In my scenario each inbound call immediately talked to an auth service which included the users ID GUID in the URI I use the rule to tag the "calling service" and a Preprocess rule to remove the rest of the url. I can then filter on calls by a USER during a time frame. If you don't happen to be lucky like me (no code approach) you will need to implement some type of user or session # header and pass that in from the FE -> BE calls then try this approach.
This works fine to see the "front end" accidentally making duplicate calls to the backend service, but not the backend services making duplicate calls to the next layer down, as these headers are not propagated past the interface on the backend. For the backend to integration layer I'm still relying on log analysis.
I think I would need some type of user or session value that can be propagated to the target layer (integration) so that Dynatrace can filter upon it. But again this is my thinking on a request header approach. There may be other ways.
In my head if Dynatrace could take a request header and force apply it to each request in the stack regardless of it being present in the inbound outbound request flow. this would also work.
Featured Posts
