一、文档概述
1.1 概述
1.2 原理/核心思想
1.3 内容
1.4 应用场景
1.5 术语解释
二、监控
2.1 为什么要监控
- 线上发布了服务，怎么知道它一切正常？
- 某个核心服务挂了，导致各级系统大量报错，如何确定问题在哪？
- 系统上线后不知道业务进来多少，不知道服务器是否够用
- 业务搞大促，请求量激增，我们居然是最后一个知道问题的人
2.2 监控什么
MonitorWhat.png
2.3 内容
2.3.1 硬件指标
HardwareMonitor.png
- CPU Idle Time（CPU空闲时间率）
- Free Memory（空闲内存数）
- IO Wait（等待IO返回执行时间。如果IO Wait很高，说明应用响应速度会被IO拖死，对应的IO属于密集型操作，是不是有太多数据读写请求，从磁盘上取数据的请求，对应IO Wati的时间就变得非常高。IO Wait越少越好）
- Network free（大多数分布式应用的调用，都需要用到局域网内的网络调用；网络的带宽是否足够用，对应从Redis缓存当中set、get数据都要通过应用服务器到Redis中间的网卡，对应Network free的容量意味着能否将对应的数据传输过来。不好的Case，一个Redis的get操作居然用到了100ms，甚至1s。但是Redis Server和对应的应用服务器所有的容量状态都是正常的。那么我们就要查下对应的网络带宽是否被打满，导致对应的数据传输不过来）
2.3.2 软件指标
- Cpu Load Average（1核CPU上，超过1，是高load; 2核CPU上，超过2，是高load; CPU的load很高的话，意味着CPU长时间处于忙碌状态，需检测对应的容量）
- ParNewCount（新生代GC清理次数，不需太多的关注。新生代发生GC，比较正常）
- ParNewTime（新生代GC清理时间，一般来说越快越好）
- Old GC Count（年老代GC的count，一般对应Par GC数量）
- Old GC Time
2.3.3 Zabbix 监控图标
Zabbix.png
上边的一条线表示CPU Idle Time比较平稳，正常，维持在70%-80%。
下边的红线表示CPU Idle Time很长一段时间接近0，需要检查对应的系统容量是否够使用。
