简介：一篇文章了解可观察性！作者：席杰&白宇Observable前世今生Observable和故障分析是系统运维的重要指标。随着系统在架构、资源单元、资源获取方式、通信方式等方面的演进，遇到了巨大的挑战。而这些挑战也在倒逼运维相关技术的发展。在正式开始今天的内容之前，先说说可观察性的前世今生。纵观运维监控的整个发展过程，监控和可观察性已经发展了近30年。20世纪90年代后期，随着计算逐渐从大型机转向台式机，客户端-服务器架构的应用开始流行，大家开始关注网络性能和主机资源。为了更好的监控这个CS的应用，第一代APM软件诞生了。运维团队在这期间主要关注网络性能和主机性能，因为此时的应用架构还很简单。此时，我们也将这些工具称为监控工具。快进到2000年，互联网发展迅速，浏览器成为新的用户界面。应用演化为基于浏览器的Browser-App-DB三层架构。与此同时，Java作为企业级软件的第一编程语言开始流行起来。“一次编写，随处运行”的概念得到了极大的改进。但是，Java虚拟机也屏蔽了代码运行的细节，使得调优和故障排除变得更加困难。因此，代码级跟踪诊断和数据库调优成为新的关注点，从而催生了新一代的监控工具APM（ApplicationPerformanceMonitoring）。2005年后，分布式应用成为很多企业的首选，比如基于SOA架构、ESB的应用开始流行。与此同时，虚拟化技术逐渐盛行，传统服务器的物理单元逐渐弱化，成为一种看不见摸不着的虚拟资源模型。消息队列、缓存等三方组件也开始在生产环境中使用。在这样的技术环境下，新一代APM软件诞生，企业开始需要进行全链路跟踪，同时监控虚拟资源和三方组件监控，从而衍生出新一代APM的核心能力。2010年后，随着云原生架构开始落地，应用架构开始逐渐从单体系统向微服务转变，其中的业务逻辑变成了微服务之间的调用和请求。同时，虚拟化更加彻底，容器管理平台被越来越多的企业所接受，三方组件逐渐向云服务演进，整个应用架构成为云原生架构。业务的调用路径变长，导致流量不可控，故障排查难度加大。需要全新的可观测性。通过覆盖整个应用生命周期的开发、测试、运维过程中全栈的各种可观察数据（指标、日志、链接、事件）进行持续分析。可见，可观察性成为云原生基础设施。整个可观察能力从纯运维状态演进到测试开发状态。可观察性的目的也从支持正常的业务运营进一步扩展到加速业务创新，让业务快速迭代。Monitoring&APM&observablecognitive的异同从上面的过程可以看出，从monitoring到APM再到observable是一个不断进化的过程。接下来，我们说说这三者之间的具体关系。为了更好的解释，这里先介绍一个经典的认知模型。对于世间万物，我们通常按照“觉知”和“理解”两个维度来划分，即“知觉”和“理解”。好吧，首先，我们所知道和理解的我们称之为事实。落入刚才讨论的话题，这部分对应的是监控。比如在做运维工作的时候，一开始就设计监控服务器的CPU使用率。无论利用率是80%还是90%，都是客观事实。这就是监控解决的，就是在知道监控什么的基础上，制定并收集相应的指标，建立监控仪表盘。其次，有些事情我们知道但不明白。比如监控到CPU使用率达到90%，但是为什么这么高，是什么原因造成的，这是一个验证过程。通过APM可以收集和分析主机上的应用性能，发现在应用链路调用过程中存在高延迟的日志帧，导致主机上的CPU利用率飙升。这就是在APM的帮助下通过应用层分析发现高CPU利用率的原因。然后，还有一些我们了解但不知道的事情。依旧是CPU占用率高的情况。如果通过学习历史数据和相关事件来预测未来某个时刻CPU使用率会出现激增，就可以实现预警。说到底，是我们不知道，不明白的。还是上面的例子，如果通过监控发现CPU使用率飙升，通过APM发现是应用日志框架导致的。但更进一步，如果我们分析这段时间用户的访问数据，我们发现在上海地区，通过苹果终端访问的请求的响应时间是其他情况的10倍，而这类请求是由于日志框架的配置。产生大量Info日志，导致部分机器CPU飙升。这是一个可观察的过程。可观察性需要解决你事先不知道（来自上海的苹果终端访问性能问题）和不理解（错误配置的日志框架产生海量信息日志）的事情。综上所述，在监控领域，我们关注的是指标，而这些指标可能集中在基础设施层，比如机器和网络的性能指标。然后根据这些指标，建立相应的看板和报警规则，对已知范围内的事物进行监控。监控发现问题后，APM通过应用级链路和内存、线程等诊断工具定位监控指标异常的根源。Observable以应用为中心，通过对日志、链接、指标、事件等各种可观察数据源进行关联分析，可以更快速、更直接地找到根源。并提供一个可观察的接口，让用户可以灵活自由地探索和分析这些可观察的数据。同时，可观测性可以与云服务对接，瞬间增强应用的弹性伸缩、高可用等能力。发现问题后，可以更快地解决相关问题，恢复应用服务。构建可观测系统的关键点可观测能力带来巨大的商业价值，同时也给系统建设带来不小的挑战。这不仅仅是工具或技术的选择，更是一种运维理念。这包括三个部分：可观察数据的收集、分析和价值输出。Observable数据收集Observable数据在业界得到广泛应用，由三大支柱组成：Logging、Tracing和Metrics。它们之间有一些共同点需要注意。1）全栈覆盖了基础层、容器层、上面构建的云服务应用，以及相应的用户端可观察数据和相应的需要采集的指标、链接、事件。2）统一标准整个行业都在推动标准的统一，首先是指标。Prometheus作为云原生时代的指标数据标准已经形成共识；链路数据的标准随着OpenTracing和OpenTelemetry的实现逐渐成为主流；在日志领域，虽然数据结构低，难以形成数据标准，但在采集、存储和分析端也涌现出Fluentd、Loki等开源新秀；另一方面，Grafana作为各种可观察数据的展示标准也越来越清晰。3）数据质量数据质量是一个很容易被忽视的重要部分。一方面，不同监测系统的数据来源需要定义数据标准，以保证分析的准确性。另一方面，同一个事件会导致大量重复的指标、告警、日志等。通过过滤、降噪和聚合，对具有分析价值的数据进行分析，是保证数据质量的重要一环。这往往是开源工具和商业工具差距比较大的地方。举个简单的例子，我们在采集一个应用调用链接的时候，采集的深度是多少？调用链接采样的策略是什么？是否可以收集所有错误和延误？抽样策略是否可以根据一定规则动态调整等，都决定了可观察数据采集的质量。可观测数据分析1）水平和垂直相关性在目前的可观测系统中，应用是一个很好的分析角度。首先，应用之间是相互关联的，可以通过调用链链接起来。其中包括微服务之间如何调用，应用程序和云服务之间如何调用，第三方组件，都可以通过链接关联起来。同时，应用层、容器层、资源层也可以垂直映射。以应用为中心，横向和纵向形成全局可观察数据关联。当需要定位问题时，可以统一从应用的角度进行分析。2）领域知识面对海量数据，如何更快的发现问题，更准确的定位问题。除了以应用为中心的数据关联外，还需要对分析问题的领域知识进行定位。对于可观察的工具或产品，最重要的是不断积累最佳故障排除路径、常见问题定位、根因决策环节方法，并固化相关经验。这相当于给运维团队配备了经验丰富的运维工程师，可以快速发现问题，定位根源。这也不同于传统的AIOps能力。可观测值输出1）统一展示上面提到，可观测性需要覆盖各个层级，每个层级都有对应的可观测数据。但是，目前与observable相关的工具非常分散，如何将这些工具产生的数据统一展示成为一个比较大的挑战。可观察数据的统一其实是比较困难的，包括格式、编码规则、字典值等问题。但是，数据结果的统一呈现是可能的。目前主流的方案是使用Grafana搭建统一的监控仪表盘。image.gif2)协同处理在统一展示、统一告警之后，如何利用钉钉、企业微信等协同平台，更高效地发现问题并处理跟踪ChartOps，逐渐成为刚需。3）云服务联动和可观察性成为云原生基础设施。可观察平台在发现和定位问题后，需要快速对接各种云服务，进行快速扩容或负载均衡，从而更快地解决问题。Prometheus+Grafana的实践，得益于云原生开源生态的蓬勃发展。我们可以很方便的搭建监控系统，比如使用Prometheus+Grafana搭建基础监控，使用SkyWalking或者Jaeger搭建跟踪系统，使用ELK或者Loki搭建日志系统。但对于运维团队来说，不同类型的可观察数据分散存储在不同的后端，故障排查仍然需要在多个系统之间跳转，效率无法得到保证。基于以上，阿里云还为企业提供了一站式可观察平台ARMS（ApplicationReal-timeMonitoringService）。作为一个产品家族，ARMS包含了多种不同可观察场景的产品。比如在基础设施层，Prometheus监控服务监控ECS、VPC、容器、第三方中间件等各种云服务。对于应用层，基于阿里云自研Java探针的应用监控完全满足应用监控需求。与开源工具相比，它在数据质量等方面有了很大的提升。并且通过链路追踪，即使使用开源SDK或者探针，也可以将数据上报给应用监控平台。对于用户体验层，通过移动端监控、前端监控、云拨号测试等模块，全面覆盖不同终端的用户体验和表现。统一告警，对各层采集的数据和告警信息进行统一告警和根因分析，通过Insight直接呈现发现结果。统一接口，无论是ARMS、Prometheus上报的数据，还是日志服务、ElasticSearch、MongoDB等各种数据源，都可以使用全托管的Grafana服务进行统一的数据可观察数??据呈现，建立统一的监控市场，以及与阿里云的各种云服务联动，提供CloudOps能力。如上所述，ARMS是一个具有许多功能的一站式产品。目前企业已经构建了一些类似ARMS的能力，或者采用了ARMS中的一些产品，比如应用监控、前端监控等。但是一个完整的可观察系统对于企业来说还是很重要的，他们希望基于开源来构建一个满足自身业务需求的可观察系统。在接下来的例子中，我们将着重讲解Prometheus+Grafana是如何构建可观察系统的。快速数据接入在ARMS中，我们可以快速创建一个Grafana专属实例，ARMSPrometheus、SLS日志服务、CMS云监控数据源都可以非常方便的进行数据同步。打开Configuration可以快速查看对应的数据源。在随时快速访问各种数据源的同时，尽可能减少日常数据源管理的工作量。数据连接到预设的数据盘后，Grafana会自动为你创建对应的数据盘。以应用监控、容器监控为例，默认会提供黄金三项指标、接口变化等基础数据。可以看到，虽然Grafana帮助大家搭建了各种数据仪表盘，但大家看到的仍然是一个碎片化的市场。在日常运维过程中，还需要基于业务领域或应用创建统一的仪表盘，让基础设施层、容器层、应用层、用户终端层的数据统一展示磁盘实现全面监控。.全栈统一平台在构建全栈统一平台时，我们从用户体验、应用性能、容器层、云服务、底层资源等方面进行了准备。1）常用PV、UV数据、JS错误率、首次渲染时间、API请求成功率、TopN页面性能等用户体验监测中的关键数据将第一时间呈现。image.gif2)应用性能监控以请求量、错误率、响应时间这三个黄金指标来表示。并根据不同的应用和不同的服务进行区分。3）容器层监控每个Pod的性能和使用情况，也会列出哪些部门创建了这些应用。这些与部署相关的Pod性能信息在本节中介绍。image.gif4)云服务监控此外，它是相关的云服务监控。这里我们以消息队列Kafka为例，比如消息服务常用的相关数据指标，比如消费累计、消费等数据。5）Host节点监控针对的是整个Host节点、CPU、运行中的Pod等数据。这样，这个大板就涵盖了从用户体验层到应用层再到基础设施容器层的整体性能监控。更重要的是，整个市场包含所有微服务的相关数据。当切换到某个服务时，与该服务关联的性能数据将独立显示。过滤在容器、应用程序和云服务等不同级别执行。这里稍微提一下它是如何完成的。Prometheus在监控采集这些云服务时，会顺便采集这些云服务上的所有标签。通过标记标签，可以根据不同的业务维度或不同的应用来区分这些云服务。当我们统一市场的时候，肯定会遇到很多数据源管理的问题。这里我们提供globalview的能力，将这个用户名下的所有Prometheus实例汇集起来，进行统一查询。无论是应用层信息还是云服务信息。借助上述场景，我们提出了可观察性平台的设计方向：基于系统和服务观察的角度，将不同的数据在后端进行整合分析，而不是刻意强调系统支持单独查询三种类型的可观察性数据。在交互逻辑上尽可能屏蔽Metrics、Tracing、Logging与用户的分离。建立完整的可观察闭环，从事故前的异常发现、事故中的故障排除到事故后的主动预警和监控，为业务持续监控和优化服务绩效提供一体化平台。原文链接本文为阿里云原创内容，未经许可不得转载。
