共计 5476 个字符，预计需要花费 14 分钟才能阅读完成。
简介：一文看懂可观测！
作者：西杰 & 白玙
可观测的前生今世
零碎的可观测与故障可剖析作为零碎运维中重要的衡量标准，随着零碎在架构、资源单位、资源获取形式、通信形式演进过程，遇到了微小挑战。而这些挑战，也在倒逼着运维相干技术倒退。在正式开始明天的内容前，咱们来讲讲可观测的前世今生，纵观整个运维监控倒退历程，监控与可观测曾经倒退了近 30 年。
上世纪 90 年代末，随着计算从大机（mainframe）逐步转移到桌面电脑，client-server 架构的利用开始流行，大家开始关注网络性能和主机资源。为了更好的监控这种 CS 的利用，第一代 APM 软件诞生。运维团队在这一时期看重与网络性能、主机性能，因为此时的利用架构还非常简单。此时，咱们还称这些工具为监控工具。
进入到 2000 年，互联网飞速发展，浏览器成为新的用户界面。利用演进成为基于浏览器的 Browser-App-DB 的三层架构，同时 Java 作为企业级软件的第一编程语言开始流行，编写一次、到处运行（write once，run anywhere）的理念，极大的晋升了代码的生产力，然而 Java 虚拟机也屏蔽了代码运行的细节，使得调优排错变得更加艰难，所以对于代码级的跟踪诊断和数据库的调优成为新的关注点，从而诞生了新一代的监控工具 APM（利用性能监控）。
2005 年之后，分布式应用成为很多企业的第一抉择，像基于 SOA 架构、ESB 的利用大行其道。同时，虚拟化技术逐步流行，传统服务器这个物理单位逐步淡化，变成了看不见、摸不到的虚构资源模式。像音讯队列、缓存这样的三方组件也开始利用在生产环境中。在这样的技术环境下，催生出新一代 APM 软件，企业开始须要进行全链路追踪，同时监控虚构资源和三方组件监控，这样就衍生出了新一代 APM 的外围能力。
到了 2010 年之后，随着云原生架构开始落地实际，利用架构开始从单体零碎逐渐转变为微服务，其中的业务逻辑随之变成微服务之间的调用与申请。同时虚拟化更加彻底，容器治理平台被越来越多企业承受，三方组件也逐步演变成云服务，整个利用架构成为云原生架构。服务的调用门路变长，使得流量的走向变得不可控，故障排查的难度增大，须要一种全新的可观测能力，通过笼罩全栈的各种可观测数据（指标，日志，链路，事件）在开发测试运维的全利用生命流程进行继续的剖析。
能够看到，可观测能力成为云原生的基础设施。整个可观测能力从单纯的运维态开始向测试开发态演进。可观测的目标也从撑持业务失常运行进一步扩大到减速业务翻新，让业务疾速迭代起来。
监控 & APM & 可观测的认知同异
从上述历程，咱们能够看到从监控到 APM 到可观测是个一直演进的过程。接下来，咱们讲讲这三者之间的具体关系。为了更好的解说，这里先引入一个经典认知模型。对于世界万物，咱们通常会依照“知不知道”（awareness）以及“理不了解”（understanding）两个维度进行划分，即“感知”与“了解”。
那么，首先对于咱们晓得且能了解的事件，咱们称之为事实。落到方才探讨的话题中，这一部分对应的就是监控。比方进行运维工作时，一开始时候就会设计去监控服务器的 CPU 利用率，这个利用率不论是 80% 还是 90%，都是一个客观事实。这就是监控解决的事件，即基于晓得要监控什么，制订采集相应指标，并建设监控大盘。
接下来，就是咱们晓得但不了解的事件。比方监控到 CPU 利用率达到 90%，然而为什么会到这么高，是起因什么导致的，这就是一个查证的过程。通过 APM 能够采集并剖析主机上的利用性能，发现在利用链路调用过程中某个高延时的 log 框架，从而引起了主机上的 CPU 利用率飙升。这就是借助 APM 通过应用层剖析去发现 CPU 利用率高的背地起因。
而后，就是咱们了解但不晓得的事件。仍旧是 CPU 利用率高这个场景案例，如果通过学习历史数据和关联事件预测到将来的某个时刻会呈现 CPU 利用率飙升，就能够实现预警。
最初，就是咱们不晓得且不了解的事件。还是下面的例子，如果通过监控发现 CPU 使用率飙升，通过 APM 发现利用日志框架所致。但进一步，如果剖析这一时间段内用户的拜访数据，发现在上海地区，通过苹果终端拜访的申请，相比其余的状况响应时长要高 10 倍，而这种类型的申请因为日志框架的配置产生了海量的 Info 日志，导致了某些机器的 CPU 飙升。这就是一个可观测的过程。可观测是须要去解决你当时不晓得（来自上海的苹果终端拜访性能问题）也不了解的事件(谬误配置日志框架产生海量 info 日志）
简略总结一下，在监控畛域咱们关注指标，这些指标可能集中在基础架构层，比如说机器、网络的性能指标。而后基于这些指标建设相应看板以及告警规定去监测已知范畴里的事件。在监控发现了问题之后，APM 通过基于利用层面的链路以及内存和线程等诊断工具，去定位监控指标异样的根因。
可观测以利用为核心，通过将日志、链路、指标、事件等各种可观测数据源进行关联、剖析，更加疾速、间接地找出根因。并提供一个可观测界面，让用户能够灵便自在的在这些可观测数据中进行摸索与剖析。与此同时，可观测能力与云服务买通，即时强化利用的弹性扩缩容、高可用等能力，在发现问题时可能更放慢地解决相干问题，复原应用服务。
建设可观测体系要害要点
可观测能力带来了微小业务价值的同时，也带来了不小的零碎建设挑战。这不仅仅是工具或技术的选型，更是一种运维理念。这其中包含可观测数据的采集、剖析以及价值输入三个局部。
可观测数据采集
目前业界宽泛推广的可观测数据蕴含三大支柱：日志事件（Logging）、链路追踪（Tracing）、指标监控（Metrics），其中存在一些共性须要关注。
1）全栈笼罩
根底层、容器层、上方组建云服务利用，以及用户终端相应可观测数据以及与之对应的指标、链路、事件都须要被采集。
2）统一标准
整个业界都在推动规范对立，首先是指标（metrics），Prometheus 作为云原生时代的指标数据规范曾经造成了共识；链路数据的规范也随着 OpenTracing 和 OpenTelemetry 的推广而逐步占据支流；在日志畛域尽管其数据的结构化水平较低难以造成数据的规范，但在采集存储和剖析侧也涌现了 Fluentd，Loki 等开源新秀；另一方面，Grafana 作为各种可观测数据的展现规范也更加清朗。
3）数据品质
数据品质作为容易漠视的重要局部，一方面，不同监控零碎的数据源须要进行数据规范的定义，确保剖析的准确性。另一方面，同个事件可能导致大量反复指标、告警、日志等。通过过滤、降噪和聚合，把具备剖析价值的数据进行剖析，保证数据品质的重要组成部分。这也往往是开源工具与商业化工具差距绝对较大的中央。举个简略例子，当咱们采集一条利用的调用链路，到底采集多深？调用链路采样的策略是什么样的？产生错、慢时是不是可能全副采下来？是不是可能基于肯定规定对采样策略进行动静调整等等，都决定了可观测数据采集的品质。
可观测数据分析
1）横纵关联
在目前的可观测体系里，利用是十分好的剖析切入角度。首先，利用与利用之间是互相关联，能够通过调用链关联起来。其中包含微服务之间是如何调用，利用与云服务以及三方组件如何调用，都能够通过链路进行关联。同时，利用与容器层、资源层也可进行垂直映射。以利用为核心，通过横向纵向造成全局可观测数据关联。当呈现问题须要进行定位时，可能从利用角度进行对立剖析。
2）畛域常识
面对海量数据，如何更疾速的发现问题，更精确定位问题。除了通过以利用为核心的数据关联，还须要去定位剖析问题的畛域常识。对于可观测工具或产品而言，最重要的就是一直累积最佳排查门路、常见问题定位、根因的决策链路办法，并把相干教训固化下来。这相当于为运维团队装备经验丰富的运维工程师，去疾速发现问题，定位根因。这个也是不同于传统的 AIOps 能力。
可观测价值输入
1）对立展示
下面提到可观测须要笼罩各个档次，每层都有相应可观测数据。但目前可观测相干工具十分零散，如何将这些工具产生的数据对立展示进去，成了比拟大挑战。可观测数据的对立其实是绝对较难的事件，包含格局、编码规定、字典值等问题。但数据后果对立出现是能够做到的，目前支流的解决方案是应用 Grafana，搭建像对立监控大盘。image.gif
2）合作解决
在对立展示以及对立告警之后，如何借助像钉钉、企业微信等合作平台可能更加高效地进行问题发现并解决跟踪的 ChartOps，也逐步成为刚需。
3）云服务联动
可观测能力成为云原生的基础设施，当可观测平台在发现并定位问题之后，须要与各种云服务疾速联动，迅速进行扩缩容或负载平衡，从而更快的解决问题。
Prometheus + Grafana 实际
得益于云原生开源生态的蓬勃发展，咱们能够轻而易举地建设一套监控体系，比方应用 Prometheus + Grafana 搭建根底监控，应用 SkyWalking 或 Jaeger 搭建追踪零碎，应用 ELK 或 Loki 搭建日志零碎。但对运维团队而言，不同类型可观测数据扩散存储在不同后端，排查问题仍需在多零碎之间跳转，效率得不到保障。基于以上，阿里云也为企业提供了一站式可观测平台 ARMS（利用的实时监控服务）。ARMS 作为产品家族，蕴含了不同可观测场景下的多款产品，比方：
针对于基础架构层，Prometheus 监控服务对包含 ECS、VPC、容器在内的各类云服务以及三方中间件进行监控。
针对应用层，基于阿里云自研 Java 探针的利用监控全面满足利用监控需要。相较于开源工具，在数据品质等方面十分大的晋升。并通过链路追踪，即便应用开源 SDK 或探针，也能够将数据上报到利用监控平台。
针对用户体验层，通过挪动监控、前端监控、云拨测等模块，全面笼罩用户在不同终端上的体验与性能。
对立告警，对于各层采集的数据、告警信息进行对立告警以及根因剖析，间接通过 Insight 出现发现后果。
对立界面，不论是 ARMS、Prometheus 的上报数据，还是日志服务、ElasticSearch、MongoDB 等各种数据源，都能够通过全托管 Grafana 服务进行对立的数据可观测数据出现，建设对立的监控大盘，并与阿里云各种云服务进行联动，提供 CloudOps 能力。
上述提到 ARMS 作为一站式产品，具备十分多的能力。目前企业已自建局部与 ARMS 相似能力，或采纳 ARMS 中的局部产品，比方利用监控、前端监控。但残缺的可观测零碎对于企业而言，仍旧至关重要，并心愿基于开源去构建合乎本身业务需要的可观测零碎。在接下来的示例中，咱们着重解说 Prometheus + Grafana 如何去构建可观测零碎。
数据疾速接入
在 ARMS 中，咱们能够疾速建设一个 Grafana 独享实例，ARMS Prometheus、SLS 日志服务、CMS 云监控数据源都能够十分便捷的进行数据同步。关上 Configuration，能够疾速查看相应数据源。在工夫疾速接入各种数据源的同时，尽可能升高日常数据源治理的工作量。
预置数据大盘
在数据实现接入后，Grafana 主动帮大家创立好相应数据大盘。以利用监控以及容器监控大盘举例，像黄金三指标、接口变动等根底数据都将默认提供。
能够看到，Grafana 尽管帮忙大家把各种数据看板搭建起来，但看到的仍旧是零散大盘。在日常运维过程中，还须要基于业务域或基于利用创立对立大盘，可能将基础架构层、容器层、应用层、用户终端层的数据都放到同一个大盘中进行展示，从而实现整体监控。
全栈对立大盘
在建设全栈对立大盘时，咱们依照用户体验、利用性能、容器层、云服务、底层资源等维度进行筹备。
1）用户体验监控
常见的 PV、UV 数据、JS 错误率、首次渲染工夫、API 申请成功率、TopN 页面性能等要害数据都会在第一工夫出现。image.gif
2）利用性能监控
以黄金三指标为代表的申请量、错误率、响应工夫。并依据不同利用、不同服务进行辨别。
3）容器层监控
各个 Pod 的性能、应用状况，同时也列出这些利用上跑的由哪些 department 创立的。这些 deployment 相干的 Pod 性能信息都出现在这一块。image.gif
4）云服务监控
此外，就是相干的云服务监控，这里以音讯队列 Kafka 举例，像音讯服务常见的相干数据指标如消费量沉积、消费量等数据。
5）主机节点监控
针对整个主机节点，CPU、所运行的 Pod 等数据。
这样子，这张大盘就笼罩了从用户体验层到应用层到基础架构容器层的整体性能监测状况。更加重要的是整个大盘蕴含着所有微服务的相干数据。当切某个服务，服务相关联的性能数据都将独立展示进去。在容器、利用、云服务等不同层面都进行过滤。这里略微提一下是怎么做到的，当 Prometheus 监控去采集这些云服务时，会顺带把云服务上的 tag 都采集下来。通过对 tag 进行打标，就能够把这些云服务基于不同业务维度或不同利用进行辨别。在做咱们对立大盘的时候，肯定会遇到十分多的数据源治理问题。这里咱们提供了 globalview 能力，把这个用户名下所有的 Prometheus 实例都汇聚到一起，对立进行查问。不论是应用层的信息，还是云服务的信息。
借助下面的场景，咱们抛砖引玉提出可观测性平台设计方向：基于零碎和服务观测的角度把不同数据在后端交融剖析，而不是刻意强调零碎反对可观测性三种数据的别离查问，在产品性能和交互逻辑上尽可能对用户屏蔽 Metrics、Tracing、Logging 的割裂。建设残缺可观测闭环，从事变前异样发现、事变中故障排查到事变后的被动预警监控，为业务继续监控、优化服务性能提供一体化平台。
原文链接
本文为阿里云原创内容，未经容许不得转载。
