Hi Barry,
You nearly saved the day :)
-for routing statistics from encapsulated assertion ensure you have checked the
"Update routing statistics in parent policy" box
Yes!! Shame on me I didn't see this option :)
- you don't need to use message-received policy to capture request start time and set as a shared variable that is available at message-completed as ${request.time.millis}
Correct. We now even use "${request.elapsedTime}", which saves us from computing $now-$then.
- using global policies will add a small amount of latency
In fact problem was on my side. Fixed the latency differences.
I now get for the 2 methods:
New one:
2020-04-23T19:13:14.492+0200 INFO 6582 com.l7tech.server.policy.assertion.ServerAuditDetailAssertion: -4: Metrics: {"time":1587661994,"sourcetype":"_json","index":"gateway_metrics","event":{"dc":"EMEA","env":"ref","loc":"lan","time":"1587661994440","formattedTime":"2020-04-23T19:13:14.440+02:00","nodeId":"111eb41796514904bb6f4babee150006","nodeName":"apiref-eu-int","nodeIp":"168.124.44.206","serviceId":"e325178b4619c90fb22f99a4af2e65b3","serviceName":"Test-routing-to-external-HELLO","serviceUri":"/helloext","remoteIp":"7.28.74.97","httpMethod":"GET","routingCode":"200","responseStatus":"200","psecFailCode":"","requestSize":"0","responseSize":"560","elapsedTime":"52","totalBackendLatency":"26","isPolicySuccessful":true,"isPolicyAuthorized":true,"isPolicyViolation":false,"isRoutingFailure":false}}
Policy Backed Metrics:
2020-04-23T19:13:14.495+0200 INFO 125698 com.l7tech.server.policy.assertion.ServerAuditDetailAssertion: -4: Metrics int: {"time":1587661994,"sourcetype":"_json","index":"gateway_metrics","event":{"dc":"EMEA","env":"ref","loc":"lan","time":1587661994440,"formattedTime":"2020-04-23T19:13:14.440+02:00","nodeId":"111eb41796514904bb6f4babee150006","nodeName":"apiref-eu-int","nodeIp":"168.124.44.206","serviceId":"e325178b4619c90fb22f99a4af2e65b3","serviceName":"Test-routing-to-external-HELLO","serviceUri":"/helloext","totalFrontendLatency":53,"totalBackendLatency":28,"isPolicySuccessful":true,"isPolicyViolation":false,"isRoutingFailure":false}}
This does the trick.
-message completed processing occurs before sending response to client so the processing in this fragment will add latency to your request frontend.
Is there a way to get actual time it took for the request to *read* from client
And after processing, if not possible on "message-completed", how to get time it took to *send* response back to client.
Overall what we need is *total* time for the request:
- time to read payload from client
- time to process (we have: elapsedTime-totalBackendLatency)
- time to send and receive response from backend (we have: totalBackendLatency)
- time to send back response to client
Many thanks for your help.
And last one:
Whenever we send data to Splunk (task sched every one minute), Route to HTTPS adds in log:
2020-04-24T00:28:00.027+0200 WARNING 217 com.l7tech.common.http.prov.apache.IdentityBindingHttpConnectionManager: Attempt to bind with no id set
Any idea ?