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

Approach to identifying Duplicate calls

Just wanting to know if anyone has a smart approach to identifying duplicate calls using Dynatrace.


Some scenarios I would like to figure out:

1.  Customer logs into a website and Web front end make two duplicate calls to the same endpoint i.e /info

2. The backend api for /info makes two duplicate calls to a integration layer say /getAccount


How would one approach this to see where duplicate calls are being made at each layer?


We have w3c trace and homemade correlation ID's but these are endpoint to destination not a user did action (login) and this is the amount of traffic the action placed on the integration layer.


Would be useful to catch issues with more/less load being placed on something over time that could be attributed to duplicate api calls.



DynaMight Legend
DynaMight Legend

@benjamin_mullan were you able to get a method to target the duplicate calls? If so can you share it with the community? 


@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.


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