监控报警最佳实践

CPU与负载

该模块用于监控系统的CPU使用率与负载，包含指标：CPU利用率、CPU WIO使用率、CPU空闲率、平均负载。其中CPU使用率包括用户使用率（User）和系统使用率（System）。

在设置报警规则时，建议您根据业务特性和对延迟的敏感程度来设置CPU空闲率（%）的报警值。通常情况下，CPU利用率的升高会导致响应时间的增加，但不同性质的业务受影响的程度不同。例如，当CPU利用率超过40%时在线型业务的响应可能会受到影响，而对于部分离线型业务，即使CPU利用率达到100%其业务运行也不会受到影响。因此，建议您根据业务自身情况来合理设置报警值。当CPU使用率过高时，可以通过扩容或升配来满足业务需求。如何扩容或升配，请参见管理存储空间和变更实例配置。

CPU WIO使用率(%)表示CPU在等待IO操作时所占用的时间比例，该指标过高表示读写磁盘遇到瓶颈。在判断机器的健康状态时，可以将CPU WIO使用率(%)和每分钟平均负载(load1)（下文简称Load指标）一起分析。Load指标综合了CPU利用率和磁盘使用率。

机器可以承受的负载通常与其CPU配置相关。例如购买的机器CPU为8核，当Load指标的值大于8即意味着CPU的处理开始排队，机器处于亚健康状态。如果CPU利用率不高，但Load指标偏高，则代表磁盘的使用率过高。当CPU负载过高或WIO使用率过高时，建议您扩容或者升配，以免影响业务。

网络和磁盘

该模块用于监控机器的网络和磁盘情况。您需要关注机器的网络流量、磁盘读写情况和IOPS指标，避免其超过ECS实例和云盘的限流阈值。

不同规格的ECS实例具备不同的网络带宽，网络的限流阈值请参见实例规格族。磁盘的限流阈值请参见块存储性能。如果对网络和磁盘限制有疑问，请联系Lindorm技术支持（钉钉号：s0s3eg3）为您解答。

非本地盘机型的ECS云盘存在总带宽上限，如果读加写的流量超过ECS云盘带宽，也会出现限流导致业务受损。在使用过程中，您需要密切关注磁盘和网络使用情况，防止超出底层机器的网络或磁盘限制。

集群负载

集群负载指标主要监控以下几项：

• 宽表计算节点内存使用比率(%)：表示宽表引擎当前堆内存已使用的比率。如果堆的使用比率长期过高，可能会导致宽表引擎OOM或Full GC，进而影响业务。堆内存大小是会波动的，如果您临时过度使用了堆内存，系统将通过垃圾回收（GC）等方式使堆的大小自然下降。当堆内存大小持续超过某个阈值时，需要进行关注。因此，当该数值过高时，建议升级宽表节点的规格，以增大内存。在配置报警规则时，建议将规则配置为：该比率大于85%~90%且持续30~60分钟后报警。如何升级规格，请参见变更实例规格。

• RS的region数(个)：每个宽表节点上的数据分片个数。宽表引擎会把表按范围切片并分布到各个机器上，由master统一管理分配。每个分片（Region）都会占用元数据内存空间，因此Region数量过多会导致机器内存不足。您需要控制Region的数量，例如减少表的数量、减少建表时预分区的个数。

  以下是不同配置下，单个机器的Region个数建议：

  机器配置（内存大小）	单机建议的分片个数
  8 GB	< 500
  16 GB	< 1000
  32 GB	< 2000
  64 GB	< 3000
  128 GB	< 5000

  以上数值仅供参考，实际使用时您可以通过宽表计算节点内存使用量 / 宽表计算节点内存总量来判断实例是否存在内存不足的问题。

• HandlerQueue长度(个)：表示服务器上请求排队的情况。如果HandlerQueue长度大于0，则表示请求在服务器上需排队处理，预示着服务器资源无法承载当前请求量，因此无法及时处理请求，建议您升级实例配置来增加CPU资源。

