OpenTelemetry OpenTracing OpenCensus 信息收集和数据采集

小渣渣

OpenTracing

OpenTracing

https://opentracing.io/

OpenTracing制定了一套平台无关、厂商无关的Trace协议，使得开发人员能够方便的添加或更换分布式追踪系统的实现。在2016年11月的时候CNCF技术委员会投票接受OpenTracing作为Hosted项目，这是CNCF的第三个项目，第一个是Kubernetes，第二个是Prometheus，可见CNCF对OpenTracing背后可观察性的重视。比如大名鼎鼎的Zipkin、Jaeger都遵循OpenTracing协议。

OpenCensus

OpenCensus

https://opencensus.io/

大家可能会想，既然有了OpenTracing，OpenCensus又来凑什么热闹？对不起，你要知道OpenCensus的发起者可是谷歌，也就是最早提出Tracing概念的公司，而OpenCensus也就是Google Dapper的社区版。OpenCensus和OpenTracing最大的不同在于除了Tracing外，它还把Metrics也包括进来，这样也可以在OpenCensus上做基础的指标监控；还一点不同是OpenCensus并不是单纯的规范制定，他还把包括数据采集的Agent、Collector一股脑都搞了。OpenCensus也有众多的追随者，最近最大的新闻就是微软也宣布加入，OpenCensus可谓是如虎添翼。

什么是OpenTelemetry？



https://opentelemetry.io/

OpenTelemetry合并了OpenTracing和OpenCensus项目，提供了一组API和库来标准化遥测数据的采集和传输。OpenTelemetry提供了一个安全，厂商中立的工具，这样就可以按照需要将数据发往不同的后端。

OpenTelemetry项目由如下组件构成：

• 推动在所有项目中使用一致的规范
• 基于规范的，包含接口和实现的APIs
• 不同语言的SDK(APIs的实现)，如 Java, Python, Go, Erlang等
• Exporters：可以将数据发往一个选择的后端
• Collectors：厂商中立的实现，用于处理和导出遥测数据
  

Opentelemetry 术语：

Traces：记录经过分布式系统的请求活动，一个trace是spans的有向无环图

Spans：一个trace中表示一个命名的，基于时间的操作。Spans嵌套形成trace树。每个trace包含一个根span，描述了端到端的延迟，其子操作也可能拥有一个或多个子spans。

Metrics：在运行时捕获的关于服务的原始度量数据。Opentelemetry定义的metric instruments。Observer支持通过异步API来采集数据，每个采集间隔采集一个数据。

Context：一个span包含一个span context，它是一个全局唯一的标识，表示每个span所属的唯一的请求，以及跨服务边界转移trace信息所需的数据。OpenTelemetry 也支持correlation context，它可以包含用户定义的属性。correlation context不是必要的，组件可以选择不携带和存储该信息。

Context propagation：表示在不同的服务之间传递上下文信息，通常通过HTTP首部。 Context propagation是Opentelemetry系统的关键功能之一。除了tracing之外，还有一些有趣的用法，如，执行A/B测试。OpenTelemetry支持通过多个协议的Context propagation来避免可能发生的问题，但需要注意的是，在自己的应用中最好使用单一的方法。

OpenTelemetry的好处

通过将OpenTracing 和OpenCensus 合并为一个开放的标准，OpenTelemetry提供了如下便利：

选择简单：不必在两个标准之间进行选择，OpenTelemetry可以同时兼容 OpenTracing和OpenCensus。
跨平台：OpenTelemetry 支持各种语言和后端。它代表了一种厂商中立的方式，可以在不改变现有工具的情况下捕获并将遥测数据传输到后端。
简化可观测性：正如OpenTelemetry所说的"高质量的观测下要求高质量的遥测"。希望看到更多的厂商转向OpenTelemetry，因为它更方便，且仅需测试单一标准。