BE频繁DEAD

【详述】问题详细描述
6~7 点BE频繁DEAD,
【背景】做过哪些操作?
6~7点 是导数高峰期,导数方式broker、flink、datax等。
【业务影响】
【StarRocks版本】例如:2.3.7
【集群规模】例如:3fe(1 follower+2observer)+5be(fe与be混部)
【机器信息】CPU虚拟核/内存/网卡,例如:16C/128G/万兆
【联系方式】
【附件】

问题描述
2023-06-05T07:30:05 报警出现BE DWON,但是BE并没有DOWN,并且集群出现副本不健康,但是在自动修复。


日志如下
be.info:
I0605-be.info (23.4 MB)
be.warn:
I0605-be.warning (95.5 KB)

fe.log:
I0605-fe.log (14.6 MB)
fe.warn.log:
I0605-fe.warn.log.0 (215.9 KB)
其他监控信息:

同时间段的FE leader日志也麻烦提供一下.

FE 7:30分 左右日志补充了

报警阶段有没有查看一下show backends; FE侧认为的BE状态?

另外在grafana上有BE DEAD时, DEAD大约持续多长时间? prometheus采集的指标有没有断图丢失采集点现象?

第一点:这个没有来得及看,BE DEAD 时间一般小于1~2分钟。
第二点: prometheus采集的指标有没有断图丢失现象 ,这边排查一下,这边有3套集群,其中一套6~7经常出现BE DEAD

从目前的信息来看: FE/BE日志里都没有BE dead相关的信息, grafana上的DEAD/ALIVE是通过prometheus提供的up指标, 目前怀疑DEAD是误报, 可能原因跟https://forum.mirrorship.cn/t/topic/6934 这个有关, 在load压力大的场景下, prometheus采集BE的/metrics可能会超时没有响应. 问题具体根源还没有定位.

好的 如果有定位到问题,同步一下吧,使用StarRocks 已经担惊受怕了

下次遇到报警BE dead时, 也麻烦查看一下show frontends; show backends记录一下FE侧认为的BE状态, 侧面验证一下我们的猜测是否合理.

好的 啥猜测呀?,明天7点我观察一下

猜测为误报警, 是因为prometheus的采集超时导致

  • IO 阻塞
  • 网络阻塞
  • CPU 阻塞

都会导致 prometheus 采集后无法同步…
最好按照自己的场景排查下
image

出现类似这种,就是被积压了…

这图 是机器的进程监控 还是SR 集群的进程监控呀

主机节点的监控啊,SR 集群也受主机资源的影响啊…

SR 指标排查不出来的时候,就需要其他的指标做参考了

主键模型表多吗?

挺多的,明细和主键模型都在使用

23-06-06 06:58:15, 2023-06-06 07:03:30出现Be dead

对应时间Show backends; 状态显示活跃
23-06-06 06:58:15 show backends;


2023-06-06 07:03:30 show backends;

非常感谢,所以这确实是误报!我们尽快调查/metrics接口超时的问题。

brpc_num_threads=48 number_tablet_writer_threads=64 transaction_publish_version_worker_count=32 be_http_num_workers=96 调参后,还是有这个现像