本文主要讲解“open遥测的相关知识点有哪些”，感兴趣的朋友不妨看看。本文介绍的方法简单、快速、实用。让边肖带你学习“open遥测的相关知识点有哪些”！
010-
前世
OpenTracing
OpenTracing开发了一套独立于平台和独立于供应商的Trace协议，使开发人员能够轻松添加或替换分布式跟踪系统的实现。2016年11月，CNCF技术委员会投票接受开放跟踪作为托管项目，这是CNCF的第三个项目。第一个是库本内斯，第二个是普罗米修斯，说明CNCF非常重视开放跟踪背后的可观测性。例如，著名的齐普金和耶格都遵循开放追踪协议。
OpenCensus
你可能会想，现在我们有了OpenTracing，OpenCensus有什么好激动的？不好意思，你应该知道OpenCensus的发起者是谷歌，是最早提出Tracing概念的公司，OpenCensus是Google Dapper的社区版。OpenCensus和OpenTracing最大的区别在于，除了跟踪之外，它还包括Metrics，Metrics也可以用于OpenCensus上的基本索引监控。另一个不同之处是，开放普查不仅仅是一个规范制定，还包括所有的代理和收集器，包括数据收集。OpenCensus也有很多追随者。最近最大的新闻是微软也宣布参与。OpenCensus甚至更强大。
OpenTracing vs OpenCensus
两套Tracing框架都有很多想要统一彼此的追随者。我该怎么办？首先来PK，在这里偷个懒活，直接上史蒂夫的图：
可以看到，OpenTracing和OpenCensus在功能和特性上各有优缺点。OpenTracing支持更多的语言，与其他系统的耦合度更低。OpenCensus支持Metrics，从API到基础框架都很方便。既然分不清功能和特性的区别，那就从人气和用户数开始PK吧：
好吧，又成功了一半。追随OpenTracing的厂商很多(如ElasticSearch、优步、DataDog、国产SkyWalking)。OpenCensus背后的谷歌和微软足以撑起半边天。
最后一场PK下来，没有胜败。我该怎么办？
00-101010
OpenTelemetry
所谓的世界要分很久，也要分很久。既然没有办法划分，每个人都有优点和缺点。让我们停止这样做，统一它。于是，born遥测技术诞生了。
那么问题来了：从零开始统一启动一个新项目可以吗？之前跟踪我的兄弟们呢？我不能失去我的兄弟。
放心，这种事情绝对不会发生。我们应该知道，open遥测的发起者都是OpenTracking和OpenCensus，所以这个项目的第一个目的就是兼容OpenTracking和OpenCensus。使用开放跟踪或开放普查的应用程序可以访问开放遥测，而无需重新修改。
横空出世
open遥测技术诞生时就有一个耀眼的光环：OpenTracing支持、OpenCensus支持和直接访问CNCF sanbox项目。然而，开放遥测并不是为了解决所有的可观测性问题。其核心工作主要集中在三个部分：
规范的制定，包括概念、协议和应用编程接口，除了它们自己的协议之外，还应该与W3C和GRPC保持一致。
相关SDK和Tool的实现和集成，包括各种语言的SDK、自动代码注入和其他第三方库(Log4j、LogBack等)的集成。);
目前采集系统仍采用OpenCensus的采集架构，包括Agent和Collector。
我们可以看到open遥测只做数据规范、SDK和采集，但不涉及后端、可视化、Alert等。目前官方推荐使用普罗米修斯作为度量后端，耶格作为追踪后端。
看完上面的图片，你可能会有疑问：度量，t
racing都有了，那Logging为什么也不加到里面呢？
其实Logging之所以没有进去，主要有两个原因：
-
工作组目前主要的工作是在把OpenTracing和OpenCensus的概念尽早统一并开发相应的SDK，Logging是P2的优先级。
-
他们还没有想好Logging该怎么集成到规范中，因为这里还需要和CNCF里面的Fluentd一起去做，大家都还没有想好。
终极目标
OpenTelemetry的终态就是实现Metrics、Tracing、Logging的融合，作为CNCF可观察性的终极解决方案。
Tracing：提供了一个请求从接收到处理完毕整个生命周期的跟踪路径，通常请求都是在分布式的系统中处理，所以也叫做分布式链路追踪。
Metrics：提供量化的系统内/外部各个维度的指标，一般包括Counter、Gauge、Histogram等。
Logging：提供系统/进程最精细化的信息，例如某个关键变量、事件、访问记录等。
这三者在可观察性上缺一不可：基于Metrics的告警发现异常，通过Tracing定位问题（可疑）模块，根据模块具体的日志详情定位到错误根源，最后再基于这次问题调查经验调整Metrics（增加或者调整报警阈值等）以便下次可以更早发现/预防此类问题。
Metrics、Tracing、Logging融合的关键
实现Metrics、Tracing、Logging融合的关键是能够拿到这三者之间的关联关系.其中我们可以根据最基础的信息来聚焦，例如：时间、Hostname(IP)、APPName。这些最基础的信息只能定位到一个具体的时间和模块，但很难继续Digin，于是我们就把TraceID把打印到Log中，这样可以做到Tracing和Logging的关联。但这还是解决不了很多问题：
-
如何把Metrics和其他两者关联起来
-
如何提供更多维度的关联，例如请求的方法名、URL、用户类型、设备类型、地理位置等
-
关联关系如何一致，且能够在分布式系统下传播
在OpenTelemetry中试图使用Context为Metrics、Logging、Tracing提供统一的上下文，三者均可以访问到这些信息，由OpenTelemetry本身负责提供Context的存储和传播：
-
Context数据在Task/Request的执行周期中都可以被访问到
-
提供统一的存储层，用于保存Context信息，并保证在各种语言和处理模型下都可以工作（例如单线程模型、线程池模型、CallBack模型、Go Routine模型等）
-
多种维度的关联基于Tag（或者叫meta）信息实现，Tag内容由业务确定，例如：通过TrafficType来区别是生产流量还是压测流量、通过DeviceType来分析各个设备类型的数据...
-
提供分布式的Context传播方式，例如通过W3C的traceparent/tracestate头、GRPC协议等
下面是Yuri Shkuro画的原型设计：
+----------------------------------------------------+ | | +------------+ custom application logic or specialized frameworks | | | | | +-------------------------------------+--------------+ | | | +---------+ +------+ +--------+ | | | | | | | | | | | metrics | | logs | | traces +---+ | | | | | | | | | | | +----+----+ +---+--+ +---+----+ | | | ^ ^ ^ | | | +-----+----------+--------+-----+ | | | | | | | +---> baggage | | | | | | | +---------------+---------------+ | | | | | +---------------------+------------------+-----------+-------------------+ Universal context propagation layer <-----> marshaling plugins
到此，相信大家对“OpenTelemetry的相关知识点有哪些”有了更深的了解，不妨来实际操作一番吧！这里是网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
内容来源网络，如有侵权，联系删除，本文地址：https://www.230890.com/zhan/95851.html