监控系列讲座（八）从上到下思考监控架构

2. 从上到下思考整个架构

这里包含下面几个问题

• 什么系统需要监控
• 使用什么软件来监控
• 监控软件应该使用怎样的结构才能满足要求
• 常见的监控指标
• 性能调优

2.1. 什么系统需要监控

一般来说，运维工程师常见的，需要被监控的系统有

• 物理机：这里面有两个部分，一个是操作系统，一个是管理控制台（HP-ILO，IBM PC-AMM，IBM小型机-HMC）
• 虚拟机：有三个部分，一个是虚拟出来的Host，一个是hypervisor的软件（比如vmware-vSphere，redhat-ovirt），最后同样需要监控管理控制台
• 公有云主机：基本上每个公有云供应商都会提供一套监控，但是略微有差别，比如AWS默认是不会在系统中装agent的，所以如果不手动安装agent，监控的指标是有限的，但是像阿里云，默认是在系统中装agent的，所以监控指标比较全面
• 存储设备：如果是使用分布式存储，比如ceph之类的，可以按照监控主机和监控应用一样来对待。如果使用的是存储设备，比如3PAR，HPE或者IBM-DS之类的存储，那么就需要在选购存储的时候，把监控的问题考虑进去，因为存储其实是一个定制化的操作系统带一些特殊的raid卡，然后插满磁盘组成的，所以操作系统上可不可以安装agent或者是不是能暴露一些metrics就成了监控的关键。
• 网络设备：一般来说，网络设备是无法安装agent的，我们想要监控就需要使用snmp协议对网络设备进行监控，当然，也有一些高端设备是自带监控api的，可以使用一些软件去采集。
• 容器/编排工具的监控：对于这种动态的系统，我们监控的时候就需要考虑到我们的监控系统也应该是适用于动态环境下的监控。pod是随时销毁和创建的，如果我们手动安装agent，那么这对于运维来说，绝对是最痛苦的。
• 工具的监控：这里说的主要是指公司内部的系统，比如DevOps系统（jenkins，gitlab，harbor）和办公系统（Sap系统，office系统，邮件系统）
• 应用的监控：这应该是最难的一部分，这涉及到了4个黄金指标中的3项，延迟，错误率，流量。延迟是说系统的响应速度，错误率是说响应的错误率，流量是说QPS之类的逻辑指标。

2.2. 需要什么软件来监控

这一部分其实是最能体现工程师的水平的，没有一款开园软件是适合所有场景的，如果我们不想自己开发，那么可能在整个的系统中会用到非常多的监控。但是，首先我们先要了解为什么使用它。就好像你要求找老板申请budget，老板一定会问你why？如果想要你的方案被采纳，就一定要告诉别人way！这其中我做了下面几个场景的总结。

• 从网络来说，我们把软件分为pull和push模型，也就是服务器是主动找目标要资源，还是说目标主动把资源送过来。因为我们的生产环境基本都有防火墙，所以如果想使用pull的模式，就需要在防火墙上开端口。如果不开端口，我们可以考虑push的模式，让目标主动汇报自己的情况。但是这又有了另外一个问题，如果目标节点挂了，它就没办法push了，而一般的系统为了防止误报，都会有多次的重试，这样就会导致问题发现的不及时。
• 从协议来说，我们分为有agent和无agent的模型。有agent的，又分为http，tcp协议的。http一般是暴露metrics的方式，而tcp协议的一般都是C/S模型，监控软件自己基于tcp模型进行通信。无agent的，一般采用的都是snmp协议。
• 从动静来说，对于虚拟机这种不经常变动的目标，我们会采用脚本安装，或者初始化参数中写入一些命令来安装agent。但是对于k8s之上的一些容器，如果使用脚本或者初始化参数来安装agent，不仅会影响k8s的敏捷性，还会给系统带来不小的压力，我们就需要使用一些轻量级的，可以随时内部读取k8s状态的监控。
• 从展示图像来说，当然越漂亮越好，但是大部分监控软件自带的展示界面都丑爆了，比如我们前面说过的prometheus。而有些软件图像比较漂亮，但是只能支持自己的监控系统，没法集成多个系统。其实领导或者客户更希望一眼可以看到所有系统的状态，即使我们使用多个监控，展示的时候，还是尽量统一。
• 从花钱角度来说，我们要了解监控系统的社区版和商业版有什么不同，比如：Influxdb的单机版不支持集群，nagios的单机版不支持mysql数据库

2.3. 监控软件架构

选好了监控软件，就需要设计架构了。我总结的架构设计原则有

• 高可用，支持分布式，多节点数据可同步
• 可备份数据，可归档数据，最好支持读写分离
• agent要轻量，少占资源
• 接口要丰富，可以和其他系统集成
• 展示界面统一
• 管理简便，特别是升级agent的时候
• 支持自动化，自动化升级，自动化部署

2.4. 比较常用的架构

默认文件1594914906592.jpg

file

这个架构是一个比较理想的状态。右侧的这些基本都是或者自带监控平台，由于一些网络原因，或者兼容性原因，他们自身的平台是不可以跨平台，或者说一些软件只适用于某些场景，所以我们没必要使用一种软件监控所有的系统。但是，我们展示的时候还是希望能够统一界面，尽量满足最终用户（比如老板，开发，或者一线oncall人员）的体验，做到所见即所得。另外一个问题，也是目前没有太好的解决方案的问题就是报警平台。目前没有非常合适的开源报警工具，一些比较知名的工具，比如pageduty之类，都是需要额外收费的，所以基本上，报警还都是使用右侧各自工具的报警功能来做的。

2.5. 常见的监控指标

我们后面单独用一个篇幅来说这个问题

2.6. 性能调优

调优其实并没有什么定律，调的意思就是试，大到每个环境，中到每个版本，小到一个参数，都会影响整体的性能。我们需要抓住两个点。

• 针对架构调优。每种软件，或者每个解决方案的架构都是不一样的，我们调优的时候，就需要找到瓶颈。具体来说，就是针对系统中用到的软件，或者硬件调优，比如：网络，磁盘，CPU，内存；数据库，web应用，后端服务，agent等等。这些都有可能出现问题，需要我们调理。
• 针对固定参数调优。这个就需要了解整个软件的工作原理，比如：采用pull/push的方式时候的时间间隔，报警的时候的过滤规则。

监控系统的调优并不仅仅是指针对于响应速度的调优，还有客户体验的调优，比如，警报没有被及时处理，是否需要不停的报告；或者用户针对某个dashboard需要有钻取的功能，就是说，点击某个业务的监控之后，可以链接到另外一个页面，能够展示业务所关联的服务器的状态。这些都应该算是监控调优的一部分，而这些都是需要我们在熟练掌握了多种软件的使用的前提下才能做到的。
为了方便大家学习，请大家加我的微信，我会把大家加到微信群（微信群的二维码会经常变）和qq群821119334，问题答案云原生技术课堂，有问题可以一起讨论

• 个人微信
  640.jpeg

• 腾讯课堂
  640-20200506145837072.jpeg

• 微信公众号
  640-20200506145842007.jpeg

• 专题讲座

2020 CKA考试视频 真题讲解 https://www.bilibili.com/video/BV167411K7hp

2020 CKA考试指南 https://www.bilibili.com/video/BV1sa4y1479B/

2020年 5月CKA考试真题 https://mp.weixin.qq.com/s/W9V4cpYeBhodol6AYtbxIA