Hi Han Liu Positive feedback from Zipkin team, Read this from Adrian, Zipkin lead. https://twitter.com/adrianfcole/status/1235424536608174080 Some similar features in the Zipkin Java SDK, brave project.
Sheng Wu 吴晟 Twitter, wusheng1108 Sheng Wu <wu.sheng.841...@gmail.com> 于2020年3月5日周四 上午10:35写道： > Hi Gao > > I am still confusing. If b3 used, then trace is the trace, there is > nothing related to what we do. > If application is instrumented by Zipkin SDK, then it is Zipkin's > transmission capability, not us. > > In the proposal, it is clear that our agent is going to propagate things > other injected and propagate them without touch. I can't see the link > between this and your mesh case. > > Sheng Wu 吴晟 > Twitter, wusheng1108 > > > Hongtao Gao <hanahm...@gmail.com> 于2020年3月5日周四 上午10:29写道： > >> Let me clarify what I'm talking about. >> >> In the Istio demo, just like Bookinfo, all of the apps implement Zipkin >> propagation, which means they can extract trace context from downstream >> and >> inject it to upstream. >> >> I want downside envoy sidecar instrumented by SkyWalking can wrap sw trace >> context into B3 context to bypass target app/service to upside sidecar. >> >> When it happens, skywalking can trace application instrumented only by >> Zipkin in service mesh scenario. >> >> I prefer to Zipkin that because it seems the actual standard tracing >> protocol in the SM world. And we leverage it as a lower-level protocol to >> figure out tracing context overlay. >> >> >> >> >> On Wed, Mar 4, 2020, 10:41 PM Sheng Wu <wu.sheng.841...@gmail.com> wrote: >> >> > Hi Gao >> > >> > Look through your reply, are you talking about propagating zipkin >> context >> > or skywalking context? Your case is not clear to me. >> > >> > Sheng Wu 吴晟 >> > Twitter, wusheng1108 >> > >> > >> > Hongtao Gao <hanahm...@gmail.com> 于2020年3月4日周三 下午10:31写道： >> > >> > > Look good to me. I think this feature is also fantastic to the Service >> > Mesh >> > > scenario. >> > > For now, OAP ingests send and receive messages from the sidecar and >> uses >> > > statistic analysis to link them to a topology. There's no trace here. >> > > >> > > If we implement the transmission protocol, the service workload can >> > bypass >> > > skywalking protocol, sidecar creates a segment and sinks it to OAP >> > instead. >> > > And furthermore, if we figure out sw6 over B3(Zipkin), our trace is >> > > connected by the application who implement Zipkin protocol. I know it >> may >> > > be >> > > a big challenge for us, but from my perspective, it's not impossible >> > > totally. >> > > >> > > Thanks, Hongtao >> > > >> > > han liu <mrpro...@gmail.com> 于2020年3月4日周三 下午5:06写道： >> > > >> > > > Hi dev team, >> > > > >> > > > I want to provide a message transmission future, which can be used >> for >> > > > message transmission in projects that already use skywalking. >> > > > This future of data transmission between multiple instances in the >> same >> > > > trace can be achieved by adding a new API of information >> transmission >> > in >> > > > each language level, which does not need a dependency on the >> existing >> > > > interface protocol. >> > > > For example, the execution process of a trace is A -> B -> C, Set >> > > transfer >> > > > content in A service, B and C services can obtain data through API. >> > > > This future is to use the message passing future of Skywaling, >> addition >> > > an >> > > > extension function. I'm not quite sure if it's appropriate to add >> it to >> > > > Skywalking? >> > > > >> > > > Currently, it can be applied to these scenarios: >> > > > 1. For the existing old system, It's not convenient to revise the >> data >> > of >> > > > the existing protocol. Through embedding transparent data, >> downstream >> > > > services can get data information. >> > > > 2. In the entry layer, such as zuul or other gateway services, >> > > > transparently transmits user identity or other customized >> information >> > to >> > > > the downstream services. >> > > > >> > > > Implementation plan: >> > > > 1. Store transmission data as Map in the current segment. >> > > > 2. Create a new protocol header for data transmission (JSON) >> > > > 3. When the downstream system receives the new protocol, it will >> > > transform >> > > > the data back to Map and store to the segment >> > > > 4. I think this implementation should apply to trace and ignored >> > segment, >> > > > otherwise, transmission data maybe will be lost. >> > > > >> > > >> > > >> > > -- >> > > Hongtao Gao >> > > >> > > Apache SkyWalking && Apache ShardingSphere >> > > Twitter, @hanahmily >> > > >> > >> >
