Skip to content
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

NewEndpoint inserts blank ipv4 address even when provided an ipv6 address #85

Closed
odeke-em opened this issue Oct 29, 2018 · 2 comments · Fixed by #86
Closed

NewEndpoint inserts blank ipv4 address even when provided an ipv6 address #85

odeke-em opened this issue Oct 29, 2018 · 2 comments · Fixed by #86
Assignees

Comments

@odeke-em
Copy link
Contributor

Thank you again for all your work on this repository and for answering my questions.

I just encountered an issue whereby I am intercepting Zipkin spans from arbitrary sources, parsing them using this library and then processing them and then on the exit users can choose to export them back to Zipkin. For this I need to have a verification test that the intercepted spans' serialization matches almost exactly.

However, when I do

endpoint, err := openzipkin.NewEndpoint("foo", "[7::80:807f]:0")

I get back

&model.Endpoint{ServiceName:"frontend", IPv4:net.IP{0x0, 0x0, 0x0, 0x0}, IPv6:net.IP{0x0, 0x7, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x80, 0x80, 0x7f}, Port:0x0}

when then reflects in my roundtrip tests as

[{"timestamp":1472470996199000,"duration":207000,"traceId":"4d1e00c0db9010db86154a4ba6e91385","id":"4d1e00c0db9010db","parentId":"86154a4ba6e91385","name":"get","kind":"CLIENT","localEndpoint":{"serviceName":"frontend","ipv4":"0.0.0.0","ipv6":"7::80:807f"},"remoteEndpoint":{"serviceName":"backend","ipv4":"192.168.99.101","port":9000},"annotations":[{"timestamp":1472470996238000,"value":"foo"},{"timestamp":1472470996403000,"value":"bar"}],"tags":{"clnt/finagle.version":"6.45.0","http.path":"/api"}},{"timestamp":1472470996199000,"duration":207000,"traceId":"4d1e00c0db9010db86154a4ba6e91385","id":"4d1e00c0db9010db","parentId":"86154a4ba6e91386","name":"put","kind":"SERVER","localEndpoint":{"serviceName":"frontend","ipv4":"0.0.0.0","ipv6":"7::80:807f"},"remoteEndpoint":{"serviceName":"frontend","ipv4":"192.168.99.101","port":9000},"annotations":[{"timestamp":1472470996238000,"value":"foo"},{"timestamp":1472470996403000,"value":"bar"}],"tags":{"clnt/finagle.version":"6.45.0","http.path":"/api"}}]

I noticed that there is an intentional fluffing of the IPv4 field if blank

zipkin-go/endpoint.go

Lines 65 to 71 in 70244c9

// default to 0 filled 4 byte array for IPv4 if IPv6 only host was found
if e.IPv4 == nil {
e.IPv4 = make([]byte, 4)
}
return e, nil
}

but I don't see a reason documented why this should be.

odeke-em added a commit to census-instrumentation/opencensus-service that referenced this issue Oct 29, 2018
…utes

This change introduces our own copy of a modified Zipkin Trace
exporter from OpenCensus-Go. This modification takes into
account the fact that our Zipkin interceptor "intercepts"/proxies
spans while the OpenCensus-Go Zipkin exporter assumes a static
world in which there is only one localEndpoint and no remoteEndpoint.
However, localEndpoint and remoteEndpoint are per-span fields
hence the necessity for us to ensure that users of this project
can have an almost transparent proxying and processing of Zipkin spans.

This change also features an end-to-end test that takes intercepted
Zipkin spans e.g. from a Zipkin Java exporting application, intercepts
them to the AgentCore and then on export we ensure that our output
has all the endpoints "localEndpoint", "remoteEndpoint" as well
as an equivalence of all the other fields.

Fixes #132
Supersedes census-instrumentation/opencensus-go#959
Supersedes census-instrumentation/opencensus-go#960
Tracking openzipkin/zipkin-go#85
@codefromthecrypt
Copy link
Member

codefromthecrypt commented Oct 30, 2018 via email

