【CDP】Cloudera Manager 记录一次 Service Monitor 内存溢出/使用率高的问题及通用排查方案

一、问题描述

最近发现我们的生产环境 Service Monitor 的监控报表数据无法正常显示，有很多的断点，有很多数据没有被正常采集到，最后定位到是 service monitor 的JVM 内存使用率过高，导致频繁GC，使得 Service Monitor 极不稳定。

开始的时候，没有过多考虑，只是增加了 JVM 的堆内存大小，但是过段时间有出现，从 16G -> 32G -> 64G，问题还是没有解决，看来必须更深的追一下了。

二、环境信息

1. cloudera manager 7.4.4
2. cdp 7.1.7

三、解决思路

首先明确 Servcie Monitor 具体的监控指标项，以及每个监控指标项对应的监控 Entity 的数量。

通常来说，监控指标项中监控实体数量越多，越容易引起引起的Service monitor 内存使用率过高。

所以我们需要定位是那个监控项拥有过多的监控实体导致的服务异常。

四、具体实践

1. 修改配置

这一步是要能够通过 rest 请求来查看 监控 Entity 的详情。

CM -> Cloudera Management Service -> 配置 -> Service Monitor 的 java 配置选项

新增如下内容：

-Dcom.cloudera.cmon.firehose.FirehoseDebugServer.enable_timeSeriesEntitySummary_servlet=true

2. 重启service Monitor 服务

CM -> Cloudera Management Service -> 实例 -> Service Monitor 重启。

3. 查看 entity 数量

http://service monitor ip:8086/timeSeriesEntitySummary

内容大致如下：

五、问题原因

我这里遇到的问题原因是 Kakfa Producer 的监控指标项过多导致的。SMM有一个已知问题，当匿名producer的metric被SMON收集的时候，很容易对SMON造成过压，导致SMON服务不正常。这会导致SMON 空间填满，从而导致内存消耗问题。为了解决这个问题，在CDP 7.1.7的新功能中引入了producer metric whitelisting，将您所关心的producer加入到白名单，过滤掉不需要的匿名producer。

找到监控实体数量最多的一项，问题大概就是由他引起的，可能每个人的情况不一样，这里只给一个通用的排查方向，具体的情况具体解决。

最终的解决方法

CM -> kafka -> 配置 -> producer.metrics.enable 设置为 false。

滚动重启 Kafka 集群。

六、补充

对于有些目前找不到问题原因，但又想尽快降低 Service Monitor 服务内存小伙伴，可以尝试重置Firehose LevelDB存储。具体步骤如下：

1. 停止 Service Monitor 服务。
2. 重命名 Service Monoitor 配置中的目录，或者直接将 /var/lib/cloudera-service-monitor 目录下的文件夹清空。
3. 启动 Service Monitor 服务。

参考：

1. https://my.cloudera.com/knowledge/ERROR-quotOutOfMemoryquot-in-Service-Monitor?id=338841