在云计算时代，如何监控云服务的 SLA ？（在云计算时代,如何监控云服务的网络）

在云计算时代，如何监控云服务的 SLA ？（在云计算时代,如何监控云服务的网络）

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

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

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

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

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

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

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

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

系统资源的监控

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

CPU：

每秒上下文切换数 CPU nice 时间 CPU user 时间 CPU system 时间 CPU iowait 时间 CPU interrupt 时间 CPU Idle 时间 CPU softirq 时间 CPU steal 时间 每秒中断数 处理器负载（1分钟平均） 处理器负载（5分钟平均） 处理器负载（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 的缓存、临时表、线程数，也是应该非常关注的，如果涉及到主从架构，主从同步延时的监控绝对是重中之得。从大的层面上来讲，像备份成功与否的监控，也至为关键。

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

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

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

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

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

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

代码层面的监控

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

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

安全监控

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

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

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

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