Skip to content

Use Protos, get rid of Zipkin & thrift.#7

Closed
tomwilkie wants to merge 6 commits intomasterfrom
protos
Closed

Use Protos, get rid of Zipkin & thrift.#7
tomwilkie wants to merge 6 commits intomasterfrom
protos

Conversation

@tomwilkie
Copy link
Contributor

@tomwilkie tomwilkie commented Apr 2, 2017

Mainly due to feedback from the Prometheus team about too many dependencies.

return &Collector{
traceIDs: make(map[int64]int, capacity),
traces: make([]trace, capacity, capacity),
traceIDs: make(map[uint64]int, capacity),

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fyi zipkin trace ids since a few months ago can be 128bit. in thrift format, the representation is high/low. in json it is simply a longer hex

}
}

func TestCodec(t *testing.T) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

when replacing codecs (ex squashing out a 3rd party dep like you have). I typically keep a test dep to ensure it is interoperable, at least for a while. That way you can tell if your endpoint works with zipkin or not (ex it accepts json or thrift, and your local codec can test against something else)

repeated Span spans = 2 [(gogoproto.nullable) = false];
}

message Span {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

interesting.. since the format is different it might be good to clarify your README statement

ex. "Internally Loki is really just an opinionated reimplementation of OpenZipkin."

Reimplementation typically uses the same model. Seems this is more like jaeger which has a different model, and supports interop to some degree. You might consider adding a section to the README explaining to users who find this tool what sort of interop is expected to work within zipkin. For example, it the api still compatible? if so which endpoints (is it just the collector or do the other endpoints still work)? If it is just collector, which of json or thrift work? If neither, then no existing zipkin instrumentation would work. On that note, since B3 isn't used, the tracer side of this isn't a reimplementation rather (again similar to jaeger) a different format and library.

Maybe least confusing is to stick with the first part of the README "inspired by" if interop isn't a goal.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thats a good point - with this change we're no longer zipkin compatible on the most part (the API will still be, as I don't want to implement my own UI)...

I've tried to make these protos more closely match the OpenTracing concepts & keywords. I'll include an update to the readme in this PR.

Thanks for the feedback Adrian!

@sipian
Copy link

sipian commented Sep 23, 2018

@tomwilkie
As mentioned by gouthamve in prometheus/prometheus#4509 (comment), I am building upon this to introduce in-memory tracing support in prometheus.

I am working in https://github.com/sipian/loki/tree/protos branch.
I will open a PR soon to get feedback for the changes.

[EDIT]
After going through the code, I am also thinking of directly integrating pkg folder into Prometheus repo.

@tomwilkie tomwilkie closed this Oct 29, 2020
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 this pull request may close these issues.

3 participants