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

格心
  • 收获赞:43
  • 擅长领域:爱折腾,拥有Android应用、linux内核驱动、移动机器人、web后端服务多领域线上应用实战经验。擅长领域:架构设计、中间件技术、IT治理、性能优化、三高系统

介绍如何使用ARMS实现对部署在阿里云上的业务系统的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;黑盒关注用户体验,及时接入处理等。另外,本文主要讲解监控,对于告警,告警并不是简单的发消息到对应的群或者发短信到对应的人,它和企业的组织结构相关性很强,本文不做深入讨论。

做监控时,都需要监控什么?

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

image.png

该业务系统是一个前后端分离博客系统,总共分为三部分,blog-api是后端应用,使用到了MySQLRedis;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监控服务,如下图:image.png

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

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

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

部署该业务系统:

创建RDS:

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

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

  3. 创建RDS用户,供业务应用使用。image.png

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

创建Redis:

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

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

创建基础云资源监控

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

  1. 创建基础云资源监控image.png

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

部署应用:

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

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

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

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

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

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

  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相关信息image.png

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

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

部署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的外网IPimage.png配置三个host解析

image.png
  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种告警规则:image.png这里面基本上涵盖了常见的场景,可以在此基础上增站点入口流量、站点状态、关键接口的状态、NTP Offset、SSL证书的告警规则即可。

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

总结与展望

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

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

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