1. 概述
1.1 版本
| 运维平台版本 | 功能变更 |
|---|---|
| V1.0 | - |
| V1.2 | 仪表板显示内容优化，强化对各个数据的解释，方便用户理解 |
1.2 功能简介
运维平台提供「主仪表板、服务器监控、外接数据库监控、Redis监控、Nginx监控和应用监控」六个仪表板。
1.3 操作说明
仪表板中的操作按钮，目前仅支持查询，不会保存记忆上次的查询项。仅建议使用以下按钮，其他的操作按钮不建议使用。
| 按钮 | 说明 |
|---|---|
 | 左侧下拉框是用于选择监控仪表板的时间范围 右侧按钮用于快捷扩大查询时间范围 |
| 左侧按钮用于刷新数据 右侧下拉框用于配置自动刷新频率 |
| V2.0及之后版本支持在运维平台绑定多个应用 因此在仪表板左上方新增了相关按钮 可用于切换查看不同应用、集群节点、实例的仪表板情况 |
2. 主仪表板
主仪表板用于关注应用的全局状态情况概览，包括了各组件与应用的连通性，应用整体的运行状况，使用情况等。
同时也提供应用的历史运行信息，核心用于关注整个应用的可用状态，如果是应用集群，将汇总展示各个节点的状态。
管理员登录「运维平台」，点击「监控仪表板」，即可查看主仪表板。分为三个部分：应用状态总览、当前系统状态、历史运行状态。
2.1 应用状态总览
1）仪表板示例：
运维平台接入各个应用的状态情况，如果出现异常指标将标红/标黄显示，通过点击应用名称可以联动下方明细指标。
2）仪表板指标说明：
| 指标 | 具体说明 |
|---|---|
| 应用名称 | 当前查看的应用的名称 |
| 节点名称 | 当前查看的应用的节点名称 |
| 节点 | 当前查看的应用节点的IP和端口号 |
| 运行时长 | 当前查看的应用持续运行的时长。即距离上次启动的时间 |
| 实际物理内存占用 | 当前查看的应用，实际占用的物理内存大小 单位：GiB |
| 在线用户 | 当前查看的应用，目前在线用户数量 |
| 外接数据库 | 应用与外接数据库的连接状态，结果可能为：连通、断开、未设置（未使用外接）和部分节点异常（集群） |
| 文件服务器 | 应用与文件服务器的连接状态，结果可能为：连通、断开、未设置（未使用文件服务器）和部分节点异常（集群） |
| 状态服务器 | 应用与状态服务器的连接状态，结果可能为：连通、断开、未设置（未使用状态服务器）和部分节点异常（集群） |
| 负载分 | 由于 GC 机制的作用，通过内存使用率来表征 JVM 负载高低的方式并不能很好地反应 JVM 真实负载情况 因此帆软引入负载分来反应 JVM 真实负载情况，通过GC 回调来获取 GC 数据，并准确衡量 JVM 负载的各种状态 |
| 内存使用率 | 内存使用率 = 当前使用的内存 / 可以使用的最大内存 当前使用的内存：当前使用的内存大小（字节） 最大内存：可以使用的最大内存（字节），分配给 JVM 的最大内存 |
| CPU使用率 | CPU使用率 = 采集时刻 CPU 使用率 |
| 工程磁盘余量 | 显示检查的磁盘剩余可用的目录总量 单位：GiB |
2.2 当前系统状态
1）仪表板示例：
2）仪表板指标说明：
| 指标 | 具体说明 |
|---|---|
| 在线用户数 | 当前查看的应用，目前在线用户数量 |
| 文件打开数 | 启动应用的用户会有最大文件打开数的限制，当前应用文件打开数接近最大文件打开数时，可能会导致后续的访问出现报错，需要修改启动用户的最大文件打开数限制 |
| 各应用目录磁盘使用情况 | 展示应用相关的root目录、工程目录、备份目录、temp目录、schedule目录和logs目录所在的磁盘空间使用率情况，当使用率超过80%时会飙红显示，可用磁盘空间不足可能会影响应用的正常运行甚至宕机，需要尽快进行磁盘清理或扩容 |
| JVM负载 | JVM的负载变化情况，负载是帆软根据gc信息计算得出的应用压力量化方式，相比内存能够更真实的反映应用的压力情况，负载过高说明应用压力大 当负载超过80时需要关注是否存在异常 |
| JVM内存使用率 | JVM的内存使用率变化情况，反映应用的客观内存占用情况，可能包含可被gc回收的内存占用 |
| JVMCPU使用率 | JVM的CPU使用率变化情况，反映应用的CPU占用情况 |
| 应用进程实际占用物理内存 | 随时间变化，应用实际占用的物理内存大小 单位：GiB |
| GC次数 | 随时间的gc次数变化情况，gc次数越多通常gc负荷越大 |
| GC时间 | 应用每秒花在gc上的时间变化情况，反应gc的负荷和应用的吞吐量，gc时间越长，应用吞吐量越小 |
2.3 历史运行状态
1）仪表板示例：
2）仪表板指标说明：
| 指标 | 具体说明 |
|---|---|
| 系统运行时长 | 应用上次持续运行的时长 |
| 上次宕机信息 | 上次应用宕机的时间 |
| 近一个月节点总宕机记录 | 帆软系统进近一个月的宕机记录，用于回溯历史异常情况考虑 |
| 近一个月的高风险卡顿次数 | 近一个月帆软系统的高负载高风险（负载分大于100分/120）次数记录 |
3. 服务器监控
服务器监控仪表板主要用于监控帆软应用及相关组件运行的服务器的状态，方便及时关注服务器的各项指标情况，避免影响应用的正常运行。
管理员登录「运维平台」，点击「监控仪表板>服务器监控」，即可查看仪表板。分为两个部分：总览、服务器明细。
3.1 总览
1）仪表板示例：
如果有多个网卡或者多个分区，是采集的使用率最高的网卡或者分区的数值。
如果出现异常指标将标红/标黄显示，通过点击应用名称可以联动下方明细指标。
2）仪表板指标说明：
| 指标 | 具体说明 |
|---|---|
| IP | 应用所在服务器IP和端口号 |
| 内存 | 服务器物理内存 |
| CPU核 | 服务器CPU核 |
| 运行时间 | 服务器持续运行时长 |
| 5m负载 | - |
| CPU使用率 | 显示CPU性能情况和当前的CPU使用率，如CPU使用率过高说明计算压力较大，需要提升CPU性能或排查具体计算任务 |
| 内存使用率 | 显示服务器当前内存使用率，如内存过高可能会导致宕机，需要加大物理内存或中止部分占用内存较多的进程 |
| 磁盘可用空间 | 服务器磁盘剩余可用空间 |
| 磁盘读取 | 根目录磁盘的读取速率BPS，反映了磁盘读写性能消耗情况 |
| 磁盘写入 | 根目录磁盘的写入速率BPS，反映了磁盘读写性能消耗情况 |
| TCP连接数 | 当前状态为 ESTABLISHED 或 CLOSE-WAIT 的 TCP 连接数 |
| TCP_tw | - |
| 下载带宽 | 服务器网络上行速率，用于判断服务器网络的压力情况 |
| 上传带宽 | 服务器网络下行速率，用于判断服务器网络的压力情况 |
3.2 服务器明细
1）仪表板示例：
2）仪表板指标说明：
| 指标 | 具体说明 |
|---|---|
| 系统信息 | 展示系统的版本、以及各项环境信息，便于运维人员确定环境信息并排查问题 |
| 文件打开数 | 启动应用的用户会有最大文件打开数的限制，当前应用文件打开数接近最大文件打开数时，可能会导致后续的访问出现报错，需要修改启动用户的最大文件打开数限制 |
| CPU使用率 | 显示CPU性能情况和当前的CPU使用率，如CPU使用率过高说明计算压力较大，需要提升CPU性能或排查具体计算任务 |
| 内存使用 | 显示当前服务器内存使用率，如内存过高可能会导致宕机，需要加大物理内存或中止部分占用内存较多的进程 |
| 磁盘使用率曲线 | 显示当前服务器根目录的磁盘使用率，如磁盘使用率过高可能导致宕机或使用异常，需要加大磁盘空间或进行磁盘清理 |
| 磁盘读写速率曲线（BPS） | 根目录磁盘的每秒读取/写入速率BPS，反映了磁盘读写性能消耗情况 |
| 磁盘每秒读写请求数量（IOPS） | 根目录磁盘每秒读取/写入请求数量IOPS，反映了磁盘读写性能消耗情况 |
| CPU等待磁盘IO完成时间的百分比 | 展示一段时间内的CPU等待磁盘IO完成时间的百分比曲线，此项数值较高说明当前系统的磁盘使用率非常高，并且cpu的大部分时间处于等I/O的状态，这个时候，往往说明I/O遇到了瓶颈 |
| 磁盘IO的CPU使用率 | 展示一段时间内被磁盘IO消耗的CPU比率的曲线 |
| 网络带宽使用 | 展示服务器一段时间内的每秒网络上行/下行速率，用于判断服务器网络的压力情况 |
| TCP连接数 | 各种状态下的TCP连接数包括LISTEN、SYN_SENT、ESTABLISHED、SYN_RECV、FIN_WAIT1、CLOSE_WAIT、FIN_WAIT2、LAST_ACK、TIME_WAIT、CLOSING、CLOSED |
| inode使用率 | （仅linux）展示服务器一段时间的inode使用率 当磁盘还未存满，但inode已经分配完时会出现无法在磁盘新建文件的情况 |
4. 应用监控
应用监控仪表板用于监控帆软应用的运行情况，不同于主仪表板，应用监控仪表板可以针对单个节点的运行状态的详细数据进行查询。
4.1 节点状态总览
1）仪表板示例：
2）仪表板指标说明：
| 指标 | 具体说明 |
|---|---|
| 节点名称 | 当前查看的应用的节点名称 |
| 节点IP | 当前查看的应用节点的IP和端口号 |
| 运行时长 | 当前查看的应用持续运行的时长。即距离上次启动的时间 |
| 实际物理内存占用 | 当前查看的应用，实际占用的物理内存大小 单位：GiB |
| 存活会话数 | 当前存活会话数，可以用于了解应用的并发峰值情况 |
| 线程死锁数 | 如果出现线程死锁，可能会出现宕机等使用异常，需要关注并排查故障 |
| 负载分 | 由于 GC 机制的作用，通过内存使用率来表征 JVM 负载高低的方式并不能很好地反应 JVM 真实负载情况 因此帆软引入负载分来反应 JVM 真实负载情况，通过GC 回调来获取 GC 数据，并准确衡量 JVM 负载的各种状态 |
| 内存使用率 | 内存使用率 = 当前使用的内存 / 可以使用的最大内存 当前使用的内存：当前使用的内存大小（字节） 最大内存：可以使用的最大内存（字节），分配给 JVM 的最大内存 |
| CPU使用率 | CPU使用率 = 采集时刻 CPU 使用率 |
| root目录磁盘余量 | 显示检查的磁盘剩余可用的目录总量 单位：GiB |
| 工程磁盘余量 | 显示检查的磁盘剩余可用的目录总量 单位：GiB |
| logs目录磁盘余量 | 显示检查的磁盘剩余可用的目录总量 单位：GiB |
| temp目录磁盘余量 | 显示检查的磁盘剩余可用的目录总量 单位：GiB |
4.2 节点明细
1）仪表板示例：
2）仪表板指标说明：
| 指标 | 具体说明 |
|---|---|
| JVM负载 | JVM的负载变化情况，负载是帆软根据gc信息计算得出的应用压力量化方式，相比内存能够更真实的反映应用的压力情况，负载过高说明应用压力大 当负载超过80时需要关注是否存在异常 |
| JVM内存使用率 | JVM的内存使用率变化情况，反映应用的客观内存占用情况，可能包含可被gc回收的内存占用 |
| JVMCPU使用率 | JVM的CPU使用率变化情况，反映应用的CPU占用情况 |
| 应用进程实际占用物理内存 | 随时间变化，应用实际占用的物理内存大小 单位：GiB |
| GC次数 | 随时间的gc次数变化情况，gc次数越多通常gc负荷越大 |
| GC时间 | 应用每秒花在gc上的时间变化情况，反应gc的负荷和应用的吞吐量，gc时间越长，应用吞吐量越小 |
| 文件打开数 | 启动应用的用户会有最大文件打开数的限制，当前应用文件打开数接近最大文件打开数时，可能会导致后续的访问出现报错，需要修改启动用户的最大文件打开数限制 |
| 各应用目录磁盘使用情况 | 展示应用相关的root目录、工程目录、备份目录、temp目录、schedule目录和logs目录所在的磁盘空间使用率情况，当使用率超过80%时会飙红显示，可用磁盘空间不足可能会影响应用的正常运行甚至宕机，需要尽快进行磁盘清理或扩容 |
| 各目录磁盘增长情况 | 各个目录所在磁盘大小的增长情况，如果剩余空间不足10GB可能会影响应用的正常运行甚至宕机，需要尽快进行磁盘清理或扩容 |
| 会话数曲线 | 当前存活会话数，以及存活会话、新增会话和关闭会话数的变化曲线，可以用于了解应用的并发峰值情况 |
| 线程死锁数量 | 如果出现线程死锁，可能会出现宕机等使用异常，需要关注并排查故障 |
4.3 应用信息
1）仪表板示例：
2）仪表板指标说明：
| 指标 | 具体说明 |
|---|---|
| 系统在线用户数 | 当前在线用户数和在线用户曲线，可以用于判断系统最大在线用户数 |
| 应用版本信息 | 应用版本信息，便于进行问题的排查定位 |
| JVM参数 | JVM的参数信息，便于进行问题的排查定位 |
| 应用插件列表 | 应用的插件列表，便于进行问题的排查定位 |
5. 外接数据库监控
外接数据库监控主要用来监控外接数据库的压力情况，避免因为外接数据库的不稳定而影响帆软系统的正常使用。
1）仪表板示例：
2）仪表板指标说明：
| 指标 | 具体说明 |
|---|---|
| 是否存活 | 外接数据库是否存活 |
| 运行时长 | 外接数据库举例上次启动的时长 |
| 缓冲池大小 | 缓冲池大小，内存允许的情况下缓冲池越大性能越好 |
| 缓冲池利用率 | 展示一段时间内缓冲池利用率的变化趋势 |
| 磁盘读取请求次数 | 磁盘读取请求次数，磁盘读取请求次数持续增长可能出现外接数据库性能差，磁盘io压力大等问题 |
| 连接数 | 展示外接数据库的剩余连接数和实例拒绝连接数，如果剩余连接数不足可能会出现应用访问异常 |
| QPS | 展示外接数据库每秒处理的请求数量，用来判断外接数据库的压力情况 |
| 正在查询的数量 | 展示外接数据库正在查询的语句数量，持续增长可能说明外接数据库超负荷 |
| 慢查询数量 | 展示外接数据库的慢查询数量，如果慢查询数量持续增长可能影响外接数据库的性能及可用性，需要关注具体慢查询的情况 |
| 死锁信息 | 展示数据库的死锁信息： ts:检测到死锁的时间戳 thread:产生死锁的线程id，这个id和show processlist里面的线程id是一致的 txn_id:innodb的事务ID txd_time:死锁检查到前，事务执行时间 user:执行transcation的用户名 db:发生死锁的DB名 tbl:死锁发生的表名 idx:产生死锁的索引名(在上面这个demo里面， 我们直接走的主键，加的记录锁) lock_type:锁的类型(记录锁，gap锁，next-key锁) lock_mode:锁模式(S,X) wait_hold:是否等着锁释放，一般死锁都是两个wait victim:该会话是否做了牺牲，终止了执行 query:造成死锁的SQL语句 |
6. Redis监控
Redis监控仪表板用于监控帆软系统使用的Redis状态服务器的运行情况。
6.1 基本信息
1）仪表板示例：
2）仪表板指标说明：
| 指标 | 具体说明 |
|---|---|
| 是否存活 | redis的存活状态 |
| redis版本 | redis的版本 |
| 模式 | 单机还是集群 |
| 运行时长 | redis本次启动的运行时长 |
| 集群活跃节点数 | 集群活跃的节点数 |
| 主节点数 | 集群主节点数量 |
| 从节点数 | 集群从节点数量 |
| redis内存信息 | redis分配的内存和使用情况，通常来说redis内存占用比较小，如果出现内存使用率很高，那么可能存在异常 |
| 内存使用率曲线 | 一段时间内已用内存在分配内存中的占比 |
| 内存碎片率 | 内存碎片率表示「Redis向操作系统中申请的内存」 与「分配器分配的内存总量」的比值 指数>1表明有内存碎片，越大表明越多，<1表明正在使用虚拟内存，虚拟内存其实就是硬盘，性能比内存低得多，这是应该增强机器的内存以提高性能。 大于1.5表示，系统分配的内存大于Redis实际使用的内存，Redis没有把这部分内存返还给系统，产生了很多内存碎片。在Redis 4.0版以前，只能通过安全重启解决这个问题。Redis 4.0及以上版本可以支持内存自动清理。 小于1表示，系统分配的内存小于Redis实际使用的内存，而Redis很有可能在使用Swap了！使用swap是相当影响性能的。 |
6.2 使用情况
1）仪表板示例：
2）仪表板指标说明：
| 指标 | 具体说明 |
|---|---|
| 客户端连接个数 | 用于查看当前redis的客户端连接个数，默认的客户端连接数最大限制为10000，如果连接数过高，会影响redis吞吐量。>5000 时通常就需要进行告警 |
| redis每秒执行的命令数 | 展示一段时间内redis每秒执行命令数的曲线 |
| 每秒查找数据库键成功/失败的次数 | 展示每秒查找数据库的hit/miss的次数，用于参考根据业务需求调优Redis配置 |
| 过期/未过期数据库键数 | 展示redis中过期/未过期数据库键数，用于参考根据业务需求调优Redis配置 |
