-
Notifications
You must be signed in to change notification settings - Fork 117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
To change AWS_XRAY_TRACING_NAME logic #371
Comments
Hey @nikolaianohyn thanks for raising this issue! Unfortunately I don't believe this is something the team wants to add, we already mention clearly in the documentation that environment variables take precedence over anything else:
So it would be a big change to alter that behavior. Hopefully you have enough solutions to make it work for your needs? Otherwise please describe your use case more in depth and we'll try to help you with it 🙂 |
@NathanielRN In my opinion values from code must be in priority compared to environments. I already have service name in trace. I don't want segments with the same name. It looks useless. You use it for GRPC interceptor, but instead of MethodName I got serviceName twice. |
Hey @nikolaianohyn, thanks for explaining further. I brought this up with the team and we can see that it is consistent across other SDKs. This is probably because 1 segment == 1 service usually. So the use of the name for the service in the trace would make sense. Are you able to make a |
@NathanielRN I see the problems in the logic and code. In GRPC interceptor you call NewSegmentFromHeader with MethodName argument. So I expect to see in UI this MethodName. Instead of this I can't understand which grpc method was called. I see only service, but my service has a lot of endpoints. |
According the code bellow I can't redefine name of trace if I set up AWS_XRAY_TRACING_NAME env. I think we should add in this condition:
&& name == ""
The text was updated successfully, but these errors were encountered: