在云计算时代，如何监控云服务的 SLA ？

在云计算时代，如何监控云服务的 SLA ？

当今已处于云计算时代，什么都云化了，从文件存储到视频转换，从服务器托管到后端接口，甚至于特定的应用逻辑，比如 IM 服务、好友关系服务等等，很多东西云厂商都帮我们做好了！

因而监控这个主题也貌似渐渐地谈得少了！
甚至于运维人员的需求也在逐渐变少了！
那我们就可以一劳永逸了吗？
不需要我们了解服务器和系统了？
不需要我们部署监控系统和服务了？
我们只需要写好代码发布就可以睡大觉了？
No！

虽然云服务器厂商帮我们打理了一切的基础设施，但是 IaaS 厂商给我们的还只是一个个全裸的系统！

虽然 PaaS 厂商让我们不再为数据库切库、扩容、分库分表、主从架构而劳心劳力，起早贪黑，但是程序的性能问题，过去、今天、未来，仍将一直存在！

虽然 BaaS 厂商，已经为我们做好了各种接口，但是在面对海量访问成长时，接口调用的扩展性是我们不得不去重视的一个问题。

虽然这一切都已经很不错，而且会趋于更好，但是成长到一定程度，或者发展特定的业务，我们仍然需要 PlanB ！云端安全、隐私等，对于某些特定的服务，仍然是一个关键的问题。因而，无论过去、现在、将来，监控仍然是一个互联网产品应该重点去关注的问题。

虽然 SaaS，BaaS，PaaS，IaaS 厂商为我们提供了方便的服务，但他们封装的那些计算能力是否能满足我们对可用性和效率的要求呢？所以针对不同情况的监控就很有必要。下图展示了云厂商封装的计算能力：

所谓监控，就是在平时的产品运行的时候，以一定的频率收集数据，当问题发生的时候，也能第一时间发现、报告和协助处理问题。监控的方面很多、维护也很多，作用也很大。

从架构的角度来讲，监控包括系统资源的监控、网络相关的监控、应用服务的监控，以及代码开发层面的监控和安全监控等。 从用户的角度来讲，监控包括了不同终端，不同网络环境，不同时间段的监控。

监控的作用也非常地大，无论是对于项目负责人，还是对于开发人员，了解和得到自己关心的一面很有帮助，就更不要说运维工程师本人了。

本文就来讨论在独立服务器或者 IaaS 环境下，我们需要对服务器和服务进行哪些监控？

系统资源的监控

所谓系统资源，就是硬件设备在操作系统中的表示。比如在操作系统中，可以看到CPU、内存、磁盘、网卡等的使用情况。下面稍加展开。

CPU：

说到这些资源的监控，我们可以想得很简单，但是也可以想得很详细。比如一般情况下，我们监控 CPU 资源就监控负载，说到负载，可能大部分研发出身的朋友，都只知道概念，而不知道由来，负载的意思是单位时间内运行队列中就绪等待的进程数平均值。只记录负载是最粗粒度的做法，但是要做得比较细致，光 CPU 这一项，就可以拆出来10多项指标。在 Zabbix 监控系统中，CPU 有13项数据收集指标，分别是：

1. 每秒上下文切换数
2. CPU nice 时间
3. CPU user 时间
4. CPU system 时间
5. CPU iowait 时间
6. CPU interrupt 时间
7. CPU Idle 时间
8. CPU softirq 时间
9. CPU steal 时间
10. 每秒中断数
11. 处理器负载（1分钟平均）
12. 处理器负载（5分钟平均）
13. 处理器负载（15分钟平均）

并对5个和第11个指标进行了报警监控。以上 CPU 的时间数据，可以使用类似 mpstat 命令获取到:

内存：

一般监控可用内存和交换分区。并对总内存数据等指标进行记录。

磁盘：

分为磁盘本身和文件系统。磁盘本身包括各个分区的使用率、RAID 状态监控、每秒读写量以及相关 CPU iowait 等指标。而文件系统，则经常出现的问题是只读状态。如果是大量小文件的存储系统，对 inode 的使用也可以统计。

网卡：

网卡主要是流量的监测、以及网卡本身的速度，1000Mb/s 网卡速度降级的情况，也偶有发生，需要加以留意。

网络相关的监控

网络虽然也是资源 ，但是不完全是系统资源，值得花一整段来进行介绍。

网络最先要做的是连通性监控，没有连通，无所谓网络。连通性监控，咋一看简单，不就一个 ping 就搞定了么？是的，有道理，但也不完全全面。有道理的是 ping 确实能帮我们探听联通性的问题，但是光一个节点，还不成，我们需要将探测节点分布在更多的机房。连通性，也不仅是 IP 的连通性，在一定程度上，域名的连通性更为重要，毕竟用户和调用，都是通过域名来的，在域名监控的时候，不见是汇报各个结点的连通统计，还有非常重要的一点是针对运营商进行分类汇总，以统计各个运营商的服务情况，以及时地发现骨干网和运营商的故障，在监控指标方面，响应延时和丢包需要重点加以关注 。

其次就是流量监控，也就是带宽的监控，带宽监控包括交换机、网卡（包括内外网）、CDN、IDC 出口等的带宽监控，如果带宽不足，会出现网络拥堵，进而去发现和解决问题。

对于网络的监控，除了从站方或者提供商的角度来监控之外，还需要从用户的角度来收集数据。可以在页面上采用内嵌JS代码的方式来收集到页面的响应速度，资源（图片、视频）的下载速度等，尽管这些数据，大多与性能分析版块相关，但是对于网络监控版块，也是重要的参考指标，尤其是按地域等维度进行网络分析时。如下是腾讯的全国网速监控图表。可以宏观地把握各地区的网络质量。

应用服务的监控

应用服务层面的监控，指的是各种应用后端运行赖以存在的进程以及相关监控，并且随着服务器角色的不同，监控的内容和对象均不相同，以 LNMP 架构为例，可能包括：

1、MySQL 数据库的监控，MySQL 数据库要监控的东西也是可多可少。在 Zabbix 中，提供了 15 项监控指标。

尽管看起来15项指标不少，实际上并不完全，比如 MySQL 的缓存、临时表、线程数，也是应该非常关注的，如果涉及到主从架构，主从同步延时的监控绝对是重中之得。从大的层面上来讲，像备份成功与否的监控，也至为关键。

2、对 Web 监控，则从几个方面入手，最基础的包括进程是否存在，Apache 的话要计算进程数，php-fpm 也要计算进程数，端口，无论是80，还是9000端口是否能连通。其次就是程序本身的错误日志和可能的出错情况了。而出错情况，又体现为 HTTP 的各种状态码，404、500、502 这样的错误是非常常见的错误，403、503错误也要加以关注，并且需要对这些出现的量做出比较长期的统计曲线，如果某一段时间，某个状态码与正常范围发生了较大幅度的偏离，则是需要加以注意的。

在 Web 的监控中，除了服务器端指标之外，最常用的是 URL 监控，通过 URL 监控能从用户的角度，反馈很多的数据，而 URL 的监控又分为纯粹 HTTP 请求的监控和 JS 的监控。针对移动 App 的 API，只需要通过调用 HTTP 请求来监控，而 Web 前端和 HTML5 前端的响应和交互 ，则需要依赖强大的 JS 进行各种数据的返回。URL监控，也能得到服务器端类似的一些数据，比如 HTTP 状态等。如下是一个典型的 URL 监控报表。

3、其他服务，除了数据库和 Web，余下的各种服务，也同这两种服务一样，异同各半。同在一般都涉及到端口和相关日志的监控，而异呢，则是各个服务，都有自己的业务不同：

比如 Memcached，我们会去监控命中率，缓存大小，请求量等.

对于验证码服务，会去监控成功率，同一个 IP 或者来源的使用量

对于注册登录服务，会去监控登录成功与失败的比例，会监控注册用户的变化，注册用户中使用临时邮箱的比率，甚至于关注用户账号不存在的数据，以发现社会工程学攻击等等。

对于邮件服务器，需要监控邮件队列中压的邮件，成功率等数据，成功率还需要细分到邮箱后缀。

总而言之，各种服务的监控，是一个繁琐的，需要良好规划的工作，否则，千奇百怪的监控代码，让运维人员陷入了泥潭，而且效果不好。

前面的这些监控，虽然也是用代码写成，但是跟代码基本上不会有耦合，并且有独立的服务和工具来完成对数据的监控统计，比如 Zabbix 就是笔者所不吝于去推广的优秀项目，推荐给真正实战运维和监控的朋友使用，Zabbix 监控界面如下：

代码层面的监控

