大家都在谈可观测性,究竟怎样落地?
【摘要】很多人都在谈可观测性，但到底该怎样落地，却很少提及。本文帮助读者明白可观测性与监控的本质差异，进而理解可观测性的落地步调，以及一体化可观测平台或监控平台的构建思路。【作者】汪照辉，专注于容器云、微服务、DevOps、数据治理、数字化转型等范畴，对相关技术有独特的理解和见解。善于于软件规划和计划，提出的“平台融合”的观点越来越得到认同和事实证明。发表了众多技术文章探讨容器平台建立、微服务技术、DevOps、数字化转型、数据治理、中台建立等内容，受到了广泛关注和肯定。有社区会员盼望分享下可观测性实际怎样落地。这的确是一个需要讨论的题目。很多人都在谈可观测性，但到底该怎样落地，却很少提及。要落地可观测性，首先要对可观测性有精确的理解，明白其与监控的本质差异。由于可观测性和监控根本上利用相同的工具，如指标、日记、链路等，只不过其实现的思想有所区别，因此很多人说不明白其差别，也就无从落地。也因此需要首先理解可观测性和监控在实现思想上的异同。
理解可观测性和监控的异同
可观测性和监控都是为了理解系统，可观测性偏重不依赖外部工具看系统的可理解性，监控在偏重看运行时的状态指标等。可观测性的实现是不需要额外的工具的。可观测性是系统自身的属性，自带光芒的，好比系统运行分配利用的资源、运行日记、调用关系等都可以通过系统自身的可视化界面进行展示或暴露出去，因此具备可观测性的系统通常可以认为是白盒的，可以清楚地理解其内部逻辑和处理过程，这样便于在开发时进行调试，在运行时进行故障定位和修复。具备可观测性的系统不需要额外工具进行数据采集，可观测性的指标、日记、链路信息是主动暴露出来的。
监控的实现需要额外的数据采集工具。监控是侵入性的数据采集，通常需要一个agent完成数据的采集，好比说，最常用的filebeat，对日记进行采集，日记采集之后通过Elasticsearch存储数据，用Kibana进行展示。这些中心件工具都是为了实现系统的运行监控而额外部署的组件。如果没有这些额外的采集监控工具组件采集展示运行数据，就难以知晓系统的运行状况。
拿K8s来说，Metrics Server可以看作是可观测性的一个实现。Metrics Server是Kubernetes内置的可扩展、高效的容器资源指标源。它从Kubelets收集资源指标，并通过Metrics API在Kubernetes apiserver中公开这些指标 ，供Horizontal Pod Autoscaler和Vertical Pod Autocaler利用。kubectl top也可以访问其指标API，从而更容易地调试自动缩放管道 。不过Metrics Server不被发起用于监控办理方案，仅用于自动缩放目的。K8s 发起监控数据可以直接从Kubelet/metrics/资源端点收集指标。固然不发起，但Metrics Server却是很不错的可观测性指标源。
K8s扩展node exporter+Push gateway+Prometheus则可以看作是监控的实现方式。它通过Node exporter将节点的CPU、内存、网络、文件系统、负载等信息发给Prometheus进行处理展示，而不是利用K8s自身提供的能力，额外部署exporter来采集数据。
本质上，可观测性和监控的区别就在于实现的方式，也就是实现思想和思路是不一样的。可观测性是从内主动收集和暴露展示自身的处理逻辑、资源利用、状态等；而监控是从外通过工具采集系统的日记、运行环境、运行状态等。监控获得的数据往往是有限的，特别对内部逻辑关系需要通过采集的数据进行推测，所以在故障定位和处理方面就比可观测性要差些。特别随着云原生分布式应用复杂度的增长，故障定位和处理服从非常关键，对系统内部逻辑的理解是故障定位和修复的前提，也因此可观测性越来越受到重视。
可观测性实现
可观测性可以视为监控的进一步发展阶段，其关注点差别，实现方式就差别。理解了可观测性和监控的本质区别，那么对于可观测性该怎样实现？首先需要从系统本身入手，在计划开发时就需要思量系统的可观测性能力，确定输出指标、日记、链路关系等。所以可观测性能力取决于计划开发阶段和职员对可观测性的理解和重视程度。这也是把可观测性作为一种文化的原因。文化就是一种约定俗成的习惯。习惯了可观测性计划开发，可观测性就成了一种天然而然地事情。
可观测性落地步调可以是：
首先，实现可观测性需要在系统计划开发过程中计划界说系统/应用的可观测输出指标、日记、调用链路关系等；
其次，需要收集这些指标、日记、调用关系信息等；
第三，需要把这些信息通过某种方式主动发布/暴露出去；
第四，信息处理和分析，以可视化方式组织展示这些信息。
通过可观测性落地步调可以看到可观测性用到的工具照旧指标、日记、链路跟踪等这些工具，跟监控没有大的区别，只不过是实现方式和实现思想不一样了。监控关注的运行中的系统状况，而可观测性伴随系统整个生命周期过程。
由于云原生系统往往是复杂的分布式系统，由众多的服务编排而成，服务之间的链路关系可能会很复杂，在出现非常时题目的定位和修复往往需要协调差别团队、众多职员协助办理。好比说，部署在云原生PaaS 上的某个服务有请求超时，可能是被调用服务的数据库地点的节点磁盘不足导致的。如果可以大概通过链路跟踪快速定位到节点磁盘题目，就能快速办理题目。云原生分布式微服务之间的共享和依赖（微服务理论上的自治也无法办理服务或组件之间依赖题目和可被理解题目）使整个链路管理可能碎片化，差别的服务由差别的团队运维，平台属于基础办法团队，也就导致题目定位协调复杂化。这就需要整个链路可以或答应见，被理解，也就是可观测性，这也可能是可观测性缘起的原因吧。
为了更好地理解各个服务之间所编排出来的应用的处理逻辑，以及在出现非常时能快速定位和办理，全部的服务就需要依照一定的原则和方法来界说可被便于理解的指标、一致规则的日记、标准化的API 接口等，并且通过公共的工具或地方可以或答应视化快速检察。如果要把这些指标、日记等信息收集起来并通过公共的工具可视化检察，那就需要收集这些信息，并从源端（系统自身）发送到目标端（可视化可观测/监控平台）。可观测性源端和目标端之间可采用 pub-sub的信息处理方式，让系统把收集起来的指标、日记等发布出来，任何一个对这些指标和日记等感兴趣的单位，都可以接收和进一步处理。一对多，这就避免了重复信息采集的题目。不用对接一套系统就部署一个agent 或插件采集一遍数据，对源系统无侵入、更不会有性能影响。
事故events触发响应模式非常契合可观测性的实现需求。每一个事故event触发，都会带来无论是状态或资源利用或数据变更等的变化，每次变化若都能利用户可见，从而就实现了可观测能力。终极这些events事故信息可以汇聚到一体化可观测平台或监控平台，从而获得全局的认知和把控。
一体化可观测平台或监控平台
可观测性和监控可以互为补充可以共同构建企业的一体化监控/可观测平台。可观测性和监控并不是水火不容的有你无我，也不是说系统具备了可观测性就不需要监控了。新的系统或应用关注可观测性能力，而汗青遗留系统和应用或不具备可观测性能力的系统和应用依然需要监控工具。在企业内部共同构建一套一体化可观测平台/监控平台，可以全面的相识企业内全部系统、资源等的运行状况，相识系统运行态势，可以借助其他工具或平台进一步分析和处理。一体化平台的运维数据也可以作为绩效等的参考。
一体化可观测/监控平台思路
不管监控或可观测性，目的是为了相识系统的内部逻辑，看到系统的及时运行状况，并能对非常状况进行敏捷响应和规复，至于用监控的数据采集方式照旧用可观测性的数据发布方式，取决于实际环境和系统的实际情况。不过就实现方式来说，可观测性具备更好的理念和对源系统更小的影响。
有任何题目可点击“阅读原文”到社区原文下留言
觉得本文有效，请转发、点赞或点击“♡”，让更多同行看到
资料/文章推荐：
[*]从系统监控到系统可观测性，是技术趋势，更是一种文化
[*]从智慧运维到系统可观测性
[*]云原生可观测性的未来
[*]系统运维管理员会被自动化淘汰吗？8 篇带来启发的自动化/智能运维思考和实战文章
[*]深入探索eBPF可观测性技术的底层奥秘
欢迎关注社区 “智能化运维”技术主题 ，将会不断更新优质资料、文章。地址：https://www.talkwithtrend.com/Topic/125353
下载 twt 社区客户端 APP
长按辨认二维码即可下载
或到应用商店搜索“twt”
长按二维码关注公众号
*本公众号所发布内容仅代表作者观点，不代表社区态度
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！
页:
[1]