@ghost ghost added the review label Oct 30, 2018
@ghost ghost assigned basvanbeek Oct 30, 2018
basvanbeek added a commit that referenced this issue Oct 30, 2018
* NewEndpoint fix: use empty ipv4 or ipv6 if applicable
* fix lint issue
@ghost ghost removed the review label Oct 30, 2018
@odeke-em
Copy link
Contributor Author

Thank you for the feedback and advisory @adriancole and @basvanbeek for the fix!

odeke-em added a commit to census-instrumentation/opencensus-service that referenced this issue Oct 31, 2018
…utes

This change introduces our own copy of a modified Zipkin Trace
exporter from OpenCensus-Go. This modification takes into
account the fact that our Zipkin interceptor "intercepts"/proxies
spans while the OpenCensus-Go Zipkin exporter assumes a static
world in which there is only one localEndpoint and no remoteEndpoint.
However, localEndpoint and remoteEndpoint are per-span fields
hence the necessity for us to ensure that users of this project
can have an almost transparent proxying and processing of Zipkin spans.

This change also features an end-to-end test that takes intercepted
Zipkin spans e.g. from a Zipkin Java exporting application, intercepts
them to the AgentCore and then on export we ensure that our output
has all the endpoints "localEndpoint", "remoteEndpoint" as well
as an equivalence of all the other fields.

Fixes #132
Supersedes census-instrumentation/opencensus-go#959
Supersedes census-instrumentation/opencensus-go#960
Tracking openzipkin/zipkin-go#85
odeke-em added a commit to census-instrumentation/opencensus-service that referenced this issue Oct 31, 2018
…utes

This change introduces our own copy of a modified Zipkin Trace
exporter from OpenCensus-Go. This modification takes into
account the fact that our Zipkin interceptor "intercepts"/proxies
spans while the OpenCensus-Go Zipkin exporter assumes a static
world in which there is only one localEndpoint and no remoteEndpoint.
However, localEndpoint and remoteEndpoint are per-span fields
hence the necessity for us to ensure that users of this project
can have an almost transparent proxying and processing of Zipkin spans.

This change also features an end-to-end test that takes intercepted
Zipkin spans e.g. from a Zipkin Java exporting application, intercepts
them to the AgentCore and then on export we ensure that our output
has all the endpoints "localEndpoint", "remoteEndpoint" as well
as an equivalence of all the other fields.

We also now use the updated Zipkin-Go client after
    openzipkin/zipkin-go#85
was fixed with
    openzipkin/zipkin-go#86

The updated Zipkin-Go no longer serializes empty ipv4
addresses as 0.0.0.0 so remove those from our tests
Fixed as per openzipkin/zipkin-go#86

Fixes #132
Supersedes census-instrumentation/opencensus-go#959
Supersedes census-instrumentation/opencensus-go#960
Spawned openzipkin/zipkin-go#85
fivesheep pushed a commit to fivesheep/opencensus-service that referenced this issue Jun 12, 2019
…utes

This change introduces our own copy of a modified Zipkin Trace
exporter from OpenCensus-Go. This modification takes into
account the fact that our Zipkin interceptor "intercepts"/proxies
spans while the OpenCensus-Go Zipkin exporter assumes a static
world in which there is only one localEndpoint and no remoteEndpoint.
However, localEndpoint and remoteEndpoint are per-span fields
hence the necessity for us to ensure that users of this project
can have an almost transparent proxying and processing of Zipkin spans.

This change also features an end-to-end test that takes intercepted
Zipkin spans e.g. from a Zipkin Java exporting application, intercepts
them to the AgentCore and then on export we ensure that our output
has all the endpoints "localEndpoint", "remoteEndpoint" as well
as an equivalence of all the other fields.

We also now use the updated Zipkin-Go client after
    openzipkin/zipkin-go#85
was fixed with
    openzipkin/zipkin-go#86

The updated Zipkin-Go no longer serializes empty ipv4
addresses as 0.0.0.0 so remove those from our tests
Fixed as per openzipkin/zipkin-go#86

Fixes census-instrumentation#132
Supersedes census-instrumentation/opencensus-go#959
Supersedes census-instrumentation/opencensus-go#960
Spawned openzipkin/zipkin-go#85
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants