关于otter监控告警使用

原创

已于 2025-03-02 15:02:29 修改 · 1.2k 阅读

7 ·

CC 4.0 BY-SA版权

文章标签：

#分布式 #中间件 #otter

于 2024-11-30 17:08:19 首次发布

一、背景

近期在使用otter完成单机房单向同步时，常常遇到channel假死的情况，导致Pipeline同步停止，系统表数据同步停止，影响生产环境用户数据查询相关的功能，虽然事后能够通过停channel后再启用channel重新启用同步任务，恢复需要同步的数据，但时常出现该问题而不能及时发现让人头疼不已。通过查询相关的资料有发现早有同学遇到过类似的问题，初步认为是otter的调度算法导致死锁导致任务停止，但目前仍然没有石锤，且otter开源团队目前未对该问题进行官方解答。具体问题描述可参考：https://github.com/alibaba/otter/issues/911

为了解决该问题，曾尝试在线下复现该问题，但是以失败告终，然后就换了一个思路：是否能及时发现同步停止的问题呢？按照这个思路我看到了官方其实目前支持五种同步的告警：延迟、Pipeline延迟、Process延迟、Position延迟、异常监控告警，同时还提供了告警自我恢复机制；通过使用测试其中的Pipeline延迟机制并开启自我恢复机制，发现确实能够及时的完成告警，而且在触发自我恢复阀的情况，系统能够自动完成channel的stop，然后自动再start，channel的同步任务恢复正常，现就针对otter监控告警机制进行说明。

二、otter监控机制解析：

首先得看一下otter监控机制的流程：1.首先我们通过otter的控制台为channel下的Pipeline配置监控。2.otter-manager在启动时会启用一个单线程的定时任务线程池，定时任务每120秒执行一次。2.1 该线程池任务在执行时会查询当前所有启用的监控记录；2.2 然后对监控规则按照Pipeline进行分组；2.3 遍历分组的后的具体规则。2.4 查询Pipeline信息，然后根据Pipeline中的channelId查询zookeeper上对应channel的状态，若channel的状态节点为null或者未停止状态则不执行后监控逻辑。2.5 根据不同的监控类型执行具体的判断逻辑；若当前的统计的数据满足监控告警的条件则执行告警逻辑，若开启了自我恢复机制则尝试恢复channel任务同步。源码分析如下：

#一、SelfMonitor中的start()开启监控
private synchronized void start() {
        if (executor == null) {
            // 创建定时任务线程池，单线程
            executor = new ScheduledThreadPoolExecutor(DEFAULT_POOL, new NamedThreadFactory("Self-Monitor"),
                                                       new ThreadPoolExecutor.CallerRunsPolicy());
        }
        if (future == null) {
            // 每120秒执行一次
            future = executor.scheduleWithFixedDelay(new Runnable() {
                public void run() {
                    try {