登录
/
注册
首页
论坛
其它
首页
科技
业界
安全
程序
广播
Follow
关于
签到
每天签到奖励2-10圆
导读
排行榜
TG频道
发帖说明
登录
/
注册
账号
自动登录
找回密码
密码
登录
立即注册
搜索
搜索
关闭
CSDN热搜
程序园
精品问答
技术交流
资源下载
本版
帖子
用户
软件
问答
教程
代码
写记录
VIP申请
VIP网盘
网盘
联系我们
发帖说明
每日签到
道具
勋章
任务
淘帖
动态
分享
留言板
导读
设置
我的收藏
退出
腾讯QQ
微信登录
返回列表
首页
›
业界区
›
业界
›
夜莺监控设计思考(一)整体定位、架构设计、单进程多进 ...
夜莺监控设计思考(一)整体定位、架构设计、单进程多进程选择、高可用设计
[ 复制链接 ]
魁睥
3 小时前
这将是一个系列,讲解 夜莺监控 的设计思考,可以理解为原理+最佳实践+产品设计时的折中取舍。
整体定位
了解一个开源项目,最应该了解的就是其定位,或者说它要解决的问题域。
夜莺的定位就是四个字:
告警引擎
。夜莺对接多种数据源(比如 Prometheus、VictoriaMetrics、MySQL、ClickHouse、Postgres、ElasticSearch),根据用户配置的告警规则,判定并产生告警事件,然后对事件做 Pipeline 处理,最终通过各类通知媒介发出告警。
可以对比 Grafana 来理解,Grafana 也是对接多种数据源,不过 Grafana 侧重在数据可视化,夜莺侧重在告警。
没有夜莺之前,各个数据源的告警是怎么处理的?
Prometheus 是直接配置在 prometheus.yml 里,管理起来稍有不便
VictoriaMetrics 是使用 vmalert,和 Prometheus 是类似的逻辑
ElasticSearch 社区里用的比较多的是 elastalert 开源项目做告警判定
ClickHouse、MySQL、Postgres 等貌似没有专门的告警引擎
有了夜莺之后,就可以在夜莺里统一管理告警规则、通知媒介、消息模板、用户联系方式等。而且,夜莺可以对告警事件做 Pipeline 处理,比如:
Relabel:类似指标的 Relabel,夜莺可以对告警事件做 Relabel
Enrichment:事件丰富,比如调用 CMDB 的接口为事件附加更多丰富的上下文信息
Drop:一些特定的告警事件要丢弃掉
等等
夜莺的核心功能部件
确定了定位之后,如果你是夜莺的设计者,要如何设计其功能部件呢?
首先,需要一个 webapi。用于和用户、第三方交互,用户需要做一些配置,比如:
数据源的配置
用户、角色的管理
用户联系方式管理(比如电话、手机号等,未来在告警触发时,要打电话发告警短信等)
各类规则配置,比如告警规则、屏蔽规则、订阅规则
通知媒介、消息模板的管理
Pipeline 的管理
查看历史告警事件,做一些统计分析等
其次,需要有一个后台任务执行的逻辑,根据用户配置的告警规则,周期性执行,去查询数据源,判定数据异常并生成告警事件,最终发送。
最简单的就是一个告警规则一个 goroutine(轻量级线程)后台执行
如果执行失败,通过某些监控指标反应异常,同时打印执行失败的日志
需要考虑高可用,如果某个实例挂了,其他实例要顶上来
需要考虑 sharding,比如有两个实例,有 1000 条规则,那每个实例要处理 500 条规则,不能重复执行,而且要均匀分配,如果某个实例挂了,剩下的实例要能承接原本宕机的实例负责的那些规则
对于某个实例而言,就要知道当前总共有多少实例,哪些实例存活,哪些实例挂了,否则,我不知道谁挂了我就没法接管。这需要一个中心状态存储,或者引入 Raft 等协议
这个功能部件主要是负责告警,姑且称之为 alert。所以,夜莺至少有两个功能部件:webapi + alert。实际上,夜莺还有其他功能部件,后文再说。
单进程还是多进程
刚才讲,夜莺至少包含两个功能部件:webapi + alert。那是做成一个进程?还是做成两个进程?
如果是公司内部的系统,我更倾向于做成两个进程,方便维护。但作为一个开源项目,还要考虑普通用户的部署复杂度,则更倾向于做成一个进程。
高可用设计
对于 webapi 功能部件而言,是一个无状态的组件,接收 api 请求然后对数据库做 CRUD,所以 webapi 可以水平扩展,部署多个,前面架设负载均衡,就是高可用了。
alert 模块需要协调分配告警规则,是有状态的,既然我们不可避免要使用数据库存储各类配置信息,那就顺便用数据库存储 alert 的心跳信息得了,比较简单。
所以,所有 alert 复用一个 MySQL,周期性心跳,这样 DB 的心跳表里就可以查到所有实例列表,以及最近一次心跳时间,从而得知哪些实例活着哪些已经挂了(长时间没有心跳就认为挂了)。
这样的架构极为简单,每个实例的配置都是相同的,要做高可用就搞多个机器部署多个实例即可。社区用户用起来也简单。
后记
本文介绍了夜莺的定位、架构、单进程还是多进程的抉择、高可用设计,如果你们公司只有一个机房或者有多个机房但是机房之间有很好的网络专线,那就部署一套夜莺就可以了,如果有多个机房,但是机房之间的网络链路很差,就需要考虑夜莺的边缘机房架构模式,咱们下一节详细介绍。
来源:程序园用户自行投稿发布,如果侵权,请联系站长删除
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!
设计
进程
高可用
选择
夜莺
相关帖子
读发布!设计与部署稳定的分布式系统(第2版)
可观测性平台夜莺开源项目发布V6正式版!
如何把一个接口设计好?
夜莺中心端管理categraf采集规则并下发
解析设计模式与设计原则:构建可维护性和可扩展性代码的重要性
推荐一款基于.NET的进程间数据交互经典解决方案
PostgreSQL pg_auto_failover 高可用 2:pg_auto_failover集群运维
记录一下 WPF进程 SendMessage 发送窗口消息进行进程间通信
多进程环境中解决 PHP 文件系统锁定问题指南
三款主流原型设计工具深度测评:墨刀、Pixso与Axure真实使用体验
vip免费申请,1年只需15美金$
回复
使用道具
举报
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
照妖镜
相关推荐
安全
读发布!设计与部署稳定的分布式系统(第2版)
0
659
许娴广
2025-10-10
安全
可观测性平台夜莺开源项目发布V6正式版!
0
915
廖雯华
2025-10-10
安全
如何把一个接口设计好?
0
380
戎玉珂
2025-10-10
安全
夜莺中心端管理categraf采集规则并下发
0
705
城徉汗
2025-10-10
安全
解析设计模式与设计原则:构建可维护性和可扩展性代码的重要性
0
461
涂流如
2025-10-11
安全
推荐一款基于.NET的进程间数据交互经典解决方案
0
749
姥恫
2025-10-12
安全
PostgreSQL pg_auto_failover 高可用 2:pg_auto_failover集群运维
0
128
师佳思
2025-10-12
业界
记录一下 WPF进程 SendMessage 发送窗口消息进行进程间通信
0
837
桂册
2025-10-13
业界
多进程环境中解决 PHP 文件系统锁定问题指南
0
789
坟菊
2025-10-13
安全
三款主流原型设计工具深度测评:墨刀、Pixso与Axure真实使用体验
0
897
山芷兰
2025-10-13
高级模式
B
Color
Image
Link
Quote
Code
Smilies
您需要登录后才可以回帖
登录
|
立即注册
回复
本版积分规则
回帖并转播
回帖后跳转到最后一页
签约作者
程序园优秀签约作者
发帖
魁睥
3 小时前
关注
0
粉丝关注
13
主题发布
板块介绍填写区域,请于后台编辑
财富榜{圆}
anyue1937
9994888
dage888
999994
3934307807
993678
4
富账慕
10004
5
刎唇
9993
6
烯八
9972
7
匝抽
9986
8
柴古香
9986
9
筒濂
9974
10
孙淼淼
9983
查看更多