You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@skywalking.apache.org by Willem Jiang <wi...@gmail.com> on 2019/09/04 01:24:44 UTC
Re: Integration of Skywalking agent with ServiceComb Pack.
On Tue, Sep 3, 2019 at 10:52 PM Zhang Lei <zh...@boco.com.cn> wrote:
>
> Hi Willem,
>
> I agree to integrate a transaction tracking service, I used Zipkin, but I don't know much about Skywalking.
>
> I have some questions:
>
> 1. Skywalking agent just working on the Omega side?
Yep, but we can also let the agent do the instrumentation on the Alpha side.
> 2. Use @Trace in the same location as @SagaStart and @Compensable, Or Combined annotation? And use TraceContext.traceId() to generate globalTxId or localTxId ?
This is the detail thing we need to think about.
I think you are just proposing a way to integrate the Zipkin, am I right?
> 3. Will Omega users have conflicts if they already use Zipkin?
We need to do some end to end verification, currently I think it's
fine if we can find a way to generate a correlation id between tracing
system and pack, we don't need to deeply combine these two system
together, they can work separately.
> 4. About provides a service to bridge the Trace information that Skywalking collects with ServiceComb Pack Transaction events information. Do you mean that Alpha sends service chain information directly to Skywalking via API?
It's more like a portal integration. We can still leverage the old API
provide by Skywalking and ServiceComb Pack.
>
> Lei Zhang
>
> > 在 2019年9月3日，下午7:22，Willem Jiang <wi...@gmail.com> 写道：
> >
> > Hi,
> >
> > As ServiceComb Pack use the GlobalTransactionId to trace the
> > distributed transactions, it's make sense that let the ServiceComb
> > Pack and Skywalking share the same Id for tracing.
> > In this way, we can bring the APM feature into Distribution
> > Transaction managemet world.
> >
> > Current ServiceComb has Interface IdGenerator[1], which is used for
> > the generate the GlobalTransactionId in OmegaContext[2]. I think if we
> > can reuse the transaction implementation with the Skywalking agent to
> > generate the GlobalTransactionId. In this way we can search the trace
> > information and transactions with same correlation ID.
> >
> > The missing part is LocalTransactionId, we need to figure a way to
> > bring the LocalTransactionId with the trace information.
> >
> > BTW, ServiceComb Pack is using ES to store the Transaction related
> > event[3]. I think we can provide a service to bridge the Trace
> > information that Skywalking collects with ServiceComb Pack Transaction
> > events information.
> >
> > Any thoughts?
> >
> > [1]https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/IdGenerator.java
> > [2]https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/OmegaContext.java
> > [3]https://github.com/apache/servicecomb-pack/tree/master/alpha/alpha-fsm
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
>
Re: Integration of Skywalking agent with ServiceComb Pack.
Posted by Zheng Feng <zh...@gmail.com>.
Thanks a lot and I think these could be very helpful !
Sheng Wu <wu...@gmail.com> 于2019年9月5日周四 下午10:30写道：
> We have a service comb RPC plugin, provided by you before.
> For pack and transaction, we need another plugin.
>
> There are a lot of plugins you could ref, and Seata plugin is WIP too,
> https://github.com/apache/skywalking/pulls. Wait for new protocol stable
> at
> Seata side.
>
> Sheng Wu 吴晟
>
> Apache SkyWalking, Apache ShardingSphere(Incubating), Zipkin
> Twitter, wusheng1108
>
>
> Zheng Feng <zh...@gmail.com> 于2019年9月5日周四 上午7:28写道：
>
> > So we have to dev a new plugin for the servicecomb-pack or there is a
> > plugin we could leverage with ?
> >
> > Sheng Wu <wu...@gmail.com> 于2019年9月5日周四 下午10:08写道：
> >
> > > Then SkyWalking has a toolkit lib[1], you could use
> > > `TraceContext.traceId()` in any place, if there is sw agent attached,
> and
> > > current context has been traced, you could have the trace id.
> > >
> > > [1]
> > >
> > >
> >
> https://github.com/apache/skywalking/blob/master/docs/en/setup/service-agent/java-agent/Application-toolkit-trace.md
> > >
> > > Sheng Wu 吴晟
> > >
> > > Apache SkyWalking, Apache ShardingSphere(Incubating), Zipkin
> > > Twitter, wusheng1108
> > >
> > >
> > > Zheng Feng <zh...@gmail.com> 于2019年9月5日周四 上午5:46写道：
> > >
> > > > Sheng Wu <wu...@gmail.com> 于2019年9月4日周三 上午11:31写道：
> > > >
> > > > > Willem Jiang <wi...@gmail.com> 于2019年9月3日周二 下午6:25写道：
> > > > >
> > > > > > On Tue, Sep 3, 2019 at 10:52 PM Zhang Lei <zhang_lei@boco.com.cn
> >
> > > > wrote:
> > > > > > >
> > > > > > > Hi Willem,
> > > > > > >
> > > > > > > I agree to integrate a transaction tracking service, I used
> > > Zipkin,
> > > > > but
> > > > > > I don't know much about Skywalking.
> > > > > > >
> > > > > > > I have some questions:
> > > > > > >
> > > > > > > 1. Skywalking agent just working on the Omega side?
> > > > > > Yep, but we can also let the agent do the instrumentation on the
> > > Alpha
> > > > > > side.
> > > > >
> > > > >
> > > > > > > 2. Use @Trace in the same location as @SagaStart and
> > @Compensable,
> > > Or
> > > > > > Combined annotation? And use TraceContext.traceId() to generate
> > > > > globalTxId
> > > > > > or localTxId ?
> > > > > > This is the detail thing we need to think about.
> > > > > > I think you are just proposing a way to integrate the Zipkin, am
> I
> > > > right?
> > > > > >
> > > > >
> > > > > @Trace is SkyWalking annotation, which SkyWalking agent could
> > identify
> > > > and
> > > > > instrument as a local span(Not RPC related)
> > > > >
> > > > >
> > > > > >
> > > > > > > 3. Will Omega users have conflicts if they already use Zipkin?
> > > > > > We need to do some end to end verification, currently I think
> it's
> > > > > > fine if we can find a way to generate a correlation id between
> > > tracing
> > > > > > system and pack, we don't need to deeply combine these two system
> > > > > > together, they can work separately.
> > > > > >
> > > > >
> > > > > SkyWalking doesn't conflict with Zipkin, but I don't recommend to
> use
> > > > both
> > > > > at the same time, because it is pointless.
> > > > >
> > > > >
> > > > > >
> > > > > > > 4. About provides a service to bridge the Trace information
> that
> > > > > > Skywalking collects with ServiceComb Pack Transaction events
> > > > information.
> > > > > > Do you mean that Alpha sends service chain information directly
> to
> > > > > > Skywalking via API?
> > > > > > It's more like a portal integration. We can still leverage the
> old
> > > API
> > > > > > provide by Skywalking and ServiceComb Pack.
> > > > > >
> > > > >
> > > > > In this way, we need to have a deeper discussion about what
> > ServiceComb
> > > > > wants and requires.
> > > > >
> > > > Basically, I think we need to track the saga transaction status by
> the
> > > > global id.
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Lei Zhang
> > > > > > >
> > > > > > > > 在 2019年9月3日，下午7:22，Willem Jiang <wi...@gmail.com> 写道：
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > As ServiceComb Pack use the GlobalTransactionId to trace the
> > > > > > > > distributed transactions, it's make sense that let the
> > > ServiceComb
> > > > > > > > Pack and Skywalking share the same Id for tracing.
> > > > > > > > In this way, we can bring the APM feature into Distribution
> > > > > > > > Transaction managemet world.
> > > > > > > >
> > > > > > > > Current ServiceComb has Interface IdGenerator[1], which is
> used
> > > for
> > > > > > > > the generate the GlobalTransactionId in OmegaContext[2]. I
> > think
> > > if
> > > > > we
> > > > > > > > can reuse the transaction implementation with the Skywalking
> > > agent
> > > > to
> > > > > > > > generate the GlobalTransactionId. In this way we can search
> the
> > > > trace
> > > > > > > > information and transactions with same correlation ID.
> > > > > > > >
> > > > > > > > The missing part is LocalTransactionId, we need to figure a
> way
> > > to
> > > > > > > > bring the LocalTransactionId with the trace information.
> > > > > > > >
> > > > > > > > BTW, ServiceComb Pack is using ES to store the Transaction
> > > related
> > > > > > > > event[3]. I think we can provide a service to bridge the
> Trace
> > > > > > > > information that Skywalking collects with ServiceComb Pack
> > > > > Transaction
> > > > > > > > events information.
> > > > > > > >
> > > > > > > > Any thoughts?
> > > > > > > >
> > > > > > > > [1]
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/IdGenerator.java
> > > > > > > > [2]
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/OmegaContext.java
> > > > > > > > [3]
> > > > > >
> > > https://github.com/apache/servicecomb-pack/tree/master/alpha/alpha-fsm
> > > > > > > >
> > > > > > > > Willem Jiang
> > > > > > > >
> > > > > > > > Twitter: willemjiang
> > > > > > > > Weibo: 姜宁willem
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Integration of Skywalking agent with ServiceComb Pack.
Posted by Zheng Feng <zh...@gmail.com>.
Thanks a lot and I think these could be very helpful !
Sheng Wu <wu...@gmail.com> 于2019年9月5日周四 下午10:30写道：
> We have a service comb RPC plugin, provided by you before.
> For pack and transaction, we need another plugin.
>
> There are a lot of plugins you could ref, and Seata plugin is WIP too,
> https://github.com/apache/skywalking/pulls. Wait for new protocol stable
> at
> Seata side.
>
> Sheng Wu 吴晟
>
> Apache SkyWalking, Apache ShardingSphere(Incubating), Zipkin
> Twitter, wusheng1108
>
>
> Zheng Feng <zh...@gmail.com> 于2019年9月5日周四 上午7:28写道：
>
> > So we have to dev a new plugin for the servicecomb-pack or there is a
> > plugin we could leverage with ?
> >
> > Sheng Wu <wu...@gmail.com> 于2019年9月5日周四 下午10:08写道：
> >
> > > Then SkyWalking has a toolkit lib[1], you could use
> > > `TraceContext.traceId()` in any place, if there is sw agent attached,
> and
> > > current context has been traced, you could have the trace id.
> > >
> > > [1]
> > >
> > >
> >
> https://github.com/apache/skywalking/blob/master/docs/en/setup/service-agent/java-agent/Application-toolkit-trace.md
> > >
> > > Sheng Wu 吴晟
> > >
> > > Apache SkyWalking, Apache ShardingSphere(Incubating), Zipkin
> > > Twitter, wusheng1108
> > >
> > >
> > > Zheng Feng <zh...@gmail.com> 于2019年9月5日周四 上午5:46写道：
> > >
> > > > Sheng Wu <wu...@gmail.com> 于2019年9月4日周三 上午11:31写道：
> > > >
> > > > > Willem Jiang <wi...@gmail.com> 于2019年9月3日周二 下午6:25写道：
> > > > >
> > > > > > On Tue, Sep 3, 2019 at 10:52 PM Zhang Lei <zhang_lei@boco.com.cn
> >
> > > > wrote:
> > > > > > >
> > > > > > > Hi Willem,
> > > > > > >
> > > > > > > I agree to integrate a transaction tracking service, I used
> > > Zipkin,
> > > > > but
> > > > > > I don't know much about Skywalking.
> > > > > > >
> > > > > > > I have some questions:
> > > > > > >
> > > > > > > 1. Skywalking agent just working on the Omega side?
> > > > > > Yep, but we can also let the agent do the instrumentation on the
> > > Alpha
> > > > > > side.
> > > > >
> > > > >
> > > > > > > 2. Use @Trace in the same location as @SagaStart and
> > @Compensable,
> > > Or
> > > > > > Combined annotation? And use TraceContext.traceId() to generate
> > > > > globalTxId
> > > > > > or localTxId ?
> > > > > > This is the detail thing we need to think about.
> > > > > > I think you are just proposing a way to integrate the Zipkin, am
> I
> > > > right?
> > > > > >
> > > > >
> > > > > @Trace is SkyWalking annotation, which SkyWalking agent could
> > identify
> > > > and
> > > > > instrument as a local span(Not RPC related)
> > > > >
> > > > >
> > > > > >
> > > > > > > 3. Will Omega users have conflicts if they already use Zipkin?
> > > > > > We need to do some end to end verification, currently I think
> it's
> > > > > > fine if we can find a way to generate a correlation id between
> > > tracing
> > > > > > system and pack, we don't need to deeply combine these two system
> > > > > > together, they can work separately.
> > > > > >
> > > > >
> > > > > SkyWalking doesn't conflict with Zipkin, but I don't recommend to
> use
> > > > both
> > > > > at the same time, because it is pointless.
> > > > >
> > > > >
> > > > > >
> > > > > > > 4. About provides a service to bridge the Trace information
> that
> > > > > > Skywalking collects with ServiceComb Pack Transaction events
> > > > information.
> > > > > > Do you mean that Alpha sends service chain information directly
> to
> > > > > > Skywalking via API?
> > > > > > It's more like a portal integration. We can still leverage the
> old
> > > API
> > > > > > provide by Skywalking and ServiceComb Pack.
> > > > > >
> > > > >
> > > > > In this way, we need to have a deeper discussion about what
> > ServiceComb
> > > > > wants and requires.
> > > > >
> > > > Basically, I think we need to track the saga transaction status by
> the
> > > > global id.
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Lei Zhang
> > > > > > >
> > > > > > > > 在 2019年9月3日，下午7:22，Willem Jiang <wi...@gmail.com> 写道：
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > As ServiceComb Pack use the GlobalTransactionId to trace the
> > > > > > > > distributed transactions, it's make sense that let the
> > > ServiceComb
> > > > > > > > Pack and Skywalking share the same Id for tracing.
> > > > > > > > In this way, we can bring the APM feature into Distribution
> > > > > > > > Transaction managemet world.
> > > > > > > >
> > > > > > > > Current ServiceComb has Interface IdGenerator[1], which is
> used
> > > for
> > > > > > > > the generate the GlobalTransactionId in OmegaContext[2]. I
> > think
> > > if
> > > > > we
> > > > > > > > can reuse the transaction implementation with the Skywalking
> > > agent
> > > > to
> > > > > > > > generate the GlobalTransactionId. In this way we can search
> the
> > > > trace
> > > > > > > > information and transactions with same correlation ID.
> > > > > > > >
> > > > > > > > The missing part is LocalTransactionId, we need to figure a
> way
> > > to
> > > > > > > > bring the LocalTransactionId with the trace information.
> > > > > > > >
> > > > > > > > BTW, ServiceComb Pack is using ES to store the Transaction
> > > related
> > > > > > > > event[3]. I think we can provide a service to bridge the
> Trace
> > > > > > > > information that Skywalking collects with ServiceComb Pack
> > > > > Transaction
> > > > > > > > events information.
> > > > > > > >
> > > > > > > > Any thoughts?
> > > > > > > >
> > > > > > > > [1]
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/IdGenerator.java
> > > > > > > > [2]
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/OmegaContext.java
> > > > > > > > [3]
> > > > > >
> > > https://github.com/apache/servicecomb-pack/tree/master/alpha/alpha-fsm
> > > > > > > >
> > > > > > > > Willem Jiang
> > > > > > > >
> > > > > > > > Twitter: willemjiang
> > > > > > > > Weibo: 姜宁willem
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Integration of Skywalking agent with ServiceComb Pack.
Posted by Zheng Feng <zh...@gmail.com>.
Thanks a lot and I think these could be very helpful !
Sheng Wu <wu...@gmail.com> 于2019年9月5日周四 下午10:30写道：
> We have a service comb RPC plugin, provided by you before.
> For pack and transaction, we need another plugin.
>
> There are a lot of plugins you could ref, and Seata plugin is WIP too,
> https://github.com/apache/skywalking/pulls. Wait for new protocol stable
> at
> Seata side.
>
> Sheng Wu 吴晟
>
> Apache SkyWalking, Apache ShardingSphere(Incubating), Zipkin
> Twitter, wusheng1108
>
>
> Zheng Feng <zh...@gmail.com> 于2019年9月5日周四 上午7:28写道：
>
> > So we have to dev a new plugin for the servicecomb-pack or there is a
> > plugin we could leverage with ?
> >
> > Sheng Wu <wu...@gmail.com> 于2019年9月5日周四 下午10:08写道：
> >
> > > Then SkyWalking has a toolkit lib[1], you could use
> > > `TraceContext.traceId()` in any place, if there is sw agent attached,
> and
> > > current context has been traced, you could have the trace id.
> > >
> > > [1]
> > >
> > >
> >
> https://github.com/apache/skywalking/blob/master/docs/en/setup/service-agent/java-agent/Application-toolkit-trace.md
> > >
> > > Sheng Wu 吴晟
> > >
> > > Apache SkyWalking, Apache ShardingSphere(Incubating), Zipkin
> > > Twitter, wusheng1108
> > >
> > >
> > > Zheng Feng <zh...@gmail.com> 于2019年9月5日周四 上午5:46写道：
> > >
> > > > Sheng Wu <wu...@gmail.com> 于2019年9月4日周三 上午11:31写道：
> > > >
> > > > > Willem Jiang <wi...@gmail.com> 于2019年9月3日周二 下午6:25写道：
> > > > >
> > > > > > On Tue, Sep 3, 2019 at 10:52 PM Zhang Lei <zhang_lei@boco.com.cn
> >
> > > > wrote:
> > > > > > >
> > > > > > > Hi Willem,
> > > > > > >
> > > > > > > I agree to integrate a transaction tracking service, I used
> > > Zipkin,
> > > > > but
> > > > > > I don't know much about Skywalking.
> > > > > > >
> > > > > > > I have some questions:
> > > > > > >
> > > > > > > 1. Skywalking agent just working on the Omega side?
> > > > > > Yep, but we can also let the agent do the instrumentation on the
> > > Alpha
> > > > > > side.
> > > > >
> > > > >
> > > > > > > 2. Use @Trace in the same location as @SagaStart and
> > @Compensable,
> > > Or
> > > > > > Combined annotation? And use TraceContext.traceId() to generate
> > > > > globalTxId
> > > > > > or localTxId ?
> > > > > > This is the detail thing we need to think about.
> > > > > > I think you are just proposing a way to integrate the Zipkin, am
> I
> > > > right?
> > > > > >
> > > > >
> > > > > @Trace is SkyWalking annotation, which SkyWalking agent could
> > identify
> > > > and
> > > > > instrument as a local span(Not RPC related)
> > > > >
> > > > >
> > > > > >
> > > > > > > 3. Will Omega users have conflicts if they already use Zipkin?
> > > > > > We need to do some end to end verification, currently I think
> it's
> > > > > > fine if we can find a way to generate a correlation id between
> > > tracing
> > > > > > system and pack, we don't need to deeply combine these two system
> > > > > > together, they can work separately.
> > > > > >
> > > > >
> > > > > SkyWalking doesn't conflict with Zipkin, but I don't recommend to
> use
> > > > both
> > > > > at the same time, because it is pointless.
> > > > >
> > > > >
> > > > > >
> > > > > > > 4. About provides a service to bridge the Trace information
> that
> > > > > > Skywalking collects with ServiceComb Pack Transaction events
> > > > information.
> > > > > > Do you mean that Alpha sends service chain information directly
> to
> > > > > > Skywalking via API?
> > > > > > It's more like a portal integration. We can still leverage the
> old
> > > API
> > > > > > provide by Skywalking and ServiceComb Pack.
> > > > > >
> > > > >
> > > > > In this way, we need to have a deeper discussion about what
> > ServiceComb
> > > > > wants and requires.
> > > > >
> > > > Basically, I think we need to track the saga transaction status by
> the
> > > > global id.
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Lei Zhang
> > > > > > >
> > > > > > > > 在 2019年9月3日，下午7:22，Willem Jiang <wi...@gmail.com> 写道：
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > As ServiceComb Pack use the GlobalTransactionId to trace the
> > > > > > > > distributed transactions, it's make sense that let the
> > > ServiceComb
> > > > > > > > Pack and Skywalking share the same Id for tracing.
> > > > > > > > In this way, we can bring the APM feature into Distribution
> > > > > > > > Transaction managemet world.
> > > > > > > >
> > > > > > > > Current ServiceComb has Interface IdGenerator[1], which is
> used
> > > for
> > > > > > > > the generate the GlobalTransactionId in OmegaContext[2]. I
> > think
> > > if
> > > > > we
> > > > > > > > can reuse the transaction implementation with the Skywalking
> > > agent
> > > > to
> > > > > > > > generate the GlobalTransactionId. In this way we can search
> the
> > > > trace
> > > > > > > > information and transactions with same correlation ID.
> > > > > > > >
> > > > > > > > The missing part is LocalTransactionId, we need to figure a
> way
> > > to
> > > > > > > > bring the LocalTransactionId with the trace information.
> > > > > > > >
> > > > > > > > BTW, ServiceComb Pack is using ES to store the Transaction
> > > related
> > > > > > > > event[3]. I think we can provide a service to bridge the
> Trace
> > > > > > > > information that Skywalking collects with ServiceComb Pack
> > > > > Transaction
> > > > > > > > events information.
> > > > > > > >
> > > > > > > > Any thoughts?
> > > > > > > >
> > > > > > > > [1]
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/IdGenerator.java
> > > > > > > > [2]
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/OmegaContext.java
> > > > > > > > [3]
> > > > > >
> > > https://github.com/apache/servicecomb-pack/tree/master/alpha/alpha-fsm
> > > > > > > >
> > > > > > > > Willem Jiang
> > > > > > > >
> > > > > > > > Twitter: willemjiang
> > > > > > > > Weibo: 姜宁willem
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Integration of Skywalking agent with ServiceComb Pack.
Posted by Sheng Wu <wu...@gmail.com>.
We have a service comb RPC plugin, provided by you before.
For pack and transaction, we need another plugin.
There are a lot of plugins you could ref, and Seata plugin is WIP too,
https://github.com/apache/skywalking/pulls. Wait for new protocol stable at
Seata side.
Sheng Wu 吴晟
Apache SkyWalking, Apache ShardingSphere(Incubating), Zipkin
Twitter, wusheng1108
Zheng Feng <zh...@gmail.com> 于2019年9月5日周四 上午7:28写道：
> So we have to dev a new plugin for the servicecomb-pack or there is a
> plugin we could leverage with ?
>
> Sheng Wu <wu...@gmail.com> 于2019年9月5日周四 下午10:08写道：
>
> > Then SkyWalking has a toolkit lib[1], you could use
> > `TraceContext.traceId()` in any place, if there is sw agent attached, and
> > current context has been traced, you could have the trace id.
> >
> > [1]
> >
> >
> https://github.com/apache/skywalking/blob/master/docs/en/setup/service-agent/java-agent/Application-toolkit-trace.md
> >
> > Sheng Wu 吴晟
> >
> > Apache SkyWalking, Apache ShardingSphere(Incubating), Zipkin
> > Twitter, wusheng1108
> >
> >
> > Zheng Feng <zh...@gmail.com> 于2019年9月5日周四 上午5:46写道：
> >
> > > Sheng Wu <wu...@gmail.com> 于2019年9月4日周三 上午11:31写道：
> > >
> > > > Willem Jiang <wi...@gmail.com> 于2019年9月3日周二 下午6:25写道：
> > > >
> > > > > On Tue, Sep 3, 2019 at 10:52 PM Zhang Lei <zh...@boco.com.cn>
> > > wrote:
> > > > > >
> > > > > > Hi Willem,
> > > > > >
> > > > > > I agree to integrate a transaction tracking service, I used
> > Zipkin,
> > > > but
> > > > > I don't know much about Skywalking.
> > > > > >
> > > > > > I have some questions:
> > > > > >
> > > > > > 1. Skywalking agent just working on the Omega side?
> > > > > Yep, but we can also let the agent do the instrumentation on the
> > Alpha
> > > > > side.
> > > >
> > > >
> > > > > > 2. Use @Trace in the same location as @SagaStart and
> @Compensable,
> > Or
> > > > > Combined annotation? And use TraceContext.traceId() to generate
> > > > globalTxId
> > > > > or localTxId ?
> > > > > This is the detail thing we need to think about.
> > > > > I think you are just proposing a way to integrate the Zipkin, am I
> > > right?
> > > > >
> > > >
> > > > @Trace is SkyWalking annotation, which SkyWalking agent could
> identify
> > > and
> > > > instrument as a local span(Not RPC related)
> > > >
> > > >
> > > > >
> > > > > > 3. Will Omega users have conflicts if they already use Zipkin?
> > > > > We need to do some end to end verification, currently I think it's
> > > > > fine if we can find a way to generate a correlation id between
> > tracing
> > > > > system and pack, we don't need to deeply combine these two system
> > > > > together, they can work separately.
> > > > >
> > > >
> > > > SkyWalking doesn't conflict with Zipkin, but I don't recommend to use
> > > both
> > > > at the same time, because it is pointless.
> > > >
> > > >
> > > > >
> > > > > > 4. About provides a service to bridge the Trace information that
> > > > > Skywalking collects with ServiceComb Pack Transaction events
> > > information.
> > > > > Do you mean that Alpha sends service chain information directly to
> > > > > Skywalking via API?
> > > > > It's more like a portal integration. We can still leverage the old
> > API
> > > > > provide by Skywalking and ServiceComb Pack.
> > > > >
> > > >
> > > > In this way, we need to have a deeper discussion about what
> ServiceComb
> > > > wants and requires.
> > > >
> > > Basically, I think we need to track the saga transaction status by the
> > > global id.
> > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > > Lei Zhang
> > > > > >
> > > > > > > 在 2019年9月3日，下午7:22，Willem Jiang <wi...@gmail.com> 写道：
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > As ServiceComb Pack use the GlobalTransactionId to trace the
> > > > > > > distributed transactions, it's make sense that let the
> > ServiceComb
> > > > > > > Pack and Skywalking share the same Id for tracing.
> > > > > > > In this way, we can bring the APM feature into Distribution
> > > > > > > Transaction managemet world.
> > > > > > >
> > > > > > > Current ServiceComb has Interface IdGenerator[1], which is used
> > for
> > > > > > > the generate the GlobalTransactionId in OmegaContext[2]. I
> think
> > if
> > > > we
> > > > > > > can reuse the transaction implementation with the Skywalking
> > agent
> > > to
> > > > > > > generate the GlobalTransactionId. In this way we can search the
> > > trace
> > > > > > > information and transactions with same correlation ID.
> > > > > > >
> > > > > > > The missing part is LocalTransactionId, we need to figure a way
> > to
> > > > > > > bring the LocalTransactionId with the trace information.
> > > > > > >
> > > > > > > BTW, ServiceComb Pack is using ES to store the Transaction
> > related
> > > > > > > event[3]. I think we can provide a service to bridge the Trace
> > > > > > > information that Skywalking collects with ServiceComb Pack
> > > > Transaction
> > > > > > > events information.
> > > > > > >
> > > > > > > Any thoughts?
> > > > > > >
> > > > > > > [1]
> > > > >
> > > >
> > >
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/IdGenerator.java
> > > > > > > [2]
> > > > >
> > > >
> > >
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/OmegaContext.java
> > > > > > > [3]
> > > > >
> > https://github.com/apache/servicecomb-pack/tree/master/alpha/alpha-fsm
> > > > > > >
> > > > > > > Willem Jiang
> > > > > > >
> > > > > > > Twitter: willemjiang
> > > > > > > Weibo: 姜宁willem
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Integration of Skywalking agent with ServiceComb Pack.
Posted by Sheng Wu <wu...@gmail.com>.
We have a service comb RPC plugin, provided by you before.
For pack and transaction, we need another plugin.
There are a lot of plugins you could ref, and Seata plugin is WIP too,
https://github.com/apache/skywalking/pulls. Wait for new protocol stable at
Seata side.
Sheng Wu 吴晟
Apache SkyWalking, Apache ShardingSphere(Incubating), Zipkin
Twitter, wusheng1108
Zheng Feng <zh...@gmail.com> 于2019年9月5日周四 上午7:28写道：
> So we have to dev a new plugin for the servicecomb-pack or there is a
> plugin we could leverage with ?
>
> Sheng Wu <wu...@gmail.com> 于2019年9月5日周四 下午10:08写道：
>
> > Then SkyWalking has a toolkit lib[1], you could use
> > `TraceContext.traceId()` in any place, if there is sw agent attached, and
> > current context has been traced, you could have the trace id.
> >
> > [1]
> >
> >
> https://github.com/apache/skywalking/blob/master/docs/en/setup/service-agent/java-agent/Application-toolkit-trace.md
> >
> > Sheng Wu 吴晟
> >
> > Apache SkyWalking, Apache ShardingSphere(Incubating), Zipkin
> > Twitter, wusheng1108
> >
> >
> > Zheng Feng <zh...@gmail.com> 于2019年9月5日周四 上午5:46写道：
> >
> > > Sheng Wu <wu...@gmail.com> 于2019年9月4日周三 上午11:31写道：
> > >
> > > > Willem Jiang <wi...@gmail.com> 于2019年9月3日周二 下午6:25写道：
> > > >
> > > > > On Tue, Sep 3, 2019 at 10:52 PM Zhang Lei <zh...@boco.com.cn>
> > > wrote:
> > > > > >
> > > > > > Hi Willem,
> > > > > >
> > > > > > I agree to integrate a transaction tracking service, I used
> > Zipkin,
> > > > but
> > > > > I don't know much about Skywalking.
> > > > > >
> > > > > > I have some questions:
> > > > > >
> > > > > > 1. Skywalking agent just working on the Omega side?
> > > > > Yep, but we can also let the agent do the instrumentation on the
> > Alpha
> > > > > side.
> > > >
> > > >
> > > > > > 2. Use @Trace in the same location as @SagaStart and
> @Compensable,
> > Or
> > > > > Combined annotation? And use TraceContext.traceId() to generate
> > > > globalTxId
> > > > > or localTxId ?
> > > > > This is the detail thing we need to think about.
> > > > > I think you are just proposing a way to integrate the Zipkin, am I
> > > right?
> > > > >
> > > >
> > > > @Trace is SkyWalking annotation, which SkyWalking agent could
> identify
> > > and
> > > > instrument as a local span(Not RPC related)
> > > >
> > > >
> > > > >
> > > > > > 3. Will Omega users have conflicts if they already use Zipkin?
> > > > > We need to do some end to end verification, currently I think it's
> > > > > fine if we can find a way to generate a correlation id between
> > tracing
> > > > > system and pack, we don't need to deeply combine these two system
> > > > > together, they can work separately.
> > > > >
> > > >
> > > > SkyWalking doesn't conflict with Zipkin, but I don't recommend to use
> > > both
> > > > at the same time, because it is pointless.
> > > >
> > > >
> > > > >
> > > > > > 4. About provides a service to bridge the Trace information that
> > > > > Skywalking collects with ServiceComb Pack Transaction events
> > > information.
> > > > > Do you mean that Alpha sends service chain information directly to
> > > > > Skywalking via API?
> > > > > It's more like a portal integration. We can still leverage the old
> > API
> > > > > provide by Skywalking and ServiceComb Pack.
> > > > >
> > > >
> > > > In this way, we need to have a deeper discussion about what
> ServiceComb
> > > > wants and requires.
> > > >
> > > Basically, I think we need to track the saga transaction status by the
> > > global id.
> > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > > Lei Zhang
> > > > > >
> > > > > > > 在 2019年9月3日，下午7:22，Willem Jiang <wi...@gmail.com> 写道：
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > As ServiceComb Pack use the GlobalTransactionId to trace the
> > > > > > > distributed transactions, it's make sense that let the
> > ServiceComb
> > > > > > > Pack and Skywalking share the same Id for tracing.
> > > > > > > In this way, we can bring the APM feature into Distribution
> > > > > > > Transaction managemet world.
> > > > > > >
> > > > > > > Current ServiceComb has Interface IdGenerator[1], which is used
> > for
> > > > > > > the generate the GlobalTransactionId in OmegaContext[2]. I
> think
> > if
> > > > we
> > > > > > > can reuse the transaction implementation with the Skywalking
> > agent
> > > to
> > > > > > > generate the GlobalTransactionId. In this way we can search the
> > > trace
> > > > > > > information and transactions with same correlation ID.
> > > > > > >
> > > > > > > The missing part is LocalTransactionId, we need to figure a way
> > to
> > > > > > > bring the LocalTransactionId with the trace information.
> > > > > > >
> > > > > > > BTW, ServiceComb Pack is using ES to store the Transaction
> > related
> > > > > > > event[3]. I think we can provide a service to bridge the Trace
> > > > > > > information that Skywalking collects with ServiceComb Pack
> > > > Transaction
> > > > > > > events information.
> > > > > > >
> > > > > > > Any thoughts?
> > > > > > >
> > > > > > > [1]
> > > > >
> > > >
> > >
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/IdGenerator.java
> > > > > > > [2]
> > > > >
> > > >
> > >
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/OmegaContext.java
> > > > > > > [3]
> > > > >
> > https://github.com/apache/servicecomb-pack/tree/master/alpha/alpha-fsm
> > > > > > >
> > > > > > > Willem Jiang
> > > > > > >
> > > > > > > Twitter: willemjiang
> > > > > > > Weibo: 姜宁willem
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Integration of Skywalking agent with ServiceComb Pack.
Posted by Sheng Wu <wu...@gmail.com>.
We have a service comb RPC plugin, provided by you before.
For pack and transaction, we need another plugin.
There are a lot of plugins you could ref, and Seata plugin is WIP too,
https://github.com/apache/skywalking/pulls. Wait for new protocol stable at
Seata side.
Sheng Wu 吴晟
Apache SkyWalking, Apache ShardingSphere(Incubating), Zipkin
Twitter, wusheng1108
Zheng Feng <zh...@gmail.com> 于2019年9月5日周四 上午7:28写道：
> So we have to dev a new plugin for the servicecomb-pack or there is a
> plugin we could leverage with ?
>
> Sheng Wu <wu...@gmail.com> 于2019年9月5日周四 下午10:08写道：
>
> > Then SkyWalking has a toolkit lib[1], you could use
> > `TraceContext.traceId()` in any place, if there is sw agent attached, and
> > current context has been traced, you could have the trace id.
> >
> > [1]
> >
> >
> https://github.com/apache/skywalking/blob/master/docs/en/setup/service-agent/java-agent/Application-toolkit-trace.md
> >
> > Sheng Wu 吴晟
> >
> > Apache SkyWalking, Apache ShardingSphere(Incubating), Zipkin
> > Twitter, wusheng1108
> >
> >
> > Zheng Feng <zh...@gmail.com> 于2019年9月5日周四 上午5:46写道：
> >
> > > Sheng Wu <wu...@gmail.com> 于2019年9月4日周三 上午11:31写道：
> > >
> > > > Willem Jiang <wi...@gmail.com> 于2019年9月3日周二 下午6:25写道：
> > > >
> > > > > On Tue, Sep 3, 2019 at 10:52 PM Zhang Lei <zh...@boco.com.cn>
> > > wrote:
> > > > > >
> > > > > > Hi Willem,
> > > > > >
> > > > > > I agree to integrate a transaction tracking service, I used
> > Zipkin,
> > > > but
> > > > > I don't know much about Skywalking.
> > > > > >
> > > > > > I have some questions:
> > > > > >
> > > > > > 1. Skywalking agent just working on the Omega side?
> > > > > Yep, but we can also let the agent do the instrumentation on the
> > Alpha
> > > > > side.
> > > >
> > > >
> > > > > > 2. Use @Trace in the same location as @SagaStart and
> @Compensable,
> > Or
> > > > > Combined annotation? And use TraceContext.traceId() to generate
> > > > globalTxId
> > > > > or localTxId ?
> > > > > This is the detail thing we need to think about.
> > > > > I think you are just proposing a way to integrate the Zipkin, am I
> > > right?
> > > > >
> > > >
> > > > @Trace is SkyWalking annotation, which SkyWalking agent could
> identify
> > > and
> > > > instrument as a local span(Not RPC related)
> > > >
> > > >
> > > > >
> > > > > > 3. Will Omega users have conflicts if they already use Zipkin?
> > > > > We need to do some end to end verification, currently I think it's
> > > > > fine if we can find a way to generate a correlation id between
> > tracing
> > > > > system and pack, we don't need to deeply combine these two system
> > > > > together, they can work separately.
> > > > >
> > > >
> > > > SkyWalking doesn't conflict with Zipkin, but I don't recommend to use
> > > both
> > > > at the same time, because it is pointless.
> > > >
> > > >
> > > > >
> > > > > > 4. About provides a service to bridge the Trace information that
> > > > > Skywalking collects with ServiceComb Pack Transaction events
> > > information.
> > > > > Do you mean that Alpha sends service chain information directly to
> > > > > Skywalking via API?
> > > > > It's more like a portal integration. We can still leverage the old
> > API
> > > > > provide by Skywalking and ServiceComb Pack.
> > > > >
> > > >
> > > > In this way, we need to have a deeper discussion about what
> ServiceComb
> > > > wants and requires.
> > > >
> > > Basically, I think we need to track the saga transaction status by the
> > > global id.
> > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > > Lei Zhang
> > > > > >
> > > > > > > 在 2019年9月3日，下午7:22，Willem Jiang <wi...@gmail.com> 写道：
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > As ServiceComb Pack use the GlobalTransactionId to trace the
> > > > > > > distributed transactions, it's make sense that let the
> > ServiceComb
> > > > > > > Pack and Skywalking share the same Id for tracing.
> > > > > > > In this way, we can bring the APM feature into Distribution
> > > > > > > Transaction managemet world.
> > > > > > >
> > > > > > > Current ServiceComb has Interface IdGenerator[1], which is used
> > for
> > > > > > > the generate the GlobalTransactionId in OmegaContext[2]. I
> think
> > if
> > > > we
> > > > > > > can reuse the transaction implementation with the Skywalking
> > agent
> > > to
> > > > > > > generate the GlobalTransactionId. In this way we can search the
> > > trace
> > > > > > > information and transactions with same correlation ID.
> > > > > > >
> > > > > > > The missing part is LocalTransactionId, we need to figure a way
> > to
> > > > > > > bring the LocalTransactionId with the trace information.
> > > > > > >
> > > > > > > BTW, ServiceComb Pack is using ES to store the Transaction
> > related
> > > > > > > event[3]. I think we can provide a service to bridge the Trace
> > > > > > > information that Skywalking collects with ServiceComb Pack
> > > > Transaction
> > > > > > > events information.
> > > > > > >
> > > > > > > Any thoughts?
> > > > > > >
> > > > > > > [1]
> > > > >
> > > >
> > >
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/IdGenerator.java
> > > > > > > [2]
> > > > >
> > > >
> > >
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/OmegaContext.java
> > > > > > > [3]
> > > > >
> > https://github.com/apache/servicecomb-pack/tree/master/alpha/alpha-fsm
> > > > > > >
> > > > > > > Willem Jiang
> > > > > > >
> > > > > > > Twitter: willemjiang
> > > > > > > Weibo: 姜宁willem
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Integration of Skywalking agent with ServiceComb Pack.
Posted by Zheng Feng <zh...@gmail.com>.
So we have to dev a new plugin for the servicecomb-pack or there is a
plugin we could leverage with ?
Sheng Wu <wu...@gmail.com> 于2019年9月5日周四 下午10:08写道：
> Then SkyWalking has a toolkit lib[1], you could use
> `TraceContext.traceId()` in any place, if there is sw agent attached, and
> current context has been traced, you could have the trace id.
>
> [1]
>
> https://github.com/apache/skywalking/blob/master/docs/en/setup/service-agent/java-agent/Application-toolkit-trace.md
>
> Sheng Wu 吴晟
>
> Apache SkyWalking, Apache ShardingSphere(Incubating), Zipkin
> Twitter, wusheng1108
>
>
> Zheng Feng <zh...@gmail.com> 于2019年9月5日周四 上午5:46写道：
>
> > Sheng Wu <wu...@gmail.com> 于2019年9月4日周三 上午11:31写道：
> >
> > > Willem Jiang <wi...@gmail.com> 于2019年9月3日周二 下午6:25写道：
> > >
> > > > On Tue, Sep 3, 2019 at 10:52 PM Zhang Lei <zh...@boco.com.cn>
> > wrote:
> > > > >
> > > > > Hi Willem,
> > > > >
> > > > > I agree to integrate a transaction tracking service, I used
> Zipkin,
> > > but
> > > > I don't know much about Skywalking.
> > > > >
> > > > > I have some questions:
> > > > >
> > > > > 1. Skywalking agent just working on the Omega side?
> > > > Yep, but we can also let the agent do the instrumentation on the
> Alpha
> > > > side.
> > >
> > >
> > > > > 2. Use @Trace in the same location as @SagaStart and @Compensable,
> Or
> > > > Combined annotation? And use TraceContext.traceId() to generate
> > > globalTxId
> > > > or localTxId ?
> > > > This is the detail thing we need to think about.
> > > > I think you are just proposing a way to integrate the Zipkin, am I
> > right?
> > > >
> > >
> > > @Trace is SkyWalking annotation, which SkyWalking agent could identify
> > and
> > > instrument as a local span(Not RPC related)
> > >
> > >
> > > >
> > > > > 3. Will Omega users have conflicts if they already use Zipkin?
> > > > We need to do some end to end verification, currently I think it's
> > > > fine if we can find a way to generate a correlation id between
> tracing
> > > > system and pack, we don't need to deeply combine these two system
> > > > together, they can work separately.
> > > >
> > >
> > > SkyWalking doesn't conflict with Zipkin, but I don't recommend to use
> > both
> > > at the same time, because it is pointless.
> > >
> > >
> > > >
> > > > > 4. About provides a service to bridge the Trace information that
> > > > Skywalking collects with ServiceComb Pack Transaction events
> > information.
> > > > Do you mean that Alpha sends service chain information directly to
> > > > Skywalking via API?
> > > > It's more like a portal integration. We can still leverage the old
> API
> > > > provide by Skywalking and ServiceComb Pack.
> > > >
> > >
> > > In this way, we need to have a deeper discussion about what ServiceComb
> > > wants and requires.
> > >
> > Basically, I think we need to track the saga transaction status by the
> > global id.
> >
> > >
> > >
> > > >
> > > >
> > > > >
> > > > > Lei Zhang
> > > > >
> > > > > > 在 2019年9月3日，下午7:22，Willem Jiang <wi...@gmail.com> 写道：
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > As ServiceComb Pack use the GlobalTransactionId to trace the
> > > > > > distributed transactions, it's make sense that let the
> ServiceComb
> > > > > > Pack and Skywalking share the same Id for tracing.
> > > > > > In this way, we can bring the APM feature into Distribution
> > > > > > Transaction managemet world.
> > > > > >
> > > > > > Current ServiceComb has Interface IdGenerator[1], which is used
> for
> > > > > > the generate the GlobalTransactionId in OmegaContext[2]. I think
> if
> > > we
> > > > > > can reuse the transaction implementation with the Skywalking
> agent
> > to
> > > > > > generate the GlobalTransactionId. In this way we can search the
> > trace
> > > > > > information and transactions with same correlation ID.
> > > > > >
> > > > > > The missing part is LocalTransactionId, we need to figure a way
> to
> > > > > > bring the LocalTransactionId with the trace information.
> > > > > >
> > > > > > BTW, ServiceComb Pack is using ES to store the Transaction
> related
> > > > > > event[3]. I think we can provide a service to bridge the Trace
> > > > > > information that Skywalking collects with ServiceComb Pack
> > > Transaction
> > > > > > events information.
> > > > > >
> > > > > > Any thoughts?
> > > > > >
> > > > > > [1]
> > > >
> > >
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/IdGenerator.java
> > > > > > [2]
> > > >
> > >
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/OmegaContext.java
> > > > > > [3]
> > > >
> https://github.com/apache/servicecomb-pack/tree/master/alpha/alpha-fsm
> > > > > >
> > > > > > Willem Jiang
> > > > > >
> > > > > > Twitter: willemjiang
> > > > > > Weibo: 姜宁willem
> > > > >
> > > >
> > >
> >
>
Re: Integration of Skywalking agent with ServiceComb Pack.
Posted by Zheng Feng <zh...@gmail.com>.
So we have to dev a new plugin for the servicecomb-pack or there is a
plugin we could leverage with ?
Sheng Wu <wu...@gmail.com> 于2019年9月5日周四 下午10:08写道：
> Then SkyWalking has a toolkit lib[1], you could use
> `TraceContext.traceId()` in any place, if there is sw agent attached, and
> current context has been traced, you could have the trace id.
>
> [1]
>
> https://github.com/apache/skywalking/blob/master/docs/en/setup/service-agent/java-agent/Application-toolkit-trace.md
>
> Sheng Wu 吴晟
>
> Apache SkyWalking, Apache ShardingSphere(Incubating), Zipkin
> Twitter, wusheng1108
>
>
> Zheng Feng <zh...@gmail.com> 于2019年9月5日周四 上午5:46写道：
>
> > Sheng Wu <wu...@gmail.com> 于2019年9月4日周三 上午11:31写道：
> >
> > > Willem Jiang <wi...@gmail.com> 于2019年9月3日周二 下午6:25写道：
> > >
> > > > On Tue, Sep 3, 2019 at 10:52 PM Zhang Lei <zh...@boco.com.cn>
> > wrote:
> > > > >
> > > > > Hi Willem,
> > > > >
> > > > > I agree to integrate a transaction tracking service, I used
> Zipkin,
> > > but
> > > > I don't know much about Skywalking.
> > > > >
> > > > > I have some questions:
> > > > >
> > > > > 1. Skywalking agent just working on the Omega side?
> > > > Yep, but we can also let the agent do the instrumentation on the
> Alpha
> > > > side.
> > >
> > >
> > > > > 2. Use @Trace in the same location as @SagaStart and @Compensable,
> Or
> > > > Combined annotation? And use TraceContext.traceId() to generate
> > > globalTxId
> > > > or localTxId ?
> > > > This is the detail thing we need to think about.
> > > > I think you are just proposing a way to integrate the Zipkin, am I
> > right?
> > > >
> > >
> > > @Trace is SkyWalking annotation, which SkyWalking agent could identify
> > and
> > > instrument as a local span(Not RPC related)
> > >
> > >
> > > >
> > > > > 3. Will Omega users have conflicts if they already use Zipkin?
> > > > We need to do some end to end verification, currently I think it's
> > > > fine if we can find a way to generate a correlation id between
> tracing
> > > > system and pack, we don't need to deeply combine these two system
> > > > together, they can work separately.
> > > >
> > >
> > > SkyWalking doesn't conflict with Zipkin, but I don't recommend to use
> > both
> > > at the same time, because it is pointless.
> > >
> > >
> > > >
> > > > > 4. About provides a service to bridge the Trace information that
> > > > Skywalking collects with ServiceComb Pack Transaction events
> > information.
> > > > Do you mean that Alpha sends service chain information directly to
> > > > Skywalking via API?
> > > > It's more like a portal integration. We can still leverage the old
> API
> > > > provide by Skywalking and ServiceComb Pack.
> > > >
> > >
> > > In this way, we need to have a deeper discussion about what ServiceComb
> > > wants and requires.
> > >
> > Basically, I think we need to track the saga transaction status by the
> > global id.
> >
> > >
> > >
> > > >
> > > >
> > > > >
> > > > > Lei Zhang
> > > > >
> > > > > > 在 2019年9月3日，下午7:22，Willem Jiang <wi...@gmail.com> 写道：
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > As ServiceComb Pack use the GlobalTransactionId to trace the
> > > > > > distributed transactions, it's make sense that let the
> ServiceComb
> > > > > > Pack and Skywalking share the same Id for tracing.
> > > > > > In this way, we can bring the APM feature into Distribution
> > > > > > Transaction managemet world.
> > > > > >
> > > > > > Current ServiceComb has Interface IdGenerator[1], which is used
> for
> > > > > > the generate the GlobalTransactionId in OmegaContext[2]. I think
> if
> > > we
> > > > > > can reuse the transaction implementation with the Skywalking
> agent
> > to
> > > > > > generate the GlobalTransactionId. In this way we can search the
> > trace
> > > > > > information and transactions with same correlation ID.
> > > > > >
> > > > > > The missing part is LocalTransactionId, we need to figure a way
> to
> > > > > > bring the LocalTransactionId with the trace information.
> > > > > >
> > > > > > BTW, ServiceComb Pack is using ES to store the Transaction
> related
> > > > > > event[3]. I think we can provide a service to bridge the Trace
> > > > > > information that Skywalking collects with ServiceComb Pack
> > > Transaction
> > > > > > events information.
> > > > > >
> > > > > > Any thoughts?
> > > > > >
> > > > > > [1]
> > > >
> > >
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/IdGenerator.java
> > > > > > [2]
> > > >
> > >
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/OmegaContext.java
> > > > > > [3]
> > > >
> https://github.com/apache/servicecomb-pack/tree/master/alpha/alpha-fsm
> > > > > >
> > > > > > Willem Jiang
> > > > > >
> > > > > > Twitter: willemjiang
> > > > > > Weibo: 姜宁willem
> > > > >
> > > >
> > >
> >
>
Re: Integration of Skywalking agent with ServiceComb Pack.
Posted by Zheng Feng <zh...@gmail.com>.
So we have to dev a new plugin for the servicecomb-pack or there is a
plugin we could leverage with ?
Sheng Wu <wu...@gmail.com> 于2019年9月5日周四 下午10:08写道：
> Then SkyWalking has a toolkit lib[1], you could use
> `TraceContext.traceId()` in any place, if there is sw agent attached, and
> current context has been traced, you could have the trace id.
>
> [1]
>
> https://github.com/apache/skywalking/blob/master/docs/en/setup/service-agent/java-agent/Application-toolkit-trace.md
>
> Sheng Wu 吴晟
>
> Apache SkyWalking, Apache ShardingSphere(Incubating), Zipkin
> Twitter, wusheng1108
>
>
> Zheng Feng <zh...@gmail.com> 于2019年9月5日周四 上午5:46写道：
>
> > Sheng Wu <wu...@gmail.com> 于2019年9月4日周三 上午11:31写道：
> >
> > > Willem Jiang <wi...@gmail.com> 于2019年9月3日周二 下午6:25写道：
> > >
> > > > On Tue, Sep 3, 2019 at 10:52 PM Zhang Lei <zh...@boco.com.cn>
> > wrote:
> > > > >
> > > > > Hi Willem,
> > > > >
> > > > > I agree to integrate a transaction tracking service, I used
> Zipkin,
> > > but
> > > > I don't know much about Skywalking.
> > > > >
> > > > > I have some questions:
> > > > >
> > > > > 1. Skywalking agent just working on the Omega side?
> > > > Yep, but we can also let the agent do the instrumentation on the
> Alpha
> > > > side.
> > >
> > >
> > > > > 2. Use @Trace in the same location as @SagaStart and @Compensable,
> Or
> > > > Combined annotation? And use TraceContext.traceId() to generate
> > > globalTxId
> > > > or localTxId ?
> > > > This is the detail thing we need to think about.
> > > > I think you are just proposing a way to integrate the Zipkin, am I
> > right?
> > > >
> > >
> > > @Trace is SkyWalking annotation, which SkyWalking agent could identify
> > and
> > > instrument as a local span(Not RPC related)
> > >
> > >
> > > >
> > > > > 3. Will Omega users have conflicts if they already use Zipkin?
> > > > We need to do some end to end verification, currently I think it's
> > > > fine if we can find a way to generate a correlation id between
> tracing
> > > > system and pack, we don't need to deeply combine these two system
> > > > together, they can work separately.
> > > >
> > >
> > > SkyWalking doesn't conflict with Zipkin, but I don't recommend to use
> > both
> > > at the same time, because it is pointless.
> > >
> > >
> > > >
> > > > > 4. About provides a service to bridge the Trace information that
> > > > Skywalking collects with ServiceComb Pack Transaction events
> > information.
> > > > Do you mean that Alpha sends service chain information directly to
> > > > Skywalking via API?
> > > > It's more like a portal integration. We can still leverage the old
> API
> > > > provide by Skywalking and ServiceComb Pack.
> > > >
> > >
> > > In this way, we need to have a deeper discussion about what ServiceComb
> > > wants and requires.
> > >
> > Basically, I think we need to track the saga transaction status by the
> > global id.
> >
> > >
> > >
> > > >
> > > >
> > > > >
> > > > > Lei Zhang
> > > > >
> > > > > > 在 2019年9月3日，下午7:22，Willem Jiang <wi...@gmail.com> 写道：
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > As ServiceComb Pack use the GlobalTransactionId to trace the
> > > > > > distributed transactions, it's make sense that let the
> ServiceComb
> > > > > > Pack and Skywalking share the same Id for tracing.
> > > > > > In this way, we can bring the APM feature into Distribution
> > > > > > Transaction managemet world.
> > > > > >
> > > > > > Current ServiceComb has Interface IdGenerator[1], which is used
> for
> > > > > > the generate the GlobalTransactionId in OmegaContext[2]. I think
> if
> > > we
> > > > > > can reuse the transaction implementation with the Skywalking
> agent
> > to
> > > > > > generate the GlobalTransactionId. In this way we can search the
> > trace
> > > > > > information and transactions with same correlation ID.
> > > > > >
> > > > > > The missing part is LocalTransactionId, we need to figure a way
> to
> > > > > > bring the LocalTransactionId with the trace information.
> > > > > >
> > > > > > BTW, ServiceComb Pack is using ES to store the Transaction
> related
> > > > > > event[3]. I think we can provide a service to bridge the Trace
> > > > > > information that Skywalking collects with ServiceComb Pack
> > > Transaction
> > > > > > events information.
> > > > > >
> > > > > > Any thoughts?
> > > > > >
> > > > > > [1]
> > > >
> > >
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/IdGenerator.java
> > > > > > [2]
> > > >
> > >
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/OmegaContext.java
> > > > > > [3]
> > > >
> https://github.com/apache/servicecomb-pack/tree/master/alpha/alpha-fsm
> > > > > >
> > > > > > Willem Jiang
> > > > > >
> > > > > > Twitter: willemjiang
> > > > > > Weibo: 姜宁willem
> > > > >
> > > >
> > >
> >
>
Re: Integration of Skywalking agent with ServiceComb Pack.
Posted by Sheng Wu <wu...@gmail.com>.
Then SkyWalking has a toolkit lib[1], you could use
`TraceContext.traceId()` in any place, if there is sw agent attached, and
current context has been traced, you could have the trace id.
[1]
https://github.com/apache/skywalking/blob/master/docs/en/setup/service-agent/java-agent/Application-toolkit-trace.md
Sheng Wu 吴晟
Apache SkyWalking, Apache ShardingSphere(Incubating), Zipkin
Twitter, wusheng1108
Zheng Feng <zh...@gmail.com> 于2019年9月5日周四 上午5:46写道：
> Sheng Wu <wu...@gmail.com> 于2019年9月4日周三 上午11:31写道：
>
> > Willem Jiang <wi...@gmail.com> 于2019年9月3日周二 下午6:25写道：
> >
> > > On Tue, Sep 3, 2019 at 10:52 PM Zhang Lei <zh...@boco.com.cn>
> wrote:
> > > >
> > > > Hi Willem,
> > > >
> > > > I agree to integrate a transaction tracking service, I used Zipkin,
> > but
> > > I don't know much about Skywalking.
> > > >
> > > > I have some questions:
> > > >
> > > > 1. Skywalking agent just working on the Omega side?
> > > Yep, but we can also let the agent do the instrumentation on the Alpha
> > > side.
> >
> >
> > > > 2. Use @Trace in the same location as @SagaStart and @Compensable, Or
> > > Combined annotation? And use TraceContext.traceId() to generate
> > globalTxId
> > > or localTxId ?
> > > This is the detail thing we need to think about.
> > > I think you are just proposing a way to integrate the Zipkin, am I
> right?
> > >
> >
> > @Trace is SkyWalking annotation, which SkyWalking agent could identify
> and
> > instrument as a local span(Not RPC related)
> >
> >
> > >
> > > > 3. Will Omega users have conflicts if they already use Zipkin?
> > > We need to do some end to end verification, currently I think it's
> > > fine if we can find a way to generate a correlation id between tracing
> > > system and pack, we don't need to deeply combine these two system
> > > together, they can work separately.
> > >
> >
> > SkyWalking doesn't conflict with Zipkin, but I don't recommend to use
> both
> > at the same time, because it is pointless.
> >
> >
> > >
> > > > 4. About provides a service to bridge the Trace information that
> > > Skywalking collects with ServiceComb Pack Transaction events
> information.
> > > Do you mean that Alpha sends service chain information directly to
> > > Skywalking via API?
> > > It's more like a portal integration. We can still leverage the old API
> > > provide by Skywalking and ServiceComb Pack.
> > >
> >
> > In this way, we need to have a deeper discussion about what ServiceComb
> > wants and requires.
> >
> Basically, I think we need to track the saga transaction status by the
> global id.
>
> >
> >
> > >
> > >
> > > >
> > > > Lei Zhang
> > > >
> > > > > 在 2019年9月3日，下午7:22，Willem Jiang <wi...@gmail.com> 写道：
> > > > >
> > > > > Hi,
> > > > >
> > > > > As ServiceComb Pack use the GlobalTransactionId to trace the
> > > > > distributed transactions, it's make sense that let the ServiceComb
> > > > > Pack and Skywalking share the same Id for tracing.
> > > > > In this way, we can bring the APM feature into Distribution
> > > > > Transaction managemet world.
> > > > >
> > > > > Current ServiceComb has Interface IdGenerator[1], which is used for
> > > > > the generate the GlobalTransactionId in OmegaContext[2]. I think if
> > we
> > > > > can reuse the transaction implementation with the Skywalking agent
> to
> > > > > generate the GlobalTransactionId. In this way we can search the
> trace
> > > > > information and transactions with same correlation ID.
> > > > >
> > > > > The missing part is LocalTransactionId, we need to figure a way to
> > > > > bring the LocalTransactionId with the trace information.
> > > > >
> > > > > BTW, ServiceComb Pack is using ES to store the Transaction related
> > > > > event[3]. I think we can provide a service to bridge the Trace
> > > > > information that Skywalking collects with ServiceComb Pack
> > Transaction
> > > > > events information.
> > > > >
> > > > > Any thoughts?
> > > > >
> > > > > [1]
> > >
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/IdGenerator.java
> > > > > [2]
> > >
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/OmegaContext.java
> > > > > [3]
> > > https://github.com/apache/servicecomb-pack/tree/master/alpha/alpha-fsm
> > > > >
> > > > > Willem Jiang
> > > > >
> > > > > Twitter: willemjiang
> > > > > Weibo: 姜宁willem
> > > >
> > >
> >
>
Re: Integration of Skywalking agent with ServiceComb Pack.
Posted by Sheng Wu <wu...@gmail.com>.
Then SkyWalking has a toolkit lib[1], you could use
`TraceContext.traceId()` in any place, if there is sw agent attached, and
current context has been traced, you could have the trace id.
[1]
https://github.com/apache/skywalking/blob/master/docs/en/setup/service-agent/java-agent/Application-toolkit-trace.md
Sheng Wu 吴晟
Apache SkyWalking, Apache ShardingSphere(Incubating), Zipkin
Twitter, wusheng1108
Zheng Feng <zh...@gmail.com> 于2019年9月5日周四 上午5:46写道：
> Sheng Wu <wu...@gmail.com> 于2019年9月4日周三 上午11:31写道：
>
> > Willem Jiang <wi...@gmail.com> 于2019年9月3日周二 下午6:25写道：
> >
> > > On Tue, Sep 3, 2019 at 10:52 PM Zhang Lei <zh...@boco.com.cn>
> wrote:
> > > >
> > > > Hi Willem,
> > > >
> > > > I agree to integrate a transaction tracking service, I used Zipkin,
> > but
> > > I don't know much about Skywalking.
> > > >
> > > > I have some questions:
> > > >
> > > > 1. Skywalking agent just working on the Omega side?
> > > Yep, but we can also let the agent do the instrumentation on the Alpha
> > > side.
> >
> >
> > > > 2. Use @Trace in the same location as @SagaStart and @Compensable, Or
> > > Combined annotation? And use TraceContext.traceId() to generate
> > globalTxId
> > > or localTxId ?
> > > This is the detail thing we need to think about.
> > > I think you are just proposing a way to integrate the Zipkin, am I
> right?
> > >
> >
> > @Trace is SkyWalking annotation, which SkyWalking agent could identify
> and
> > instrument as a local span(Not RPC related)
> >
> >
> > >
> > > > 3. Will Omega users have conflicts if they already use Zipkin?
> > > We need to do some end to end verification, currently I think it's
> > > fine if we can find a way to generate a correlation id between tracing
> > > system and pack, we don't need to deeply combine these two system
> > > together, they can work separately.
> > >
> >
> > SkyWalking doesn't conflict with Zipkin, but I don't recommend to use
> both
> > at the same time, because it is pointless.
> >
> >
> > >
> > > > 4. About provides a service to bridge the Trace information that
> > > Skywalking collects with ServiceComb Pack Transaction events
> information.
> > > Do you mean that Alpha sends service chain information directly to
> > > Skywalking via API?
> > > It's more like a portal integration. We can still leverage the old API
> > > provide by Skywalking and ServiceComb Pack.
> > >
> >
> > In this way, we need to have a deeper discussion about what ServiceComb
> > wants and requires.
> >
> Basically, I think we need to track the saga transaction status by the
> global id.
>
> >
> >
> > >
> > >
> > > >
> > > > Lei Zhang
> > > >
> > > > > 在 2019年9月3日，下午7:22，Willem Jiang <wi...@gmail.com> 写道：
> > > > >
> > > > > Hi,
> > > > >
> > > > > As ServiceComb Pack use the GlobalTransactionId to trace the
> > > > > distributed transactions, it's make sense that let the ServiceComb
> > > > > Pack and Skywalking share the same Id for tracing.
> > > > > In this way, we can bring the APM feature into Distribution
> > > > > Transaction managemet world.
> > > > >
> > > > > Current ServiceComb has Interface IdGenerator[1], which is used for
> > > > > the generate the GlobalTransactionId in OmegaContext[2]. I think if
> > we
> > > > > can reuse the transaction implementation with the Skywalking agent
> to
> > > > > generate the GlobalTransactionId. In this way we can search the
> trace
> > > > > information and transactions with same correlation ID.
> > > > >
> > > > > The missing part is LocalTransactionId, we need to figure a way to
> > > > > bring the LocalTransactionId with the trace information.
> > > > >
> > > > > BTW, ServiceComb Pack is using ES to store the Transaction related
> > > > > event[3]. I think we can provide a service to bridge the Trace
> > > > > information that Skywalking collects with ServiceComb Pack
> > Transaction
> > > > > events information.
> > > > >
> > > > > Any thoughts?
> > > > >
> > > > > [1]
> > >
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/IdGenerator.java
> > > > > [2]
> > >
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/OmegaContext.java
> > > > > [3]
> > > https://github.com/apache/servicecomb-pack/tree/master/alpha/alpha-fsm
> > > > >
> > > > > Willem Jiang
> > > > >
> > > > > Twitter: willemjiang
> > > > > Weibo: 姜宁willem
> > > >
> > >
> >
>
Re: Integration of Skywalking agent with ServiceComb Pack.
Posted by Sheng Wu <wu...@gmail.com>.
Then SkyWalking has a toolkit lib[1], you could use
`TraceContext.traceId()` in any place, if there is sw agent attached, and
current context has been traced, you could have the trace id.
[1]
https://github.com/apache/skywalking/blob/master/docs/en/setup/service-agent/java-agent/Application-toolkit-trace.md
Sheng Wu 吴晟
Apache SkyWalking, Apache ShardingSphere(Incubating), Zipkin
Twitter, wusheng1108
Zheng Feng <zh...@gmail.com> 于2019年9月5日周四 上午5:46写道：
> Sheng Wu <wu...@gmail.com> 于2019年9月4日周三 上午11:31写道：
>
> > Willem Jiang <wi...@gmail.com> 于2019年9月3日周二 下午6:25写道：
> >
> > > On Tue, Sep 3, 2019 at 10:52 PM Zhang Lei <zh...@boco.com.cn>
> wrote:
> > > >
> > > > Hi Willem,
> > > >
> > > > I agree to integrate a transaction tracking service, I used Zipkin,
> > but
> > > I don't know much about Skywalking.
> > > >
> > > > I have some questions:
> > > >
> > > > 1. Skywalking agent just working on the Omega side?
> > > Yep, but we can also let the agent do the instrumentation on the Alpha
> > > side.
> >
> >
> > > > 2. Use @Trace in the same location as @SagaStart and @Compensable, Or
> > > Combined annotation? And use TraceContext.traceId() to generate
> > globalTxId
> > > or localTxId ?
> > > This is the detail thing we need to think about.
> > > I think you are just proposing a way to integrate the Zipkin, am I
> right?
> > >
> >
> > @Trace is SkyWalking annotation, which SkyWalking agent could identify
> and
> > instrument as a local span(Not RPC related)
> >
> >
> > >
> > > > 3. Will Omega users have conflicts if they already use Zipkin?
> > > We need to do some end to end verification, currently I think it's
> > > fine if we can find a way to generate a correlation id between tracing
> > > system and pack, we don't need to deeply combine these two system
> > > together, they can work separately.
> > >
> >
> > SkyWalking doesn't conflict with Zipkin, but I don't recommend to use
> both
> > at the same time, because it is pointless.
> >
> >
> > >
> > > > 4. About provides a service to bridge the Trace information that
> > > Skywalking collects with ServiceComb Pack Transaction events
> information.
> > > Do you mean that Alpha sends service chain information directly to
> > > Skywalking via API?
> > > It's more like a portal integration. We can still leverage the old API
> > > provide by Skywalking and ServiceComb Pack.
> > >
> >
> > In this way, we need to have a deeper discussion about what ServiceComb
> > wants and requires.
> >
> Basically, I think we need to track the saga transaction status by the
> global id.
>
> >
> >
> > >
> > >
> > > >
> > > > Lei Zhang
> > > >
> > > > > 在 2019年9月3日，下午7:22，Willem Jiang <wi...@gmail.com> 写道：
> > > > >
> > > > > Hi,
> > > > >
> > > > > As ServiceComb Pack use the GlobalTransactionId to trace the
> > > > > distributed transactions, it's make sense that let the ServiceComb
> > > > > Pack and Skywalking share the same Id for tracing.
> > > > > In this way, we can bring the APM feature into Distribution
> > > > > Transaction managemet world.
> > > > >
> > > > > Current ServiceComb has Interface IdGenerator[1], which is used for
> > > > > the generate the GlobalTransactionId in OmegaContext[2]. I think if
> > we
> > > > > can reuse the transaction implementation with the Skywalking agent
> to
> > > > > generate the GlobalTransactionId. In this way we can search the
> trace
> > > > > information and transactions with same correlation ID.
> > > > >
> > > > > The missing part is LocalTransactionId, we need to figure a way to
> > > > > bring the LocalTransactionId with the trace information.
> > > > >
> > > > > BTW, ServiceComb Pack is using ES to store the Transaction related
> > > > > event[3]. I think we can provide a service to bridge the Trace
> > > > > information that Skywalking collects with ServiceComb Pack
> > Transaction
> > > > > events information.
> > > > >
> > > > > Any thoughts?
> > > > >
> > > > > [1]
> > >
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/IdGenerator.java
> > > > > [2]
> > >
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/OmegaContext.java
> > > > > [3]
> > > https://github.com/apache/servicecomb-pack/tree/master/alpha/alpha-fsm
> > > > >
> > > > > Willem Jiang
> > > > >
> > > > > Twitter: willemjiang
> > > > > Weibo: 姜宁willem
> > > >
> > >
> >
>
Re: Integration of Skywalking agent with ServiceComb Pack.
Posted by Zheng Feng <zh...@gmail.com>.
Sheng Wu <wu...@gmail.com> 于2019年9月4日周三 上午11:31写道：
> Willem Jiang <wi...@gmail.com> 于2019年9月3日周二 下午6:25写道：
>
> > On Tue, Sep 3, 2019 at 10:52 PM Zhang Lei <zh...@boco.com.cn> wrote:
> > >
> > > Hi Willem,
> > >
> > > I agree to integrate a transaction tracking service, I used Zipkin,
> but
> > I don't know much about Skywalking.
> > >
> > > I have some questions:
> > >
> > > 1. Skywalking agent just working on the Omega side?
> > Yep, but we can also let the agent do the instrumentation on the Alpha
> > side.
>
>
> > > 2. Use @Trace in the same location as @SagaStart and @Compensable, Or
> > Combined annotation? And use TraceContext.traceId() to generate
> globalTxId
> > or localTxId ?
> > This is the detail thing we need to think about.
> > I think you are just proposing a way to integrate the Zipkin, am I right?
> >
>
> @Trace is SkyWalking annotation, which SkyWalking agent could identify and
> instrument as a local span(Not RPC related)
>
>
> >
> > > 3. Will Omega users have conflicts if they already use Zipkin?
> > We need to do some end to end verification, currently I think it's
> > fine if we can find a way to generate a correlation id between tracing
> > system and pack, we don't need to deeply combine these two system
> > together, they can work separately.
> >
>
> SkyWalking doesn't conflict with Zipkin, but I don't recommend to use both
> at the same time, because it is pointless.
>
>
> >
> > > 4. About provides a service to bridge the Trace information that
> > Skywalking collects with ServiceComb Pack Transaction events information.
> > Do you mean that Alpha sends service chain information directly to
> > Skywalking via API?
> > It's more like a portal integration. We can still leverage the old API
> > provide by Skywalking and ServiceComb Pack.
> >
>
> In this way, we need to have a deeper discussion about what ServiceComb
> wants and requires.
>
Basically, I think we need to track the saga transaction status by the
global id.
>
>
> >
> >
> > >
> > > Lei Zhang
> > >
> > > > 在 2019年9月3日，下午7:22，Willem Jiang <wi...@gmail.com> 写道：
> > > >
> > > > Hi,
> > > >
> > > > As ServiceComb Pack use the GlobalTransactionId to trace the
> > > > distributed transactions, it's make sense that let the ServiceComb
> > > > Pack and Skywalking share the same Id for tracing.
> > > > In this way, we can bring the APM feature into Distribution
> > > > Transaction managemet world.
> > > >
> > > > Current ServiceComb has Interface IdGenerator[1], which is used for
> > > > the generate the GlobalTransactionId in OmegaContext[2]. I think if
> we
> > > > can reuse the transaction implementation with the Skywalking agent to
> > > > generate the GlobalTransactionId. In this way we can search the trace
> > > > information and transactions with same correlation ID.
> > > >
> > > > The missing part is LocalTransactionId, we need to figure a way to
> > > > bring the LocalTransactionId with the trace information.
> > > >
> > > > BTW, ServiceComb Pack is using ES to store the Transaction related
> > > > event[3]. I think we can provide a service to bridge the Trace
> > > > information that Skywalking collects with ServiceComb Pack
> Transaction
> > > > events information.
> > > >
> > > > Any thoughts?
> > > >
> > > > [1]
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/IdGenerator.java
> > > > [2]
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/OmegaContext.java
> > > > [3]
> > https://github.com/apache/servicecomb-pack/tree/master/alpha/alpha-fsm
> > > >
> > > > Willem Jiang
> > > >
> > > > Twitter: willemjiang
> > > > Weibo: 姜宁willem
> > >
> >
>
Re: Integration of Skywalking agent with ServiceComb Pack.
Posted by Zheng Feng <zh...@gmail.com>.
Sheng Wu <wu...@gmail.com> 于2019年9月4日周三 上午11:31写道：
> Willem Jiang <wi...@gmail.com> 于2019年9月3日周二 下午6:25写道：
>
> > On Tue, Sep 3, 2019 at 10:52 PM Zhang Lei <zh...@boco.com.cn> wrote:
> > >
> > > Hi Willem,
> > >
> > > I agree to integrate a transaction tracking service, I used Zipkin,
> but
> > I don't know much about Skywalking.
> > >
> > > I have some questions:
> > >
> > > 1. Skywalking agent just working on the Omega side?
> > Yep, but we can also let the agent do the instrumentation on the Alpha
> > side.
>
>
> > > 2. Use @Trace in the same location as @SagaStart and @Compensable, Or
> > Combined annotation? And use TraceContext.traceId() to generate
> globalTxId
> > or localTxId ?
> > This is the detail thing we need to think about.
> > I think you are just proposing a way to integrate the Zipkin, am I right?
> >
>
> @Trace is SkyWalking annotation, which SkyWalking agent could identify and
> instrument as a local span(Not RPC related)
>
>
> >
> > > 3. Will Omega users have conflicts if they already use Zipkin?
> > We need to do some end to end verification, currently I think it's
> > fine if we can find a way to generate a correlation id between tracing
> > system and pack, we don't need to deeply combine these two system
> > together, they can work separately.
> >
>
> SkyWalking doesn't conflict with Zipkin, but I don't recommend to use both
> at the same time, because it is pointless.
>
>
> >
> > > 4. About provides a service to bridge the Trace information that
> > Skywalking collects with ServiceComb Pack Transaction events information.
> > Do you mean that Alpha sends service chain information directly to
> > Skywalking via API?
> > It's more like a portal integration. We can still leverage the old API
> > provide by Skywalking and ServiceComb Pack.
> >
>
> In this way, we need to have a deeper discussion about what ServiceComb
> wants and requires.
>
Basically, I think we need to track the saga transaction status by the
global id.
>
>
> >
> >
> > >
> > > Lei Zhang
> > >
> > > > 在 2019年9月3日，下午7:22，Willem Jiang <wi...@gmail.com> 写道：
> > > >
> > > > Hi,
> > > >
> > > > As ServiceComb Pack use the GlobalTransactionId to trace the
> > > > distributed transactions, it's make sense that let the ServiceComb
> > > > Pack and Skywalking share the same Id for tracing.
> > > > In this way, we can bring the APM feature into Distribution
> > > > Transaction managemet world.
> > > >
> > > > Current ServiceComb has Interface IdGenerator[1], which is used for
> > > > the generate the GlobalTransactionId in OmegaContext[2]. I think if
> we
> > > > can reuse the transaction implementation with the Skywalking agent to
> > > > generate the GlobalTransactionId. In this way we can search the trace
> > > > information and transactions with same correlation ID.
> > > >
> > > > The missing part is LocalTransactionId, we need to figure a way to
> > > > bring the LocalTransactionId with the trace information.
> > > >
> > > > BTW, ServiceComb Pack is using ES to store the Transaction related
> > > > event[3]. I think we can provide a service to bridge the Trace
> > > > information that Skywalking collects with ServiceComb Pack
> Transaction
> > > > events information.
> > > >
> > > > Any thoughts?
> > > >
> > > > [1]
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/IdGenerator.java
> > > > [2]
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/OmegaContext.java
> > > > [3]
> > https://github.com/apache/servicecomb-pack/tree/master/alpha/alpha-fsm
> > > >
> > > > Willem Jiang
> > > >
> > > > Twitter: willemjiang
> > > > Weibo: 姜宁willem
> > >
> >
>
Re: Integration of Skywalking agent with ServiceComb Pack.
Posted by Zheng Feng <zh...@gmail.com>.
Sheng Wu <wu...@gmail.com> 于2019年9月4日周三 上午11:31写道：
> Willem Jiang <wi...@gmail.com> 于2019年9月3日周二 下午6:25写道：
>
> > On Tue, Sep 3, 2019 at 10:52 PM Zhang Lei <zh...@boco.com.cn> wrote:
> > >
> > > Hi Willem,
> > >
> > > I agree to integrate a transaction tracking service, I used Zipkin,
> but
> > I don't know much about Skywalking.
> > >
> > > I have some questions:
> > >
> > > 1. Skywalking agent just working on the Omega side?
> > Yep, but we can also let the agent do the instrumentation on the Alpha
> > side.
>
>
> > > 2. Use @Trace in the same location as @SagaStart and @Compensable, Or
> > Combined annotation? And use TraceContext.traceId() to generate
> globalTxId
> > or localTxId ?
> > This is the detail thing we need to think about.
> > I think you are just proposing a way to integrate the Zipkin, am I right?
> >
>
> @Trace is SkyWalking annotation, which SkyWalking agent could identify and
> instrument as a local span(Not RPC related)
>
>
> >
> > > 3. Will Omega users have conflicts if they already use Zipkin?
> > We need to do some end to end verification, currently I think it's
> > fine if we can find a way to generate a correlation id between tracing
> > system and pack, we don't need to deeply combine these two system
> > together, they can work separately.
> >
>
> SkyWalking doesn't conflict with Zipkin, but I don't recommend to use both
> at the same time, because it is pointless.
>
>
> >
> > > 4. About provides a service to bridge the Trace information that
> > Skywalking collects with ServiceComb Pack Transaction events information.
> > Do you mean that Alpha sends service chain information directly to
> > Skywalking via API?
> > It's more like a portal integration. We can still leverage the old API
> > provide by Skywalking and ServiceComb Pack.
> >
>
> In this way, we need to have a deeper discussion about what ServiceComb
> wants and requires.
>
Basically, I think we need to track the saga transaction status by the
global id.
>
>
> >
> >
> > >
> > > Lei Zhang
> > >
> > > > 在 2019年9月3日，下午7:22，Willem Jiang <wi...@gmail.com> 写道：
> > > >
> > > > Hi,
> > > >
> > > > As ServiceComb Pack use the GlobalTransactionId to trace the
> > > > distributed transactions, it's make sense that let the ServiceComb
> > > > Pack and Skywalking share the same Id for tracing.
> > > > In this way, we can bring the APM feature into Distribution
> > > > Transaction managemet world.
> > > >
> > > > Current ServiceComb has Interface IdGenerator[1], which is used for
> > > > the generate the GlobalTransactionId in OmegaContext[2]. I think if
> we
> > > > can reuse the transaction implementation with the Skywalking agent to
> > > > generate the GlobalTransactionId. In this way we can search the trace
> > > > information and transactions with same correlation ID.
> > > >
> > > > The missing part is LocalTransactionId, we need to figure a way to
> > > > bring the LocalTransactionId with the trace information.
> > > >
> > > > BTW, ServiceComb Pack is using ES to store the Transaction related
> > > > event[3]. I think we can provide a service to bridge the Trace
> > > > information that Skywalking collects with ServiceComb Pack
> Transaction
> > > > events information.
> > > >
> > > > Any thoughts?
> > > >
> > > > [1]
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/IdGenerator.java
> > > > [2]
> >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/OmegaContext.java
> > > > [3]
> > https://github.com/apache/servicecomb-pack/tree/master/alpha/alpha-fsm
> > > >
> > > > Willem Jiang
> > > >
> > > > Twitter: willemjiang
> > > > Weibo: 姜宁willem
> > >
> >
>
Re: Integration of Skywalking agent with ServiceComb Pack.
Posted by Sheng Wu <wu...@gmail.com>.
Willem Jiang <wi...@gmail.com> 于2019年9月3日周二 下午6:25写道：
> On Tue, Sep 3, 2019 at 10:52 PM Zhang Lei <zh...@boco.com.cn> wrote:
> >
> > Hi Willem,
> >
> > I agree to integrate a transaction tracking service, I used Zipkin, but
> I don't know much about Skywalking.
> >
> > I have some questions:
> >
> > 1. Skywalking agent just working on the Omega side?
> Yep, but we can also let the agent do the instrumentation on the Alpha
> side.
> > 2. Use @Trace in the same location as @SagaStart and @Compensable, Or
> Combined annotation? And use TraceContext.traceId() to generate globalTxId
> or localTxId ?
> This is the detail thing we need to think about.
> I think you are just proposing a way to integrate the Zipkin, am I right?
>
@Trace is SkyWalking annotation, which SkyWalking agent could identify and
instrument as a local span(Not RPC related)
>
> > 3. Will Omega users have conflicts if they already use Zipkin?
> We need to do some end to end verification, currently I think it's
> fine if we can find a way to generate a correlation id between tracing
> system and pack, we don't need to deeply combine these two system
> together, they can work separately.
>
SkyWalking doesn't conflict with Zipkin, but I don't recommend to use both
at the same time, because it is pointless.
>
> > 4. About provides a service to bridge the Trace information that
> Skywalking collects with ServiceComb Pack Transaction events information.
> Do you mean that Alpha sends service chain information directly to
> Skywalking via API?
> It's more like a portal integration. We can still leverage the old API
> provide by Skywalking and ServiceComb Pack.
>
In this way, we need to have a deeper discussion about what ServiceComb
wants and requires.
>
>
> >
> > Lei Zhang
> >
> > > 在 2019年9月3日，下午7:22，Willem Jiang <wi...@gmail.com> 写道：
> > >
> > > Hi,
> > >
> > > As ServiceComb Pack use the GlobalTransactionId to trace the
> > > distributed transactions, it's make sense that let the ServiceComb
> > > Pack and Skywalking share the same Id for tracing.
> > > In this way, we can bring the APM feature into Distribution
> > > Transaction managemet world.
> > >
> > > Current ServiceComb has Interface IdGenerator[1], which is used for
> > > the generate the GlobalTransactionId in OmegaContext[2]. I think if we
> > > can reuse the transaction implementation with the Skywalking agent to
> > > generate the GlobalTransactionId. In this way we can search the trace
> > > information and transactions with same correlation ID.
> > >
> > > The missing part is LocalTransactionId, we need to figure a way to
> > > bring the LocalTransactionId with the trace information.
> > >
> > > BTW, ServiceComb Pack is using ES to store the Transaction related
> > > event[3]. I think we can provide a service to bridge the Trace
> > > information that Skywalking collects with ServiceComb Pack Transaction
> > > events information.
> > >
> > > Any thoughts?
> > >
> > > [1]
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/IdGenerator.java
> > > [2]
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/OmegaContext.java
> > > [3]
> https://github.com/apache/servicecomb-pack/tree/master/alpha/alpha-fsm
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> >
>
Re: Integration of Skywalking agent with ServiceComb Pack.
Posted by Sheng Wu <wu...@gmail.com>.
Willem Jiang <wi...@gmail.com> 于2019年9月3日周二 下午6:25写道：
> On Tue, Sep 3, 2019 at 10:52 PM Zhang Lei <zh...@boco.com.cn> wrote:
> >
> > Hi Willem,
> >
> > I agree to integrate a transaction tracking service, I used Zipkin, but
> I don't know much about Skywalking.
> >
> > I have some questions:
> >
> > 1. Skywalking agent just working on the Omega side?
> Yep, but we can also let the agent do the instrumentation on the Alpha
> side.
> > 2. Use @Trace in the same location as @SagaStart and @Compensable, Or
> Combined annotation? And use TraceContext.traceId() to generate globalTxId
> or localTxId ?
> This is the detail thing we need to think about.
> I think you are just proposing a way to integrate the Zipkin, am I right?
>
@Trace is SkyWalking annotation, which SkyWalking agent could identify and
instrument as a local span(Not RPC related)
>
> > 3. Will Omega users have conflicts if they already use Zipkin?
> We need to do some end to end verification, currently I think it's
> fine if we can find a way to generate a correlation id between tracing
> system and pack, we don't need to deeply combine these two system
> together, they can work separately.
>
SkyWalking doesn't conflict with Zipkin, but I don't recommend to use both
at the same time, because it is pointless.
>
> > 4. About provides a service to bridge the Trace information that
> Skywalking collects with ServiceComb Pack Transaction events information.
> Do you mean that Alpha sends service chain information directly to
> Skywalking via API?
> It's more like a portal integration. We can still leverage the old API
> provide by Skywalking and ServiceComb Pack.
>
In this way, we need to have a deeper discussion about what ServiceComb
wants and requires.
>
>
> >
> > Lei Zhang
> >
> > > 在 2019年9月3日，下午7:22，Willem Jiang <wi...@gmail.com> 写道：
> > >
> > > Hi,
> > >
> > > As ServiceComb Pack use the GlobalTransactionId to trace the
> > > distributed transactions, it's make sense that let the ServiceComb
> > > Pack and Skywalking share the same Id for tracing.
> > > In this way, we can bring the APM feature into Distribution
> > > Transaction managemet world.
> > >
> > > Current ServiceComb has Interface IdGenerator[1], which is used for
> > > the generate the GlobalTransactionId in OmegaContext[2]. I think if we
> > > can reuse the transaction implementation with the Skywalking agent to
> > > generate the GlobalTransactionId. In this way we can search the trace
> > > information and transactions with same correlation ID.
> > >
> > > The missing part is LocalTransactionId, we need to figure a way to
> > > bring the LocalTransactionId with the trace information.
> > >
> > > BTW, ServiceComb Pack is using ES to store the Transaction related
> > > event[3]. I think we can provide a service to bridge the Trace
> > > information that Skywalking collects with ServiceComb Pack Transaction
> > > events information.
> > >
> > > Any thoughts?
> > >
> > > [1]
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/IdGenerator.java
> > > [2]
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/OmegaContext.java
> > > [3]
> https://github.com/apache/servicecomb-pack/tree/master/alpha/alpha-fsm
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> >
>
Re: Integration of Skywalking agent with ServiceComb Pack.
Posted by Sheng Wu <wu...@gmail.com>.
Willem Jiang <wi...@gmail.com> 于2019年9月3日周二 下午6:25写道：
> On Tue, Sep 3, 2019 at 10:52 PM Zhang Lei <zh...@boco.com.cn> wrote:
> >
> > Hi Willem,
> >
> > I agree to integrate a transaction tracking service, I used Zipkin, but
> I don't know much about Skywalking.
> >
> > I have some questions:
> >
> > 1. Skywalking agent just working on the Omega side?
> Yep, but we can also let the agent do the instrumentation on the Alpha
> side.
> > 2. Use @Trace in the same location as @SagaStart and @Compensable, Or
> Combined annotation? And use TraceContext.traceId() to generate globalTxId
> or localTxId ?
> This is the detail thing we need to think about.
> I think you are just proposing a way to integrate the Zipkin, am I right?
>
@Trace is SkyWalking annotation, which SkyWalking agent could identify and
instrument as a local span(Not RPC related)
>
> > 3. Will Omega users have conflicts if they already use Zipkin?
> We need to do some end to end verification, currently I think it's
> fine if we can find a way to generate a correlation id between tracing
> system and pack, we don't need to deeply combine these two system
> together, they can work separately.
>
SkyWalking doesn't conflict with Zipkin, but I don't recommend to use both
at the same time, because it is pointless.
>
> > 4. About provides a service to bridge the Trace information that
> Skywalking collects with ServiceComb Pack Transaction events information.
> Do you mean that Alpha sends service chain information directly to
> Skywalking via API?
> It's more like a portal integration. We can still leverage the old API
> provide by Skywalking and ServiceComb Pack.
>
In this way, we need to have a deeper discussion about what ServiceComb
wants and requires.
>
>
> >
> > Lei Zhang
> >
> > > 在 2019年9月3日，下午7:22，Willem Jiang <wi...@gmail.com> 写道：
> > >
> > > Hi,
> > >
> > > As ServiceComb Pack use the GlobalTransactionId to trace the
> > > distributed transactions, it's make sense that let the ServiceComb
> > > Pack and Skywalking share the same Id for tracing.
> > > In this way, we can bring the APM feature into Distribution
> > > Transaction managemet world.
> > >
> > > Current ServiceComb has Interface IdGenerator[1], which is used for
> > > the generate the GlobalTransactionId in OmegaContext[2]. I think if we
> > > can reuse the transaction implementation with the Skywalking agent to
> > > generate the GlobalTransactionId. In this way we can search the trace
> > > information and transactions with same correlation ID.
> > >
> > > The missing part is LocalTransactionId, we need to figure a way to
> > > bring the LocalTransactionId with the trace information.
> > >
> > > BTW, ServiceComb Pack is using ES to store the Transaction related
> > > event[3]. I think we can provide a service to bridge the Trace
> > > information that Skywalking collects with ServiceComb Pack Transaction
> > > events information.
> > >
> > > Any thoughts?
> > >
> > > [1]
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/IdGenerator.java
> > > [2]
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/OmegaContext.java
> > > [3]
> https://github.com/apache/servicecomb-pack/tree/master/alpha/alpha-fsm
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> >
>