图：阿里巴巴高级技术专家姜文锋
2021年10月22日，在云栖大会的《云上运维最佳实践》分论坛，阿里巴巴高级技术专家姜文锋发表了主题为“云服务器可观测能力的探索与实践”的演讲。本篇内容根据他的演讲整理成的文章，通过以下三个部分来介绍云服务器可观测能力的探索与实践。
- 可观测的价值
- 云服务器可观测解决方案
- 总结
一、可观测的价值
什么是可观测能力,它为什么对云服务器这么重要？通俗地讲，可观测能力就是了解云服务器内部运行情况的能力。它对于云服务器的重要性，在我看来主要有三点：提升确定性，简化运维，提升信息透明性。
无论是物理机还是云服务器都做不到百分之百可靠。云服务器具备完善的可观测能力，可以非常全面的扫描云服务器的各种运行指标和内部状态，得到一个丰富的信息全图，来提升信息的透明性，避免黑盒。在异常的场景，通过这个扫描的结果，也可以快速定位问题的原因，简化运维。
二、云服务器可观测解决方案
云服务器可观测整体解决方案，先来看看阿里云是怎么做的。
一切皆数据。阿里云依托强大的数据中台，每天从将近1亿的采集单元采集近100TB的数据，这些数据体现了云服务器内部各种运行状态、指标、参数。这些数据采集上来后经过数据清洗去除噪音，关联分析与定义的各种指标进行关联匹配，最后经过特征计算得出云服务器运行的真实画像。然后再把处理过的数据输出到两类产品。第一类产品就是我们的内部运维保障平台，它是阿里云主动维护云平台稳定性的一个主要的解决方案。
另一类，它会输入到用户端的可观测产品，即为了满足3个目标：确定性运行、简化运维和信息透明而提供的运维产品，包括4个产品：云监控、ECS系统事件、健康诊断、健康状态。下面我们分别介绍这4个产品。
1、云监控
提到监控系统，相信大家都不会感到陌生，云监控就是阿里云针对云上的资源和互联网应用的一个监控、报警服务。云监控相对于传统的监控服务。它有什么样的优势？我会重点说前面两点：
- 天然集成。不需要购买和开通，只需要有阿里云账号就可以使用，即查即用。
- 报警灵活。有灵活的报警规则设置，还有灵活丰富的报警推送渠道。报警推送渠道主要分为两类：一是消息触达类的渠道，比如我们常见的钉钉、短信。更重要的，它可以有一个渠道是自动处理渠道，这是为接下来自动化运维打下一个基础。自动处理渠道包括函数计算、运维编排、消息服务、日志服务。
关于云监控，下面再重点分享一下它强大的主机监控项。云监控除了支持常见的CPU、内存、LOAD、磁盘、网卡之外，它还能对进程做监控。通过进程监控，你可以知道你的进程是不是存活，以及当前进程资源消耗的情况。所以云监控是最基本、最常用的手段。
2、ECS系统事件
阿里云会主动上报影响ECS实例运行的底层运维事件或者非预期的维修事件，并且给用户提供维修建议。ECS系统事件怎样改善和提高云服务器可观测能力呢？
- 主动上报底层问题，提升服务器运行的确定性。
- 能简化运维。系统事件上报上来之后，我们订阅这个事件，实现事件自动化处理，提升事件处理效率、简化运维。
- Event-Driven 能够带来系统效率的提升。大家都知道，异步场景，PUSH模式PULL模式有明显的效率优势。举个非常熟悉的例子：创建ECS实例，一般我们会先调用RunInstances API，得到一个实例ID，然后不断地调用DescribeInstances接口查询实例状态直到变成Running,客户测编程复杂不说，效率还低,改成事件驱动模式则只需订阅实例状态变化事件，等变成Running自动触发后续的业务逻辑,简单高效。上图的右侧是ECS事件服务流程图，事件推送会直接复用云监控异常推送渠道，为我们接下来实现自动化处理事件打下基础。
我们对ECS系统容量有一个基本了解之后，重点看一下它怎么实现事件的自动化处理？上图左侧是目前事件分类，重点看一下右边，这里推荐了两种实现事件自动化处理的方案：
- 第一是把系统事件通过云监控推送到函数计算服务，特定的事件触发特定的函数计算能力，从而实现事件的自动化处理。
- 第二是可以把事件推送给运维编排服务，特定的事件触发我们预先设置好的特定运维编排模板，从而实现事件的自动化处理，这里要提醒函数计算是付费的服务，但运维编排是免费的。
ECS系统事件能够主动上报影响实例运行的底层事件，是云服务器可观测能力的重要一环，能够较好解决确定性运行的问题。但这还不够。因为实际情况是云平台出现严重问题的概率还是很小的，总的来看，云平台是很稳定的。大部分运维问题都是跟用户的操作和使用有关，也就是说问题往往发生在客户OS和客户应用内部。而系统事件对客户OS内的异常覆盖是比较有限的。所以为了进一步完善云服务器的观测能力，我们又推出了诊断服务。诊断服务具体分为三个产品：实例健康诊断、实例健康状态和网络连通诊断。
3、健康诊断
先看一下实例健康诊断，即针对客户OS内的问题，以及云服务器所依赖的云平台软硬件问题做全面检测的服务。我们的诊断项目前分为两大类：客户OS诊断项和云平台诊断项。
今天重点会和大家说一下客户OS诊断项，基于健康诊断，目前能够检测到客户OS内的哪些问题？
- 首先基于健康诊断，能够发现常见的CPU打满、内存不足、磁盘空间不足，占用资源最高的top5进程等资源使用率的问题。
- 其次通过健康诊断还能发现常见的网络设置、磁盘设计、文件系统设置的问题。以网络设置为例，网卡是否up，网络服务是否在运行，网卡多队列是否开启从而保障网络性能，网卡ip配置方式是否正确（比如我们经常遇到用户的实例理应使用dhcp方式动态分配ip，却因为使用了自定义镜像配置了静态ip导致网络不可访问的问题）等常见的网络问题。
- 通过健康诊断，我们还能看到影响实例正常运行的服务是否正常进行，如常见端口是否在监听（比如linux 22端口，windows 3389端口），动态分配ip的dhcp进程是否存在，负责系统初始化的systemd是否正常运行等。
- 通过健康诊断还能看客户OS内有没有设置自定义防火墙，自定义路由表。这往往会造成网络连通方面的问题。云服务器，我们建议使用安全组作为唯一的防火墙解决方案，因为安全组是处于虚拟网络层面，用户无法篡改的，所以它既简单又安全。
以上这些能力是截止到目前我们具备的诊断能力，但这远不是终点。还有很多新的诊断能力在研发中。我还想分享下我们做诊断的一些体会，坦白地说把诊断做好很难，因为客户的问题千差万别，很难通过事先的设计把诊断能力做强做准。我们的经验是要问题驱动，即发现问题解决问题快速迭代不断丰富诊断能力。
接下来我们看一下健康诊断典型的用法。这里我列了两个典型的场景：
首先，做异常实例的原因检测。比如上图能够看到服务器load突然飙高，你当然可以通过更细粒度的监控指标来定位原因，但还有一个更方便的做法，即运行一下实例的健康诊断。以这个case为例，我们会清晰告诉你占用CPU资源最高的进程是谁？它的ID是什么？接下来能够帮助你快速定位问题。可以看一下这个进程是不是业务自身的问题造成的？是正常的业务流量增长还是代码的实现有问题？是不是有最近的发布等。
第二，建议基于健康诊断和运维编排来实现对实例周期性的健康巡检。我们的运维编排服务是支持定期周期执行的能力，你只要针对需要巡检的实例，定期周期的调用实例健康诊断接口，就可以产生诊断报告。然后根据诊断报告的提示来做人工或者自动的处理。如果说实例规模比较大，可以针对提示非常严重的问题，实现自动化的异常响应，自动化运维。
4、健康状态
接下来看一下实例的健康状态。健康状态和健康诊断的原理是一致的，但是健康状态有三个明显的区别。
一是诊断项的范围。实例的健康状态诊断项更加精练，我们选择的是保证实例健康运行的、基本的计算、网络、存储的诊断项。从现在开始ECS是有两种状态，一种是管控状态，还有一种就是运行时状态，也就是健康状态。而实例的健康诊断呈现给用户的是一份诊断报告，除了有问题，还会告知你这个问题的原因是什么？所以说通过这三项对比，我们发现实例健康状态其实是有自己特殊的适用场景。上图是我们精选的实例健康状态支持的诊断项，大家可以简单了解一下。
实例健康状态的典型用法。如果你的实例很少，可以通过控制台及时感知到当前实例运行状态是什么？是不是健康的？
- 如果不是健康，一定是底层或者用户设置出现了什么问题，可以采取相应的运维手段，或者寻求技术支持。
- 如果集群规模比较大，而且对基础设施的可靠性要求非常高。我们建议采用右图，通过弹性伸缩的自动汰换异常实例功能，保障整个集群的基础设施高可用。具体就是通过弹性伸缩的控制台，来开启实例健康状态检测功能。接下来弹性伸缩服务就会代替客户周期检查实例健康状态。发现异常则立刻用相同规格的健康实例汰换异常实例，确保整个基础设施层面保持高可用。
最后，介绍一个我们正在处于公测的产品，网络连通诊断。大家都知道网络不通问题的原因可以非常复杂，我们的客户经常受网络不通问题的困扰，而根据长期帮用户排查问题的经验，发现三类问题高频出现：
- 目标进程监听不正确；
- 防火墙设置的问题。包括客户OS内自定义的防火墙和安全组；
- 实例自身的网络设置问题。
所以针对高频这三种问题，我们研发了网络的端到端诊断。它能够比较准确地发现通信的源和目的节点的：
- 安全组以及客户OS防火墙设置问题
- 子网ACL设置问题
- 实例自身网络状态/设置问题
- 端口是否在正常监听
三、总结
1、几个产品对比
好的，以上我们针对云服务器可观测能力的3个目标：确定性运行、简化运维和信息透明向大家介绍了5个产品：云监控，ECS系统事件，实例健康诊断、实例健康状态和网络端到端诊断。最后，做一个总结和回顾。 首先看下几个产品的特点对比：
- 云监控：特别适合客户OS和客户进程的指标监控和报警
- 系统事件：覆盖的问题域比较广，但主要还是上报因为云平台系统维护或系统错误导致影响实例运行的问题。客户OS和客户进程的问题涉及的比较少。
- 健康诊断：覆盖的问题域很广，诊断项比事件更丰富，尤其是客户OS相关的诊断项很丰富，而且仍然在不断丰富。
- 健康状态：原理与健康诊断类似，但诊断项更精炼，适合特定的场景。
2、不同场景下的产品选择
最后从场景角度，看一下不同的场景适合使用什么样的产品和工具，来解决我们的问题。
- 如果我们想做业务或者主机监控/度量和报警，优先使用云监控。
- 如果我们的实例出现了异常，我们想周期性对实例做一个健康的巡检，我们建议使用ECS系统事件和ECS健康诊断。
- 如果你的场景是容器或二次虚拟化的场景，对基础设施的高可用要求非常高。那么我们建议弹性伸缩+实例健康状态的异常实例自动探算能力，保证整个集群的高可用。
- 如果遇到网络不通问题，优先使用网络端到端诊断。看一下常见的安全组，客户安全防火墙，进程监听以及自身实例网络设置有没有问题。
点击大会官网，观看姜文锋的精彩演讲视频。
