-
Notifications
You must be signed in to change notification settings - Fork 31
Consider using localEndpoint
instead of peer.*
tags
#55
Comments
Hi, thanks for opening this issue as well. The current (after #52) implementation might already be doing some part of what you suggest. But I need your help filling up the gaps. First, there's Assuming #57 is also merged, the each HTTP request proxied generates the following spans:
Of these, the behavior of
For reference, here's how the
Comments / questions:
But perhaps I am not understanding the roles of localEndpoint and remoteEndpoint correctly. |
The local
This is correct
Are these operations that involve a remote node? I guess yes, hence it is correct.
I am not entirely sure about this (where did you read it?). what is true is that zipkin displays the service names in uppercase now:
Yes please. That should be part of all spans.
In sum, if |
Fixes #55 In all the Spans generated by kong: * The localEndpoint is now `{ serviceName = "kong" }` * The remoteEndpoint has changed like so: * If a Kong Service was found when proxying, * If that service has a name then remoteEndpoint will have `{ serviceName = "<service.name>"}`. * Otherwise remoteEndpoint = `{ serviceName = "<service.id>" }` where id is a uuid. In addition to the serviceName, the remoteEndpoint can have `ipv4/ipv6` and `port` attributes. These have remained unchanged from before: * On the request (root) span, ipv4/v6 and port are the consumer's forwarded ip and port * On each balancer try span, ipv4/v6 and port are what the balancer attempted * On the proxy span, ipv4/v6 and port are first successful combination the balancer attempted
In https://zipkin.io/zipkin-api/,
|
Hi, I have given this a try in #63. Here's the "before and after" traces: https://gist.github.com/kikito/4cca7fb37498fb65830a4f1b8ba2236c I've got some concerns:
|
Hi @kikito, this is great stuff.
It is not because now you can search spans based on that serviceName.
Usually we don't pass zero values,
If kong is calling service A on behalf of an upstream service then that span should keep the Does that make sense? |
Fixes #55 In all the Spans generated by kong: * The localEndpoint is now `{ serviceName = "kong" }` * The remoteEndpoint has changed like so: * If a Kong Service was found when proxying, * If that service has a name then remoteEndpoint will have `{ serviceName = "<service.name>"}`. * Otherwise remoteEndpoint = `{ serviceName = "<service.id>" }` where id is a uuid. In addition to the serviceName, the remoteEndpoint can have `ipv4/ipv6` and `port` attributes. These have remained unchanged from before: * On the request (root) span, ipv4/v6 and port are the consumer's forwarded ip and port * On each balancer try span, ipv4/v6 and port are what the balancer attempted * On the proxy span, ipv4/v6 and port are first successful combination the balancer attempted
Done!
Understood. I have moved the consumer ip/port to the tags section (updaded description on the PR). All the |
Fixes #55 In all the Spans generated by kong: * The localEndpoint is now `{ serviceName = "kong" }` * The remoteEndpoint has changed like so: * If a Kong Service was found when proxying, * If that service has a name then remoteEndpoint will have `{ serviceName = "<service.name>" }`. In addition to the serviceName, the remoteEndpoint can have `ipv4/ipv6` and `port` attributes. These have remained unchanged from before: * On the request (root) span, ipv4/v6 and port are the consumer's forwarded ip and port * On each balancer try span, ipv4/v6 and port are what the balancer attempted * On the proxy span, ipv4/v6 and port are first successful combination the balancer attempted
Fixes #55 In all the Spans generated by kong: * The `localEndpoint` is `{ serviceName = "kong" }` in all spans. The `remoteEndpoint` has changed as follows: * On the request (root) span, it remains as before: * `remoteEndpoint.ipv4/v6` and `remoteEndpoint.port` point to the consumer's forwarded ip and port * On each balancer attempt span: * If a Kong Service was found when proxying, and that Service has a `name`, then `remoteEndpoint.serviceName` will be the Service Name. * `remoteEndpoint.ipv4/v6` and `remoteEndpoint.port` will point to the ip+port combination used on the span * On the proxy span: * If a Kong Service was found when proxying, and that Service has a `name`, then `remoteEndpoint.serviceName` will be the Service Name. * `remoteEndpoint.ipv4/v6` and `remoteEndpoint.port` will point to the first successful combination of balancer attempts.
Fixes #55 In all the Spans generated by kong: * The `localEndpoint` is `{ serviceName = "kong" }` in all spans. The `remoteEndpoint` has changed as follows: * On the request (root) span, it remains as before: * `remoteEndpoint.ipv4/v6` and `remoteEndpoint.port` point to the consumer's forwarded ip and port * On each balancer attempt span: * If a Kong Service was found when proxying, and that Service has a `name`, then `remoteEndpoint.serviceName` will be the Service Name. * `remoteEndpoint.ipv4/v6` and `remoteEndpoint.port` will point to the ip+port combination used on the span * On the proxy span: * If a Kong Service was found when proxying, and that Service has a `name`, then `remoteEndpoint.serviceName` will be the Service Name. * `remoteEndpoint.ipv4/v6` and `remoteEndpoint.port` will point to the first successful combination of balancer attempts.
peer.service
,peer.ipv4
,peer.ipv6
andpeer.port
are opentracing tags whereas zipkin uses thelocalEndpoint
attribute:This certainly is the case for #39 and #53
The text was updated successfully, but these errors were encountered: