你确定要删除吗?(不可恢复)
[ 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 |