对业务系统的监控 No.118

这篇文章是写给想对目前的业务系统进行监控但是又不知道从何入手的小伙伴看的，又或者是对于现有监控机制的一个反思，具体为什么要做这件事情，可以参照一下下边这篇，结合着看看。

工程师们你们写完代码后还做些什么No.115

如下翻译，checkpoint -> cp

cp1 : 业务系统宿主机监控

现在一般系统都不直接跑物理机了，基本都跑在虚拟机或者容器上边，无论你们所谓的宿主机或者迁移做到多好，都要密切关注宿主机这块事情，很可能分分钟被其他业务或者宿主机本身把系统搞挂。一旦有异常必须关注起来，特别是机器数量比较少的时候，系统没发起自动迁移的情况下，及时迁移宿主机

大概需要关注的东西：宿主机网络、磁盘IO、CPU load、memory load

cp2 : 数据库监控

对于一个普通的业务系统来说，最重要的底层组件莫过于数据库了，根据我的经验，现在非常多业务并没有对数据库进行设计，所以一般情况下，数据库要是挂了，那么这时候业务系统通常来说就是直接不可用状态。数据库本身的容灾固然重要，但是数据库一般情况下来说，并不能识别哪些业务SQL是重要的，哪些是不重要的，它只能根据它固有的线程池、CPU、内存来提供一定量级的服务。

一旦发现有异常，一定要第一优先级介入，业务上进行限流，数据库层面SQL处理，比如强行kill慢SQL。

大概需要关注的东西：连接池、读/写RT(响应时间)、读/写QPS(每秒请求数)、CPU、网络IO、内存命中率、慢SQL

cp3 : 虚拟机或容器健康度

关注点跟宿主机一样，宿主机做了什么监控，这里就做什么监控。

cp4: 业务系统基础关键参数监控

对于虚拟机或者容器来说，可能一切都是正常的，但是业务系统上已经出现了大面积拒绝服务，大面积的响应超时，这时候其实可能已经出现了极大的问题，还需要结合一定的监控和排查才能发现问题所在。

大概需要关注的东西：HTTP RT(响应时间)、HTTP QPS(每秒请求数)、HTTP 空闲连接数。对于 Java 类系统来说还有JVM各种参数的监控，比如 各个代的gc时间、总gc次数和时间、堆内存、堆外内存、线程数 等。

cp5: 关键公共依赖系统的监

很多业务系统本身并不止有数据库，还有很多外部系统。比如 Redis、Memcached 这类外部缓存系统。比如类似 ElasticSearch 、 Solor 、阿里云 OpenSearch 这类搜索系统。比如Kafka 、RocketMQ、RabbitMQ 这类消息中间件。而且业务系统对于这些外部系统的依赖性一般来说还是比较高的，这类系统一旦出现问题，对于业务的影响也不容小嘘，很多时候也是致命的。

大概需要关注的东西：外部系统本身的稳定性监控，这类应该有专人维护，只需要要求他们做好监控，有任何告警订阅一下就好了。主要监控的还是业务系统本身对于外部系统的调用情况，比如连接池、读/写RT(响应时间)、读/写QPS(每秒请求数)、读/写成功率、网络IO。

cp6: 关键业务接口系统性监控

就算上边一切都是正常的，你系统可能还是崩溃的，为什么呢？可能你的系统早就拒绝服务了，返回了一大堆 isSuccess=false 的数据，这对于用户，对于业务方来说就是系统不可用，所以我们还要针对我们自己的业务进行一些业务层面的监控。一旦发现关键接口有问题，尽快介入排查原因，比如对于异常接口进行限流保障其他系统。比如对于关键接口的失败进行原因排查，尽快定位原因恢复业务。这块其实是很多人平时在写业务系统忽略最多的点，目前实现路径还是比较多的比如数据库实时查询，http连接实时检查、日志实时采集分析，业务数据准实时分析。

大概需要关注的东西：各个关键接口的成功率、RT(响应时间)、QPS。

cp7: 监控自动化和可视化

cp6做完善后，如果需要人实时盯着，其实用处也比较有限，还是要有一套机制自动化告警甚至自动化处理的机制。如果是正常轮班有人在盯着呢，最好是对于监控数据进行可视化。

cp8: 异常数据监控

业务流程处理是成功的，系统业务成功的，但是还是有一些隐患，比如数据不正确或者关键数据丢失。这类问题会出现在调用方或者某些代码分支出现问题的时候，一些关键数据丢失了，导致最终在进行客户履约的时候数据缺失。比如外卖丢了送货地址护着送货电话等，依然需要以自动化的形式做好异常数据监控。

大概需要关注的东西：关键业务节点的关键参数。

以上，吃面去了，饿了，你不点个赞吗？