你确定要删除吗？(不可恢复)
| [ All ] |
|---|
出问题CAT的服务端:[172.16.14.192, 10.1.6.128]
| 指标 | 值 | 备注 | |
|---|---|---|---|
| [:: show ::] | 处理消息总量 | 0 | 服务器接受到消息总量 |
| [:: show ::] | 丢失消息总量 | 0 | 服务器进行encode以及analyze处理来不及而丢失消息总量 |
| [:: show ::] | 每分钟平均处理数 | 0 | 平均每分钟处理消息量 |
| [:: show ::] | 单台机器每分钟最大处理数 | 0 | 单台机器平均每分钟最大处理消息数目 |
| [:: show ::] | gzip压缩成功消息数量 | 0 | 将消息进行gzip压缩消息数目 |
| [:: show ::] | gzip来不及压缩丢失消息数量 | 0 | 将消息进行gzip压缩，gzip线程太忙而丢失消息丢失数目 |
| [:: show ::] | 两台机器时钟不准导致消息存储丢失 | 0 | 这个场景用于Pigeon，服务端id是由客户端产生，客户端和服务端时钟差2小时，会导致存储丢失 |
| [:: show ::] | 网络传输或者客户端延迟发送导致消息丢失 | 0 | CAT分小时处理，当一个小时过去了，默认会延迟3分钟结束当前小时，在3分钟后还接受上个小时消息，直接丢弃 |
| [:: show ::] | 存储消息块数量 | 0 | CAT是分块存储，消息块成功放入存储队列 |
| [:: show ::] | 存储消息块丢失数量 | 0 | 将存储块写入磁盘的线程太忙，存储队列溢出的消息块数量 |
| [:: show ::] | 存储消息块花费时间(分钟) | 0 | 存储消息花费的CPU时间 |
| [:: show ::] | 压缩前消息大小(GB) | 0.00 | 压缩前所有存储消息的总大小 |
| [:: show ::] | 系统处理延迟(ms) | 0 | 客户端产生消息，到服务端存储之间的时钟误差。（在机器时钟完全准确的情况下） |
| 处理项目列表 | 处理消息总量 | 丢失消息总量 | 压缩前消息大小(GB) | 平均消息大小(KB) | 机器总数 | 项目对应机器列表 |
| 1 | 0 |