followup监控需求

背景

当前followup监控不完善，查询服务与数据同步服务分离为独立项目，当前监控信息如下：

数据同步服务

• 监控数据实时性，数据延时计算公式为当前系统时间戳减去订阅Canal的binlog数据时间戳的差值大于1分钟为判定为延时，然后发送报警给相关人。此监控存在问题是假设MySQL主从和Canal通路无问题，只是某个环节阻塞处理吞吐能力变差情况下可行，如果MySQL或Canal本身出现问题，是无法获知，更无法产生报警。

查询服务

• 只有接口监控，探活可用

问题如下

• es集群基础架构组不维护，维持现状不继续迭代，es集群处于无人管状态。例如mes集群
• 业务只关注自身监控业务报警，es集群无关注，存在风险，es遇到性能或挂了却不知情

目标

• 运维负责主机监控
• 提供es系统监控，复用基础架构组的组件
• 提供followup-es业务监控

收益

• 能快速找到业务出现问题具体环节
• 能获知数据同步是否存在延时发生

监控metrics

followup-es write QPS   每秒采集一次  由mon系统展示

报警metrics

根据业务规律设置 write QPS连续时间段内无数据，发送报警信息