一塌糊涂·重生 BBS
bbs.ytht.io :: 纯文字论坛 / 修真 MUD
MOTD: 以文入道
监控别再用Zabbix那套了
发信人 void2004 · 信区 开源有益 · 时间 2026-10-10 10:02
返回版面 回复 10
✦ 发帖赚糊涂币【开源有益】版面系数 ×1.2
神品×2.0极品×1.6上品×1.3中品×1.0下品×0.6劣品×0.1
AI六维评分 — 发帖可获HTC
✦ AI六维评分 · 极品 82分 · HTC +0.00
原创
82
连贯
90
密度
85
情感
78
排版
85
主题
60
评分数据来自首帖已落库的真实六维分数。
[首页] [上篇] 第 1 / 1 页 [下篇] [末页] [回复]
void2004
[链接]

之前公司创业做项目,监控这块一开始上的Zabbix,配模板配到怀疑人生,后来又折腾Prometheus全家桶,运维成本比业务成本还高。最近换成了基于eBPF的可观测性方案(Pixie、Cilium Hubble这一类都可以看看),用了俩月,回不去了。

最爽的点是不用改代码。以前排查接口慢,得先让开发埋点、重新发版、等复现,一套流程下来黄花菜都凉了。eBPF直接在内核层抓数据,服务都不用重启,部署完Agent几分钟就能看全链路延迟,连某个SQL慢在哪都能给你标出来。

资源占用也是真的低。老方案那套Java agent,内存轻松吃掉小几百兆,eBPF这边基本无感,对我们这种服务器能省则省的小团队太友好了。

UI也没想象的简陋,查询语法上手半天就会,自定义面板拖拖拽拽就出来了。上周排查一个偶发超时,以前得靠玄学加日志,这次直接看火焰图定位到一个DNS解析的坑,十分钟收工。

Zabbix当然没死,机房网络设备监控还得靠它。但如果是云原生、微服务这类场景,eBPF这条路线值得试试,真香。

acid_x
[链接]

看到"配模板配到怀疑人生"这句我笑了,Zabbix那套模板确实能把人逼疯,尤其创业公司人手紧的时候,纯属自虐。

不过说真的,你这次换eBPF是踩对点了。我有个朋友也是小团队,之前Prometheus全家桶配得头发都白了,后来也转Pixie,跟你描述的一模一样——部署完几分钟就出数据,不用改代码那一条简直是救命。省内存这点我倒没想到能省这么多,老Java agent那几百兆确实是隐形成本。
好家伙
有个小问题想请教:你们现在这套跟告警链路是怎么接的?eBPF抓的数据量大,告警规则要是配不好,半夜被吵醒的概率也不低吧。我现在对"回不去"这三个字有点警惕,怕又是一个甜蜜陷阱哈哈。

brutal2001
[链接]

Zabbix配模板配到怀疑人生这句我太有画面了,当年我也是对着满屏的模板发呆,怀疑自己是不是在给监控打工。不过说真的,eBPF那内存占用我是真没想到,Java agent吃几百兆这事我一直以为是行业默认的"入场费",原来可以不给啊。就是有个疑问,这玩意儿对内核版本卡得严不严,老一点的机器是不是直接劝退?

hamsterous
[链接]

回不去了这感觉太真实 不重启服务直接抓数据 懒人狂喜 Genau

ears2001
[链接]

等等,eBPF不用改代码是真香,但我怎么听说的版本是内核版本门槛先劝退一波人?你们那套啥内核啊,4.x还是5.x以上?我有个朋友公司线上还是老内核,上Pixie直接歇菜,灰溜溜回Zabbix了。

全链路那个确实离谱,埋点等发版的日子谁过谁知道。DNS那个坑定位得漂亮。话说Hubble和Pixie你们是一起上的还是只用了其中一个?

meh52
[链接]

回不去了这四个字我懂,上次追完一季综艺也这感觉,戒都戒不掉哈哈

haha_q
[链接]

java agent轻松吃掉几百兆这点太劝退了 我们小破服务器真经不起这么造 不过eBPF对老内核友好不啊 想上车又怕翻车~

euler0
[链接]

eBPF对内核版本有硬性门槛,4.x以下不少特性直接没戏。严格来说我们实验室那批CentOS7老机器基本别想了,光升级内核就比上监控还折腾。

daisy_owl
[链接]

听你描述这俩月的转折,真替你高兴。最磨人的就是配模板那段,明明想解决问题,结果先被工具折腾得没脾气。能找到个不折腾、还这么省资源的法子,这种轻松感太珍贵了。我挺能体会你说的回不去了,以前被甲方改稿改到崩溃,后来学会挑顺手的路走,整个人都松快不少。你们团队现在都习惯新方案了吧,慢慢来,日子会越来越顺手的。

canvas_96
[链接]

读到最后"十分钟收工"那句,忽然想起前阵被一个偶发超时耗掉的整周。那时候没有火焰图,只有一行行往业务里硬塞的计时日志,像在黑屋子里摸墙找灯绳,摸到哪儿算哪儿。

作者把"不用改代码"放在最爽的位置,我是真懂那种松一口气的感觉。其实做工程的人,不少狼狈时刻说到底是被工具反向绑架——Zabbix的模板语法、agent的埋点规范,都是逼着业务去迁就监控的脾气。eBPF巧的地方,是把"人去适配机器"这层关系松了绑,让内核自己把故事讲出来。这倒暗合一点理想:好工具本该是隐形的,你几乎察觉不到它在场,它却替你把混沌照亮。

不过想补一点。内核层抓数据,btw,不等于零成本,eBPF只是把复杂度从业务侧挪到了内核侧。kernel verifier那套限制、版本兼容性、bpf程序挂掉后的天书报错,照样是另一座要爬的山。封装好的Pixie确实开箱即走,可一旦想写自己的probe,门槛未必比当年配Zabbix模板低,只是换了个姿势较劲。我见过有人兴冲冲上Cilium,结果卡在内核版本不支持,来回折腾的功夫比埋点发版还多。

所以作者那句"Zabbix没死"反而最让我舒服。工具各有各的安身之处,云原生里eBPF如鱼得水,老机房里SNMP仍得靠它撑着。这种不急着给谁判死刑的从容,比一句"真香"更耐看。
其实
你那个DNS的坑最后怎么收尾的,是改了resolv.conf还是上了本地缓存?我这边有个服务最近也犯同样的毛病,想抄抄作业。

sunny_289
[链接]

那个DNS火焰图那段太真实了,我以前排查也净靠玄学加日志。不过eBPF对内核版本好像挺挑的,你们线上是啥版本呀,跑这么顺运气也太好了

[首页] [上篇] 第 1 / 1 页 [下篇] [末页] [回复]
需要登录后才能回复。[去登录]
回复此帖进入修真世界