-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Adds v2 SpanStore and a bridging adapter to v1 #1709
Conversation
PS once this is in, the v2 http api (openapi/swagger etc) can be implemented. Later, we can formalize and make the java libraries not-internal. |
55c0148
to
176099f
Compare
a6ef2bc
to
b19b1e3
Compare
ok all apis are here, and I'll raise two other PRs: one to add the http api and another to implement with elasticsearch. There's still a solid amount of work on this PR, yet, which is to backfill tests and make a v2 replacement for SpanStoreTest One thing you'll notice is I made a copy of the bridging read api from elasticsearch to here. This is to decouple change. The elasticsearch copy will be deleted later. cc @anuraaga |
b19b1e3
to
d51ec34
Compare
OK backfilled almost all tests. nearly there |
d51ec34
to
a442821
Compare
a442821
to
5b88715
Compare
This adds SpanStore which returns Call objects as opposed to replicating signatures for synchronous and asynchronous invocations. Unlike before, this does not support "adjustments" rather assumes they happen at a layer above storage. This decision refines the storage query api to the following: ```java Call<List<List<Span>>> getTraces(QueryRequest request); Call<List<Span>> getTrace(long traceIdHigh, long traceIdLow); Call<List<String>> getServiceNames(); Call<List<String>> getSpanNames(String serviceName); Call<List<DependencyLink>> getDependencies(long endTs, long lookback); ``` A later change might replace the getTrace call with a hex string parameter.
This adds SpanStore which returns Call objects as opposed to replicating signatures for synchronous and asynchronous invocations. Unlike before, this does not support "adjustments" rather assumes they happen at a layer above storage. This decision refines the storage query api to the following: ```java Call<List<List<Span>>> getTraces(QueryRequest request); Call<List<Span>> getTrace(long traceIdHigh, long traceIdLow); Call<List<String>> getServiceNames(); Call<List<String>> getSpanNames(String serviceName); Call<List<DependencyLink>> getDependencies(long endTs, long lookback); ``` A later change might replace the getTrace call with a hex string parameter.
This represents the minimal read apis needed for Zipkin
As discussed earlier on gitter w/ @basvanbeek, we no longer do
adjustment at storage layer. Essentially, all operations are "raw",
which reduces the responsibility of implementors. This also midly
changes the
getTrace
call, disallowing it from returning null (asempty will suffice).
This adds SpanStore which returns Call objects as opposed to replicating
signatures for synchronous and asynchronous invocations. Unlike before,
this does not support "adjustments" rather assumes they happen at a
layer above storage. This decision refines the storage query api to the
following:
A later change might replace the getTrace call with a hex string
parameter.