有没有办法从父活动(System.Diagnostics)获取所有子活动对象?
使用 System.Diagnostics.Activity,并给出以下 C# 代码:
Activity parentActivity = Activity.Current;
有没有办法获取以 parentActivity
作为其 Activity
的所有 Activity
对象代码>父级?或者其他一些方法来获取当前操作中包含的 Activity 对象的“树”?
Using System.Diagnostics.Activity
, and given the following C# code:
Activity parentActivity = Activity.Current;
Is there a way to get all Activity
objects which have parentActivity
as their Parent
? Or some other way to get the "tree" of Activity
objects that are contained within the current operation?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
恐怕这样不行。
例如,考虑 .NET 中的分布式跟踪,即 构建在 Activity API 之上。微服务架构通常需要分布式跟踪,其中服务彼此之间的了解并不多。到处都有请求,服务所能做的最好的事情就是将一些元数据从传入请求传递到传出请求(并添加一些元数据)。
这些元数据是此类活动 ID 可以到达的地方,但服务只知道它想要将请求发送到哪里(带有这些元数据),而不知道它实际到达的位置。因此,服务无法知道哪些活动最终将其活动 ID 作为父活动 ID。
只是您可以将您拥有的不同服务“加载”到某些分布式跟踪工具(例如 Jaeger),一旦请求完成并且知道什么结束在哪里,它将构建您想要的所有美丽的树。但你不能在跨服务请求中执行此操作 - 你不知道未来:)
I'm afraid it doesn't work this way.
For example, think of distributed tracing in .NET, which is built on top of the Activity API. Distributed tracing is often required for microservice architecture where the services don't really know much about each other. There are requests here and there and the best that services can do is to pass some metadata from the incoming request to the outgoing request (and add some).
These metadata is where such Activity IDs can go but then a service only knows where it wants to send the request (with these metadata) and not where it actually arrives. So a service can't know which Activities will eventually have its Activity ID as a parent Activity ID.
It's just that you can "onboard" different services you own to some Distributed Tracing tooling (like Jaeger) which will build all those beautiful trees you want once the requests are completed and it's known what ended where. But you can't do this in the middle of a cross-service request - you don't know the future :)