我很好奇如何为来自发布者的消息提供分布式跟踪，以及订阅者部分如何接收该消息，以便有可能跟踪消息发送(发布者)和消息接收(订阅者)发生错误时可能发生的情况。
我看到了这个PR，它似乎在追求这个，因为它也在这篇文章中解释了PR的作者拥有的东西。但是，对于gcp python客户端pub-sub
来说，用于跟踪pub-sub消息流的开放遥测支持似乎还不存在。我想提到这个前言，只是想问以下问题:
另一方面，我在OTEL收集器项目中看到了Google Cloud Pub Sub出口商和Google Cloud Pub Sub Receiver模块，这与上面提到的PR的目的有什么不同?
我猜在收集器的角度下，这些模块是从应用程序的角度向发布子主题(导出者)发送跟踪(已经在OTEL收集器中)，并从订阅(接收方)获取OTEL消息，但不跟踪发布者发送和订阅者接收的消息?
我想更好地理解关于向发布子主题发送跟踪或从订阅接收OTEL消息以及从发布者生成跟踪以查看这些消息的行为直到它们到达订阅者的想法
我猜在收集器角度下，这些模块是从应用程序角度向发布子主题(导出器)发送跟踪(已经在OTEL收集器中)，并从订阅(接收方)获取OTEL消息，但不跟踪发布者发送和订阅者接收的消息?
对，这是正确的理解。
我想更好地理解关于向发布子主题发送跟踪或从订阅接收OTEL消息以及从发布者生成跟踪以查看这些消息的行为直到它们到达订阅者的想法
我不清楚。您的意思是问如何跟踪发送/接收到公共订阅主题的消息，还是想知道如何向主题发送跟踪?
根据你之前的描述，我猜你想知道前者。这与如何在其他消息/队列系统(如芹菜、Kafka等)中获得e22可见性有点相关。这是通过在入口/出口点创建跨度并通过消息头或类似的东西传播上下文来实现的。要么库本身支持OpenTelemetry(例如，google pub-sub正在尝试做的事情)，要么OpenTelemetry提供了一个工具库来实现这一目标。插装通常包装原始库API方法，并通过拦截原始调用来生成跟踪。您可以在这里查看可用工具的当前列表https://github.com/open-telemetry/opentelemetry-python-contrib/tree/main/instrumentation。这也会给你一个如何写一篇文章的想法。我不确定这是否回答了你的问题，但我希望它能给你一些总体的想法。