企业级业务系统的360度立体监控

无论是什么样的业务系统，监控是绕不开的，甚至可以说是很重要的，阿里云应用实时监控ARMS，是一款应用性能管理（APM）产品，包含应用监控、Prometheus监控和前端监控三大子产品，涵盖分布式应用、容器环境、浏览器、小程序、APP等领域的性能管理，实现全栈式性能监控和端到端全链路追踪诊断，让应用运维更加轻松高效。本文主要介绍如何使用ARMS实现对部署在阿里云上的业务系统的360度立体监控。

名词解释

1. ECS：云服务器ECS（Elastic Compute Service）是阿里云提供的性能卓越、稳定可靠、弹性扩展的IaaS（Infrastructure as a Service）级别云计算服务。云服务器ECS免去了您采购IT硬件的前期准备，让您像使用水、电、天然气等公共资源一样便捷、高效地使用服务器，实现计算资源的即开即用和弹性伸缩。

2. SLB：负载均衡SLB（Server Load Balancer）是一种对流量进行按需分发的服务，通过将流量分发到不同的后端服务来扩展应用系统的服务吞吐能力，并且可以消除系统中的单点故障，提升应用系统的可用性。

3. NAT网关：NAT网关（NAT Gateway）可以提供网络地址转换服务。阿里云提供公网NAT网关和VPC NAT网关两款产品。公网NAT网关提供公网地址转换服务，VPC NAT网关提供私网地址转换服务，您可以根据业务需求灵活选择。

4. EIP：弹性公网IP（Elastic IP Address，简称EIP）是可以独立购买和持有的公网IP地址资源。目前，EIP支持绑定到专有网络类型的ECS实例、专有网络类型的私网SLB实例、专有网络类型的辅助弹性网卡、NAT网关和高可用虚拟IP上。

5. RDS：云数据库RDS MySQL 版是全球最受欢迎的开源数据库之一，作为开源软件组合 LAMP（Linux + Apache + MySQL + Perl/PHP/Python） 中的重要一环，广泛应用于各类应用场景。

6. ACK：容器服务 Kubernetes 版（简称 ACK）提供高性能可伸缩的容器应用管理能力，支持企业级容器化应用的全生命周期管理；

7. ARMS: 阿里云应用实时监控ARMS，是一款应用性能管理（APM）产品，包含应用监控、Prometheus监控和前端监控三大子产品，涵盖分布式应用、容器环境、浏览器、小程序、APP等领域的性能管理，实现全栈式性能监控和端到端全链路追踪诊断。本文主要介绍如何使用ARMS实现对部署在阿里云上的业务系统的360度立体监控。

前置知识

需要说明的是，实践本文所述业务系统的360度立体监控，您需要了解docker 基础、k8s基础、mysql基本使用、Redis基本使用、java基础，对于这些方面的知识，无需深入，能够使用即可实践。

为什么需要监控？

最早的互联网应用监控系统诞生在90年代，经过近30年的发展，现在的监控系统已经是非常复杂的分布式系统了，它通过多种手段收集应用、服务器、中间件、Pass平台的系统行为信息，通过收集到所需的数据指标，帮助分析生产问题、性能问题，并在指标超过正常值时报警。

因此，我们可以知道，监控系统就是观察业务系统的工具，它也有了更时髦的叫法，可观测。

其实监控系统的价值主要有如下两点：

1. 预防故障，比如当基础资源的使用到达一定的水位之后，需要及时介入处理，否则可能会引起故障，这个介入可以是人工介入，这就需要配合告警，也可以是自愈，自动化运维、智能运维。

2. 当问题发生时，能够提供基础的信息，大致定位到是操作系统、应用、中间件等什么地方出问题了，比如页面加载慢，能够知道具体出问题的范围。

当然，除此之外，监控系统还有其他的作用，比如预测资源趋势，实施AIOPS；黑盒关注用户体验，及时接入处理等。另外，本文主要讲解监控，对于告警，告警并不是简单的发消息到对应的群或者发短信到对应的人，它和企业的组织结构相关性很强，本文不做深入讨论。

做监控时，都需要监控什么？

我们理解了监控的重要性，那么做监控时，都需要监控什么呢？也就是说，我们的监控对象主要有哪些呢？脱离业务系统谈监控其实不太现实，我们本次实施监控的业务系统部署在阿里云上，网络拓扑如下：

​

该业务系统是一个前后端分离博客系统，总共分为三部分，blog-api是后端应用，使用到了MySQL和Redis；blog-cms是使用vue实现的后台管理系统的前端，调用blog-api的接口；blog-view是使用vue实现的博客系统前端，调用blog-api的接口实现相关逻辑。项目地址：https://github.com/aclouddemo/nblog

这是一套非常简单的业务系统，但是它已经包含了大部分常见的业务场景，MQ与RPC暂时不涉及，不过操作方式和Java应用是一样的。下面，我们就基于这套业务系统，讨论监控系统的实施方案。

针对此业务系统，我把监控对象分类如下：

1. 基础云资源，主要包括ECS、SLB、NAT网关、EIP、RDS数据库、Redis。

2. ACK容器服务，主要包含k8s集群以及Ingress、CoreDNS在内的其他关键组件。

3. 业务应用系统，从页面到数据库的数据全链路追踪。

4. 其他，这类暂时不知道如何分类，但是很重要，比如NTP Offset、站点入口流量、站点状态、关键接口的状态、SSL证书等。

​

针对基础云资源的监控需要监控的指标

云资源当前已然成为一种是基础设施，基础不牢地动山摇，在该架构下，基础云资源主要包括ECS、SLB、NAT网关、EIP、RDS数据库、Redis。

1. ECS的主要监控指标有：CPU、内存、磁盘、网络、文件打开数等方面的指标。

2. SLB的主要监控指标有：收发包、连接数、QPS、状态码等信息。

3. NAT网关的主要监控指标有：连接速率、并发数、出入流量等方便的指标。

4. EIP的主要监控指标有：数据包数、带宽等方便的指标。

5. RDS 数据库的主要监控指标有：CPU、内存、磁盘、连接数等。

6. Redis的主要监控指标有：CPU、内存、连接数等。

最终监控效果见视频。

针对ACK容器的监控需要监控的指标

Google自2014年6月7日发布k8s至今接近有8个年头，它已经成为事实上的编排平台的领导者、下一代分布式架构的代表，其在自动化部署、监控、扩展性、以及管理容器化的应用中已经体现出独特的优势，也是实现云原生基石。在k8s容器相关的监控上，我们梳理了如下监控对象：

1. API server 核心指标监控。

2. Controller Manager 核心指标监控。

3. etcd 核心指标监控。

4. Scheduler核心指标监控。

5. coreDNS 核心指标监控。

6. Ingress 核心指标监控。

7. Node、deployment 、Daemonset、StatefulSet、Pod 核心指标监控。

最终监控效果见视频。

针对业务应用系统的监控需要监控的指标

基础云资源的监控和ack容器的监控已经很复杂，但一些应用问题依然观测不到，比如一个接口偶尔访问慢了，如果观察基础云资源与ack容器，发现都很正常，如何知道具体哪里出问题了呢？这时候就需要从页面到数据库的全链路分析，缩小问题范围，再具体分析，针对业务应用系统的监控，我们需要监控的资源与指标如下：

1. 前端页面监控：Js错误数、页面访问速度、页面加载分析、会话追踪等，其中会话追踪可以把页面到数据库的整个请求串起来。

2. 后端应用监控：请求数、响应时间、jvm监控、线程池监控、SQL调用分析、NoSQL调用分析、请求调用链等。

最终监控效果见视频。

其他

除了上面的监控，其实还有一些其他的重要监控对象，它们发生问题的概率比较低，但是问题发生时也会造成很大风险，比如站点状态、关键接口的状态、NTP Offset、SSL证书等。

集成监控的实施

到这里，我们已经梳理完了所有的监控对象与相关的指标，这些监控对象对于一些复杂大型高并发系统来说，还有没有覆盖到的地方，但是对于大部分业务系统来说，实际上已经足够了，下面，我们先搭建相关环境，然后针对这个业务系统实施具体的监控，其实环境搭建完成，监控也就差不多了。

创建ack环境

1. 登录阿里云控制台，进入容器服务 Kubernetes 版，创建k8s集群。（如果已有集群可跳过，确保集群已安装阿里云arms-promethues即可）。集群配置和节点配置用户自定义即可，保证ACK/RDS/Redis在一个VPC下就能够正常工作，组件配置需要暴露公网ingress并且勾选使用Promethues监控服务，如下图：

完成相关操作后，等待几分钟，集群即准备完毕。

1. 点击集群列表中的名称，进入k8s集群管理页面，copy k8s 访问凭证，将相关信息保存到计算机 $HOME/.kube/config 文件中以备后续使用。

2. 至此，集群部署完成，使用kubctl工具连接集群，可以发现集群内已经有基础组件的pod和其他相关pod启动。

部署该业务系统：

创建RDS:

1. 创建RDS的过程比较简单，选择mysql 5.7 创建即可，需要保障RDS和ACK在一个VPC下。

2. RDS创建好之后默认白名单是127.0.0.1，不支持外部连接，需要修改RDS白名单为VPC内网网段。

3. 创建RDS用户，供业务应用使用。

4. 最后，保存用户名密码与内网连接地址，后续需要配置在应用中。注意：实践中发现Promethues不能获取到node节点数据，

创建Redis:

1. 创建Redis的过程和创建RDS的过程类似，也需要保障Redis和ACK在一个VPC下。

2. 创建完成后，确保白名单能够支持内网连通，需要保存密码与内网连接地址。此处不做过多介绍。

创建基础云资源监控

目前为止，我们已经完成了基础云资源的创建，现在就可以把他们全部监控起来了。

1. 创建基础云资源监控

2. 选择监控ECS、SLB、NAT网关、EIP、RDS、Redis，然后创建。

部署应用：

好了，到这一步，基础云资源已经准备完毕，下面我们给前端接入arms前端监控，后端接入arms应用监控，再把前后端链路串联起来，最后部署到k8s中即可。

1. 前端应用接入arms前端监控，并编译成docker容器

2. 第一步，先创建两个前端站点，blog-cms和blog-view:选择web&h5，并点击新建

3. 第二步，复制相关代码，分别配置相关信息到blog-cms和blog-view的src/main.js，此处以blog-cms举例：

1. 后端应用接入arms应用监控

2. 后端以手动的方式接入，下载探针后，在JVM参数中加入相关配置，见blog-api的Dockerfile

1. 前后端链路打通

2. 前后端链路的打通依靠网关传递相关的HTTP Header，在前端监控的配置里面，配置enableLinkTrace为true

3. ingress-nginx 配置 enable-underscores-in-headers: "true"，这个当前ack版本默认是配置好的。

1. 导入mysql数据

2. 连接mysql并创建数据库。

3. 把blog-api项目下的nblog.sql导入数据库。

1. 部署应用容器到ack

2. 确认前端blog-cms和blog-view配置好前端监控，前面已经完成。

3. 在blog-api配置文件中配置好mysql和Redis相关信息

4. 分别到3个项目下执行docker build . 构建 docker image 并上传到镜像仓库。

5. 使用每个项目目录下k8s-app文件部署k8s应用，需要修具体的镜像地址，如果镜像不能在公网访问，需要在k8s中配置好具体的secret，部署成功后应该如下：

部署ingress，修改本地host：

应用部署完成后，需要对外暴露服务，实际上ingress已经暴露服务了，但是要正常访问到ack中的应用，需要配置好路由和host。另外，由于没有准备备案的域名，当前先直接使用aliyun.com域名，并且在本地修改host。

1. 配置ingress，具体文件在项目根目录的ingress.yml，节省篇幅，此处不贴图

2. 部署ingress，使用 kubectl apply 命令部署ingress。kubectl apply -f ingress.yml

3. 修改本地host查看ingress的外网IP配置三个host解析

1. 到这里应用就部署完成了，访问http://blog-view.aliyun.com/home 和 http://blog-cms.aliyun.com/dashboard 可以看到效果。

其他监控-黑盒监控

这里使用 ACK Service 巡检演示其他监控，事实上，黑盒监控可以覆盖站点状态、NTP Offset、SSL证书，HTTP，TCP，DNS等，具体参考：https://github.com/prometheus/blackbox_exporter 。至于NTP Offset，可以参考：https://github.com/sapcc/ntp_exporter ，它可以检查节点上时钟相对于给定 NTP 服务器的漂移。黑盒监控暂无演示视频。

到这里，我们的业务系统就算基本搭建完成了，来看看监控效果吧。

监控效果展示

因为页面实在太多，这里就请欣赏视频。

1. 基础云资源监控效果演示说明：

   1. slb有些指标没有数据，是因为当前创建的SLB为4层负载均衡，相关数据是7层负载均衡数据指标。

2. ACK容器监控效果演示

3. 从页面到数据库的全链路监控演示​

监控的告警

1. 常见的告警规则进入promethues的告警规则页面，其中包含了63种告警规则：这里面基本上涵盖了常见的场景，可以在此基础上增站点入口流量、站点状态、关键接口的状态、NTP Offset、SSL证书的告警规则即可。

2. 告警通知是一个定制化很高的话题，因为不同组织下需要通知的逻辑差别很大，很难形成统一的规则，举个例子，技术部分运维、开发，要求告警全部通知到运维，业务线相关告警要通知到具体业务线，晚上21点钱短信和IM通知，21点后电话通知，这就需要多种通知策略互相配合，因为告警的复杂性，比较难使用较短的文字说清楚，可以参考构建高效精准的告警协同处理体系，此处不再对告警通知展开。

总结与展望

这一套方案里面，监控主要使用的是arms这个产品，arms的应用监控，在阿里内部叫鹰眼，历史久远并且已经支撑了多年双十一。arms的promthues更多是在社区的基础上做适配，当前已经支持了主流的阿里云产品，尤其是我后面看到了promethues团队总结的告警规则，可以说是往前走了一大步，大大降低了用户的使用成本。

实际上，这套监控方案对一些不复杂的项目来说有些重了，很多企业业务的压力不大，业务的连续性要求不高，很多时候不需要这么复杂的监控方案，但是它依然具有一定的参考性，可以在这个方案上做一些取舍，比如去掉应用链路追踪，或者做成实时开启关闭的模式，需要时再开启，这就很完美。另外，细心的读者应该发现，云基础资源的监控和ACK容器的监控有重叠，也可以自行取舍。

关于监控的未来，其实没有想到太多，可观测一呼百应，已初显锋芒，当前几乎成为云原生的标配了。AIOPS是比较热的一个方向，监控的海量数据结合大数据与人工智能，自动判断故障范围或者直接修复故障，但AIOPS的核心是通过大数据判断问题，然后做决策，当前很多业务系统只是通过简单的策略，也可以实现自动处理问题降低故障，那AIOPS到底是不是个伪需求呢？交给时间吧。