alibaba / alibaba/otter

监控报canal elapsed XXX seconds no data

Open
#623 6 comments 0 reactions 0 assignees View on GitHub
Dominant language
Java
Stars
8.1k
Forks
2.5k
PR merge metrics
No merged PRs in 30d

Description

我配置了两个node节点的高可用,看了下现在pipe跑在nod[2]上面,而node[1]一直在报未接收到数据,同步也都是正常的。
请教下,是不是哪里有问题,
这给我的监控带来了一些困扰。

对应node节点日志如下,
2018-10-16 16:20:33.192 [pipelineId = 3 , CanalDetecting-0] WARN c.a.o.shared.arbitrate.impl.setl.monitor.MainstemMonitor - mainstem is running in node[2] , but not in node[1]
2018-10-16 16:20:33.192 [pipelineId = 3 , CanalDetecting-0] WARN c.a.o.s.a.i.setl.zookeeper.termin.WarningTerminProcess - nid:1[3:mainstem:pid:3 canal elapsed 105800 seconds no data]
2018-10-16 16:41:27.515 [pipelineId = 3 , CanalDetecting-0] WARN c.a.o.shared.arbitrate.impl.setl.monitor.MainstemMonitor - mainstem is running in node[2] , but not in node[1]
2018-10-16 16:41:27.516 [pipelineId = 3 , CanalDetecting-0] WARN c.a.o.s.a.i.setl.zookeeper.termin.WarningTerminProcess - nid:1[3:mainstem:pid:3 canal elapsed 110450 seconds no data]

谢谢。

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reading the MainstemMonitor and WarningTerminProcess entry points named in the logs, then trace how the two-node high-availability state produces the elapsed-no-data warning. Reproduce or inspect the node[1]/node[2] behavior and determine whether the warning is expected for the standby node; done means the monitoring output accurately reflects the synchronization state.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
distributed-systems, observability
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.