• Compaction队列长度(个)：表示服务器上Compaction任务的排队情况。当写入量增多时，需要执行的Compaction操作会随之增多，可能会出现需要排队执行的现象。

  说明

  • Compaction队列长度大于0不代表实例一定处于不健康状态。假设业务的写入高峰和写入低谷有比较明显的周期，白天写入高峰，晚上写入低谷，那么白天Compaction任务可能存在积压（即Compaction队列长度大于0），但在晚上的业务低谷期，系统将自动处理这些积压的任务，此时Compaction队列长度会减少到0，这说明实例是健康的。此外，如果Compaction队列长度长期稳定在某一个值，表示实例处于稳定状态，无需关注。

  • 如果Compaction队列长度持续上涨且没有下降趋势，说明实例资源不足，需要增加节点或升级配置来增加CPU资源，以便及时处理Compaction任务。Compaction任务的积压在短时间内不会影响业务，但长期积压会导致分片内文件过多，可能会影响读RT。如果文件数量持续增长可能会出现反压写现象，导致写入RT增加甚至超时。

• Region的平均文件数：表示分片内平均文件的个数，数量越多，读RT越大。每个文件元数据都会占用内存，如果文件总数过多可能导致Full GC或OOM。

• Region的最大文件数：Lindorm对单个Region内的文件数量存在限制，如果超过该限制会出现反压写现象导致写超时。具体限制说明，请参见数据请求的限制。

读请求

主要包含以下几类监控项：

• Get监控项：包括Get请求量(个/秒)、Get平均RT(毫秒)、Get P99 RT(毫秒)三项。该监控项是指根据完整的主键信息，在Lindorm服务器执行一次点查调用，获取相关的监控指标，包括QPS，平均RT和P99 RT。如果您使用了BatchGet操作，无论BatchGet操作中包含多少行，都只会被视为一次点查调用。由于BatchGet操作是在单个服务器上以串行方式执行，因此如果仅使用了BatchGet操作，或同时使用了BatchGet操作和单行Get操作，平均RT的值会高于单行Get操作的RT。

• Scan监控项：包括Scan请求量(个/秒)、Scan平均RT(毫秒)、Scan P99 RT(毫秒)三项。该监控项用于监控范围扫描操作（Scan请求）的相关指标。Lindorm服务器会将大范围的Scan请求拆分并以流式的方式返回，Scan请求量(个/秒)和Scan平均RT(毫秒)分别指将Scan请求拆分后，每秒发送到服务器的扫描子调用数量和每个扫描操作的平均耗时，因此Scan请求量(个/秒)显示的Scan请求的数量可能会比实际使用时发起的Scan请求数量多。同时，完整Scan请求的耗时也由多个子扫描请求的耗时组成。

• 读监控项：包括读请求量(个/秒)、读平均RT(毫秒)、读流量三项。该监控项同时包含了Get和Scan请求的监控项，用于统计实例每秒返回多少行数据、返回每行数据的平均耗时。Get请求和Scan请求可能一次请求返回多行，因此该监控项能够更真实地反映实例的读吞吐。

写请求

• 写流量：该监控项用于监控写入宽表引擎的流量吞吐，单位为KB/s。宽表写入底层存储时，宽表的列会被转化为键值对（KeyValue）形式，因此写入的列相比于业务实际写入的列更多，数据量更大。建议您通过该指标来判断Lindorm宽表引擎的写入吞吐。

  写入吞吐过大，可能会导致Compaction任务积压，进而影响实例的稳定性，请您根据业务需求综合考虑并选择合适的CPU配置。

  以下是不同配置下的写入吞吐参考：

  CPU配置	建议的写入吞吐
  4核	< 5 MB/s
  8核	< 10 MB/s
  16核	< 30 MB/s
  32核	< 60 MB/s

  以上值仅供参考，实际使用时您可以进一步结合Compaction队列长度、Region的平均文件数以及Region的最大文件数来综合考虑。

• 超过Memstore上限次数(次)：Lindorm宽表在写入时会先将数据写入对应Region的内存缓存（Memstore）中，当Memstore过大时，系统将触发一次Flush操作将数据刷写到磁盘上。如果业务的写入热点过于集中，写入请求集中在某几个Region上，就会造成这些Region的Memstore过大，会导致出现反压写现象，从而影响写吞吐。因此当该指标大于0时，您需要考虑写入是否存在热点现象，或写入TPS已经超过实例能够承受的最大值导致来不及将数据刷写至磁盘上。您可以通过Hash算法将主键打散，避免热点的产生。更多介绍，请参见如何设计宽表主键。