han liu <mrpro...@gmail.com> 于2020年3月5日周四 下午8:03写道：
> Hi Sheng Wu > > I totally agree with it, and I think we only need to provide some API is > enough . Log level does not need to provide support. > Agree. Once this begins, I would say please provide a pull request to add the header protocol description to the repo. After that, the other would be easier. We could encourage other agents to support this too. Sheng Wu 吴晟 Twitter, wusheng1108 > > Sheng Wu <wu.sheng.841...@gmail.com> 于2020年3月5日周四 下午4:58写道： > > > 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 > > >> > > > > >> > > > >> > > > > > >
