# 变更记录
| 产品版本 | 更新内容 | 更新日期 |
| :------- | -------- | -------------- |
| V6.0.1 | 初始版本 | 2023年10月28日 |
# 1简介
## 1.1背景介绍
Monitor作为性能优化和故障排除的一个主要工具用来提高产品可用性、降低故障风险，Monitor 在V6.0.1围绕集群级监控、性能诊断、基础组件检测、告警、数据库监控等维度新增一些特性，进一步提高产品从故障发现到故障处理完成的效率。
## 1.2新增特性概览
| 序号 | 特性描述 |
| ---- | ------------------------------------------------------------ |
| 1 | 集群监控：支持批量服务实例节点同时进行指标监控、线程监控、TOP监控 |
| 2 | 火焰图：支持生成调用耗时，lock火焰图 |
| 3 | 基础组件性能检测：支持原子级能力检测 |
| 4 | 日志组件检测：支持日志ELK组件可用性和阻塞状态实时一键检测及系统日志丢弃量监控 |
| 5 | 告警增强：告警通知，支持企业微信、钉钉、云之家通知；告警处理策略，支持停止服务、暂停服务、重启服务 |
| 6 | 数据库SQL实时快照：支持批量查询数据库当前正在运行的SQL及SQL事件状态 |
| 7 | 数据库监控集成PMM：集成PMM(Percona Monitoring and Management)页面, 一种开源的数据库性能监控工具 |
| | |
# 2.特性使用说明
## 2.1 集群监控
1. 指标监控
- 特性价值：同时监控多个服务实例节点的JVM、SQL耗时统计指标，支持查询当前节点和历史节点任意自定义时间范围内指标，用于按需查看特定时间段指标更灵活
- 操作入口：【集群监控】->【指标监控】
- 使用场景：系统出现卡顿，从多个应用多个实例快速排查出那些实例JVM指标不太正常
- 使用案例：系统突然响应变慢，先看看WEB应用的指标，由于有多个实例从注册中心一个个看实例效率太低，按应用查看其所有实例指标，一键查询一步到位，快速排查出具体那些实例指标有异常用于进一步分析。
从上图监控图表对比分析，很直观清晰地发现IP为10.10.24.38的WEB节点发生GC的频率和耗时明显远高于10.10.87.120节点，快速找出下一步需要重点排查的实例目标。
2. 线程监控
- 特性价值：同时监控多个服务实例节点的线程堆栈，用于分析线程运行情况定位性能根因。线程监控提供新版的线程监控支持线程分类过滤和实例多选能力属于灰度发布阶段，支持更多的线程监控能力。
- 操作入口：【集群监控】->【线程监控】
新版线程监控操作入口：【集群监控】->【线程监控】页面“右下角”操作工具栏【体验新版】
- 使用场景：系统出现卡顿，从多个应用多个实例快速排查出阻塞线程定位出死锁、阻塞锁及卡顿方法
- 使用案例：线程监控分析方法和V.0一致，在这不再重复描述，请参考Monitor用户手册
如上图：新版集群线程监控新增【调度线程】、【其他】分类用于更精确查询线程，新增【线程运行时间】过滤用于快速查询目标时间的线程，新增【自动刷新】能力用于自动刷新提高线程监控效率，新增多实例选择能力按需批量监控实例线程运行状态和线程堆栈。
3. TOP监控
- 特性价值：同时监控多个服务实例节点CPU负载情况，用于快速排查CPU复杂高的服务实例及占用CPU高的线程
- 操作入口：【集群监控】->【TOP监控】
- 使用场景：系统出现卡顿，从多个实例快速排查出占用CPU高的线程分析是什么业务引起CPU占用过高
- 使用案例：突然响应变慢，排查CPU负高的服务节点实例及占用CPU高的线程
如上图：从每个实例的CPU使用情况，通过【宿主机信息】可以很快发现10.10.245.245BOS节点最近一段时间CPU基本满负载饱和运行CPU压力很大判断出瓶颈点在实例节点，再根据该节点JVM进程CPU、和线程CPU用量情况进一步找出哪个线程CPU消耗较大，结合线程堆栈深入分析根因。
## 2.2 火焰图
1. 调用耗时火焰图
- 特性价值：用于生成除CPU耗时外包含IO耗时、网络耗时、锁等待耗时的火焰图，用于分析由于IO、网络阻塞、锁竞争、死锁导致的性能下降问题，可以更全面的分析系统性能瓶颈，帮助开发人员和系统管理员理解在CPU等待时发生的事情，以便更好地优化性能。另外也有个名称【OFF-CPU】火焰图，详细概念请参考https://www.brendangregg.com/FlameGraphs/offcpuflamegraphs.html
- 操作入口：【性能治理】->【火焰图】，生成火焰图类型选择【调用耗时】
- 使用场景：
1. I/O等待分析：分析应用程序中的I/O等待情况识别在I/O操作期间CPU处于空闲状态原因如磁盘读写、网络请求等。
2. 锁竞争分析：识别哪些线程或进程在等待锁时导致CPU空闲，分析哪些函数或代码段涉及锁等待。
3. 系统调用等待：监测和分析应用程序中的系统调用等待情况，了解应用程序在执行系统调用时的CPU空闲时间。
- 使用案例：突然响应变慢，通过TOP监控发现CPU资源比较空闲，生成所有WEB节点调用耗时火焰图分析阻塞根因
步骤1、生成WEB调用耗时火焰图
如上图，选择WEB服务所有节点，下选择【调用耗时】类型生成火焰图
步骤2、生成成功后的火焰图如下，下图很直观的看到线程阻塞主要发生在网络等待上。
2. Lock火焰图
- 特性价值：Lock火焰图来更深入地分析锁的使用情况。Lock火焰图显示哪些线程或进程在使用锁，哪些锁被频繁竞争，以及锁的等待时间。建议优先通过【调用耗时】火焰图分析确定存在锁竞争或锁等待再生成【Lock】火焰图深入分析。
- 操作入口：【性能治理】->【火焰图】，生成火焰图类型选择【Lock】
- 使用场景：
1. 锁竞争分析：用于分析多线程的锁的使用情况。有助于识别锁竞争，锁等待时间和锁的使用情况，找出哪些线程等待哪些锁，以及哪些锁被频繁竞争。
2. 线程间通信：Lock火焰图也用于分析多线程应用程序中的线程间通信，包括锁定、条件变量等机制的使用情况。
- 使用案例
步骤1、生成锁火焰图
如上图，选择WEB服务所有节点，下选择【Lock】类型生成火焰图
步骤2、分析火焰图，生成后的火焰图如下图很，直观反应3个线程存在锁竞争，进一步分析代码SetQueue中存在对ReentrantLock的竞争使用。
## 2.3 基础组件性能检测
- 特性价值：V5.0版本组件检测是多个方法一起检测耗时，不能精准反应被检测组件每个方法的具体耗时，V6.0.1增强为对每个方法进行原子级性能检测，可以精准查看每个方法级具体性能指标。
- 操作入口：【基础组件】->【组件检测】
- 使用场景：系统出现卡顿，优先检测基础组件性能，判断是否由于基础组件存在性能问题导致
- 使用案例：系统登录突然响应变慢，对基础组件进行一波性能检测，发现具体组件具体方法存在性能较慢优先排查基础组件的性能问题。
如上图，可以清晰看到每个组件的每个方法原子级性能情况，从检测结果很容易发现DB上获取连接需要114ms是性能瓶颈，不过需要注意单次测试只是一次采样并不代表存在性能瓶颈，需持续手动刷新一段时间某个方法一直显示慢或超慢才基本确定存在性能问题再进一步针对性定位问题。
## 2.4 日志组件检测
V.0查询日志一旦发现查询不到最新日志或者查询的日志延迟较大甚至查不到日志，有可能日志被主动丢弃也有可能日志使用的ELK组件某个组件出现问题，无法了解到哪个环节出现问题没法做进一步处理会导致日志无法使用进而影响分析问题。
- 特性价值：日志组件检测支持日志是否配置完整性检测、Kafaka是否可用及消息堆积检测、LogStash基于Kafka消息消费和ES状态初步判断LogStash是否可用如果需要进一步获取精准结果可以在MC中配置logstash服务地址参数【monito.logstash.url】、ES可用及磁盘使用情况检测，提供整个链路的各个环节诊断，一旦发现问题方便运维人员及时针对性处理。
- 操作入口：【基础组件】->【日志组件检测】
- 使用场景：系统某个功能持续报错，需要从日志查看错误信息排查问题，结果却查询不到最近的日志
- 使用案例：日志查询查不到最近5分钟内的日志，手工触发日志组件检测，检测报告如下图，发现kafka存在消息验证堆积，ES磁盘使用基本使用完，可以很直观判断是ES无法写入新的日志数据导致的，可以通知运维对ES服务进行数据清理或增加存储空间恢复日志服务。
## 2.5 告警增强
1.告警通知增强
- 特性价值：增加企业微信、钉钉、云之家社交软件通知功能，降低客户告警成本提高告警及时性及告警通知多样化
- 操作入口：【告警管理】->【告警策略】
如上图，通过Webhook的API接入不同的社交软件，接入的3种社交软件Webhook地址查看帮助如下：
1. [企业微信Webhook地址查看帮助文档](https://open.work.weixin.qq.com/help2/pc/14931#%E4%BA%94%E3%80%81%E7%BE%A4%E6%9C%BA%E5%99%A8%E4%BA%BAWebhook%E5%9C%B0%E5%9D%80)
2. [钉钉Webhook地址查看帮助文档](https://open.dingtalk.com/document/orgapp/assign-a-webhook-url-to-an-internal-chatbot)
3. [云之家Webhook地址查看帮文档](https://open.yunzhijia.com/opendocs/docs.html#/tutorial/index/robot?id=%e5%88%9b%e5%bb%ba%e9%80%9a%e7%9f%a5%e5%9e%8b%e6%9c%ba%e5%99%a8%e4%ba%ba)
- 使用场景:邮件通知查看告警不方便，短信通知是收费服务对企业来说增加费用负担，使用社交软件通知对告警获取的便利性和实时性有极大提高同时降低企业费用，达到降本增效的效果。
- 使用案例：使用JVM堆内存使用率配置告警策略，告警通知使用云之家通知，效果如下图，清晰直观显示告警信息
2.告警处理增强服务行为
- 特性价值：基于告警支持对服务实例可用性进行降级、熔断保护或者快速重启提高服务的可靠性
- 操作入口：【告警管理】->【告警策略】
如上图，支持告警处理策略：无(不对服务做处理)、停止服务、暂停服务、重启服务，建议根据客户现场实际情况配置对应的处理策略。
- 使用场景：服务实例发生指标告警，对触发告警的服务实例进行处理
- 使用案例：服务一旦发生OMM告警，停止触发OMM的服务实例
告警策略配置如下图：
告警处理结果通知如下：
## 2.6 数据库SQL实时快照
- 特性价值：一键排查慢SQL，支持下载，提高定位业务中慢SQL的效率，支持MySQL、Postgresql、Oracle数据库
- 操作入口：【性能治理】->【SQL实时快照】
- 使用场景：系统卡顿，优先快速排查出数据库慢查询SQL，基于排查结果推动业务开发人员优化整改使系统尽快恢复正常
- 使用案例：查询集群中所有数据库运行时长大于等于10秒的Sql
如上图，可以同时查询多个数据库正在执行的SQL，相比分别去每个数据库主机排查效率提升明。
MySQL会显示status及对应的值，说明SQL当前的状态，比如sending data
Postgresql会显示wait_event及对应的值，如 wait_event:buffer_io
- 配置说明：系统会默认读取MC中配置的数据库信息去查询SQL，有可能MC配置的账号权限不足则需要重新在Monitor配置，配置入口【系统配置】->【监控库配置】
账号权限要求如下：
MySQL：有权限访问infomation_schame的用户
PostgreSQL：有权限访问系统库中pg_stat_activity视图的用户
Oracle:有权限访问系统库中v$session、v$sql、v$sqlstats视图的用户
## 2.7 数据库监控集成PMM
PMM([Percona Monitoring and Managemen](https://www.percona.com/software/database-tools/percona-monitoring-and-management))提供非常友好的监控分析页面帮助数据库管理员实时监控数据库性能、执行查询分析、诊断问题和优化性能。V6.0.1 Monitor集成了PMM监控功能页面，PMM服务端和Agent需要运维人员手动安装，[安装方法请参考官网说明](https://docs.percona.com/percona-monitoring-and-management/setting-up/index.html)
- 特性价值:支持可视化界面快速查看数据库CPU、IO、内存、网络等指标，支持查看SQL的负载、平均耗时、QPS等状态，支持查看SQL执行计划，定位慢SQL根因等，完善数控层定位问题能力，提高系统故障排除效率。
- 操作入口：第三方工具】->【PMM】
- 使用场景：系统卡顿，优先排查应用节点发现资源并不紧张，很可能卡在数据库通过PMM分析数据库资源和SQL执行情况
- 使用案例：查看并分析耗时久的SQL及其查询计划，通过【PMM】菜单打开PMM
查看SQL运行情况，如下图，直观显示查询时间范围内SQL负载高及执行时间
查看运行较慢的SQL，分析执行计划，如下图，可以查看执行计划
- 配置说明
1. Monitor是自动登录到PMM使用起来更方便，前提是需要配置好相关信息
配置信息入口【系统配置】->【参数配置】，配置正确的PMM Web页面URL和登录的账号、密码，如下图
2. 配置反向代理，由于PMM页面存在限制跨域的问题需要通过Nginx配置反向代理，统一Monitor和Pmm的域名，部署形态如下图
- Monitor没有使用Nginx做代理的场景，需要部署一个Nginx用来代理Monitor和PMM，nginx.conf配置如下
```
server {
listen 80;
server_name localhost;
#PMM反向代理配置
location /graph {
#PMM地址
proxy_pass https:/ip:port/graph/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
#Monitor反向代理配置
location /monitor/eye/ {
#Monitor地址
proxy_pass http://ip:port/ierp/monitor/eye/;
}
}
```
- Monitor使用Nginx做代理的场景，nginx,conf的配置文件增加PMM反向代理配置即可，如下
```
#PMM反向代理配置
location /graph {
#PMM地址
proxy_pass https://ip:port/graph/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
