当前应用的API读写比是多少，对应到各个存储层面的比例是多少。当应用QPS上升，哪个依赖最先挂掉。redis/mysql 还是依赖的服务，还是应用本身。
定期盘点无论是用户反馈故障，还是监控警报，基本都晚了，因为这时候已经累积了一定错误量的调用了。所以需要再抢先一步，定期盘点应用。衡量的指标一般围绕使用率、饱和度、吞吐量以及响应时间
盘点的内容包括所有的依赖。
应用层面
磁盘cpu，内存，load数，jvm gc情况
系统层面
qps
依赖的存储
磁盘，cpu, IOPS， qps。
消息队列
消费速度是否正常
另外系统日志是第一手的故障信息来源，应用owner需要定期对错误日志进行查询，能够有效的将潜在问题扼杀在摇篮里。
监控警报监控警报有助于提早发现故障，所以确保监控项完备，警报能够有效报出来。
以下是常用的一些监控项
主机状态 磁盘使用率>85
主机状态 5分钟load > 核数*1.5
主机状态 5分钟内存使用率 > 80
主机状态 5分钟CPU > 50
API 5分钟API错误率>0.1
SQL 慢查询 耗时>100ms
日志 1分钟错误数>10
日志 5分钟错误数>50