Closed stefnestor closed 3 weeks ago
Pinging @elastic/es-distributed (Team:Distributed)
We (the @elastic/es-distributed-coordination team) discussed this today. It is of course technically feasible to copy whatever headers one might want into the task context but each one carries some overhead (both computational and conceptual) so we'd want to draw the line somewhere. Given this thinking, our general feeling was that this niche is already filled with the X-Opaque-Id
(and X-elastic-product-origin
) fields, as well as the integration with APM. Together, these existing fields already carry details about the requesting application in most cases, typically way more detail than just the user-agent header. In cases where they aren't sufficient, we'd rather treat that as a deficiency in the calling application instead of adding workarounds in Elasticsearch itself. Thus we decided to close this without taking action.
Description
👋 howdy, team!
Our Elastic Cloud logs
user_agent
which has been a helpful heuristic in determining inducing upstream traffic. According to google, this user agent is a HTTP header, which makes it sound eligible to be passed into the List Tasks emittedheader
.This would help close the gap especially for on-prem services to determine traffic instigators, but it would also be helpful in Cloud to enable customer self-service on tracing traffic to its upstream requestor to reduce related Support investigation times.
Building off today's example to Logstash for similar data ballpark logstash#16448, this would appear
TIA! 🙏