上面的这些监控，看起来，跟开发人员关系不是那么的密切，即使监控发现问题，也先是运维处理问题，然后再转为开发人员处理问题，比较少能直接定位为开发人员需要处理的问题。但是近年，两个概念，在互联网业界冒了出来，一个叫 DevOps，一个叫白盒运维，其实两个意思差不多，说白了，就是搞运维的要懂得开发的是咋回事，做开发的，也要去明白运维，从而快速，紧密地做优化和解决问题。理想是美好的，如果自己去埋代码，会把代码写得比较乱，对于某些有洁癖的领导，为了统计和监控，加入一大堆代码，有点实在心里梗梗的。另外，同时要兼具运维和开发的全栈工程师，毕竟也是少数，所以一个新的行业却如火如荼地发展了起来，这就是 APM。

APM 全称是应用性能管理，也就是能将程序的监控，不再局限在程序的外围系统和服务上而能将监控深入到代码的层级。具体的技术实现是安装 APM 厂商所提供的探针，他们就一切都帮你做好了，不用安装 Zabbix 这么复杂的程序，不用去埋代码，所有的结果就都在云端。甚至笔者都以为，有了探针这个东西，其他监控也是能做的啊，有木有!!!怪不得最近又出了一个全栈式监控的名词。见新闻《阿里云联手 OneAPM 全栈式性能监控服务》。说到 OneAPM，笔者用的产品也正是他们家的，这是国内第一的 OneAPM 厂商，功能也相当地强大，以 PHP 为例，只需要安装探针，一切数据就尽在掌握了。

OneAPM，在不埋代码的情况，能知道你的哪个 SQL 可能慢了。存在问题。这简直颠覆了笔者之前的监控认知。让开发和运维的鸿沟一下子变窄了数倍。

至于OneAPM 怎么安装和使用，笔者就不再介绍了。大家可以上 OneAPM 的网站上去使用，如果不知道咋使用，可以尽量地骚扰他们的技术支持人员，呵呵。

其实监控，真的是一个大话题，上面说了这么多，只是大概地解释了有哪些应用上的监控类型，现在来探讨最后一个主题，安全监控。

安全监控

所有的监控，都是为了快速发现服务中的异常，并对异常设置一定的阈值范围，并设置一定的报警状态。比如单 CPU 负载在2以上是黄色报警，如果在5以上，就要红色报警了。而在所有的异常之中，有一种异常，非常的重要，也非常地特殊，那就是安全。

安全的监控分为内部安全问题的发现和外部安全问题的防攻击。在前面也或多或者少地提到了，比如验证码和登录注册服务的监控，已涉及到了业务安全。

大部分安全问题，都是堡垒从内部攻破的，所以内部的安全问题发现和监控就变得非常地重要。比如 Web 漏洞中的 XSS 跨站攻击、SQL 注入攻击、缓冲区溢出等，无一例外是内部的问题。所以通过工具扫描和发现安全问题就变得非常重要。现在比如 360 提供了 Web 网站安全检测工具，可以部分地发现问题。但是更多的问题，比如 XSS 和 SQL 攻击的问题，还是需要内部开发人员在输入输出方面，做更多的控制 ，要么过滤，要么转义。

而像域名劫持和 DDOS 攻击，则是需要借助自己或者外部的力量来处理了。域名劫持，可以通过 JS 监控来发现。在 JS 中检测所有资源的 URL，看看是否在当前服务提供商合法的域名资源范围内，否则则为劫持。而 DDoS 的攻击则需要专业的厂商来提供支持，比如腾讯云提供防 DDoS，而专业的防 DDoS 厂商如青松抗 DDoS 也是不错的产品。

而对于内部敏感信息的检测、代码篡改的检测，则更多的是一个内部审计的问题，无非是内容分析或者是文件签名分析，并没有太大的难点。

在云计算时代，尽管云厂商为我们提供了各种各样的服务，但是为了服务的质量，DevOps 监控仍是一个需要相当关注的话题，也由于有 Zabbix、OneAPM、专业安全厂商的存在，也让开发和运维的工作更加轻松，更加少地扯皮。以上分析了服务和服务器中，需要监控的五大类别：系统资源、网络相关、应用服务、代码层面、安全问题，希望能引起大家对于监控的重视，防患于未然。

备注：以上文章，参考了《构建高性能 Web 站点》(郭欣)、《Python 自动化运维技术与最佳实践》（刘天斯）、《海量运维、运营规划之道》（唐文）等书籍，并采用了网络上部分截图。本文系优才学院原创文章。