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: 异常数据监控

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

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

https://www.tuicool.com/articles/fyQv2uf