add http.request.synthetic attribute to server spans and metrics
#1523
Conversation
Co-authored-by: Trask Stalnaker <[email protected]>
Co-authored-by: Trask Stalnaker <[email protected]>
| brief: > | ||
| A flag indicating that the user agent represents a synthetic source and did not originate from genuine client traffic. | ||
| note: > | ||
| This flag can primarily be determined by the contents of the `user_agent.original` attribute. Instrumentations should determine what they consider synthetic or bot traffic, |
There was a problem hiding this comment.
It there any prior art we can refer to? E.g. a well-known database of crawlers/bots?
There was a problem hiding this comment.
There are a number sites that maintain lists of the most popular. So far, the best I've found is Data Dome's list of those most popular in 2024 https://datadome.co/bot-management-protection/crawlers-list/.
Co-authored-by: Liudmila Molkova <[email protected]>
Co-authored-by: Liudmila Molkova <[email protected]>
…ksonWeber/semantic-conventions into jacksonweber-sythetic-source
| @@ -35,3 +35,20 @@ groups: | |||
| using a user-agent for non-browser products, such as microservices with multiple names/versions inside the | |||
| `user_agent.original`, the most significant version SHOULD be selected. In such a scenario it should align | |||
| with `user_agent.name` | |||
| - id: user_agent.synthetic.type | |||
There was a problem hiding this comment.
Asked this in chat, but also asking here.
Should this (also) be added to client spans so synthetic agents can self-identify in a trace?
There was a problem hiding this comment.
Makes sense to me to allow agents to self-identify and allow for propagation of user_agent.synthetic.type to any server spans created in response to the remote client span from the synthetic agent.
There was a problem hiding this comment.
these sound like two different (though potentially both useful) things:
allow agents to self-identify
and
allow for propagation of
user_agent.synthetic.typeto any server spans created in response to the remote client span from the synthetic agent
I'd suggest sticking to just the first in this PR
Fixes #1127
Changes
Adds the
http.request.syntheticattribute to server spans and metrics to track if telemetry is generated from a synthetic testing source, some kind of bot, or a real user. This will help users filter out telemetry generated by these kinds of synthetic sources that they may not want to consider.Note: if the PR is touching an area that is not listed in the existing areas, or the area does not have sufficient domain experts coverage, the PR might be tagged as experts needed and move slowly until experts are identified.
Merge requirement checklist
[chore]