You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The X-Amzn-Trace-Id header that Amazon adds to ELB only gives time since epoch in seconds as opposed to milliseconds. This isn't a very accurate measurement, and seems to impact apps negatively (reporting times incorrectly, which seems to be a lot more pronounced since their recent change to hex decimal timestamps)
Whether Amazon is truncating the time or rounding the time to the second may need to be investigated, but either way unless queuetime is above a second this measurement doesn't add much value
The text was updated successfully, but these errors were encountered:
Good morning Jack. It looks like the header for the request is only going to have seconds. I could imagine them changing it to be a hexadecimal value to do milliseconds in the future, but I can't find any roadmap that would indicate as such. I agree that the appropriate measure is to remove this.
The header's time value is in seconds which isn't enough precision
for us to provide quality data to users. With seconds precision, the
queue time hovers about 0.5s due to the truncation.
It may be possible to pull the millisecond precision data from the
AWS logs themselves and avoid the python agent altogether.
Closesscoutapp#631
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-request-tracing.html
The X-Amzn-Trace-Id header that Amazon adds to ELB only gives time since epoch in seconds as opposed to milliseconds. This isn't a very accurate measurement, and seems to impact apps negatively (reporting times incorrectly, which seems to be a lot more pronounced since their recent change to hex decimal timestamps)
Whether Amazon is truncating the time or rounding the time to the second may need to be investigated, but either way unless queuetime is above a second this measurement doesn't add much value
The text was updated successfully, but these errors were encountered: