智汇 IT
城启新篇

可观测性落地别当监控工具收藏家

上周在南京新街口跟个做电商的技术总监吃盐水鸭,他喝了半瓶冰啤酒就开始吐槽。去年光买监控工具就花了小四十万,Prometheus、Grafana、ELK、商用链路追踪平台,能接的全接上了,光大屏就给老板做了三块,红的绿的跳得跟灯会似的。结果今年618零点,支付接口挂了,整个技术部挤在作战室盯了四十分钟大盘,愣是没发现是支付网关的SSL证书过期了。

那天的鸭都没吃完。

你买的不是可观测性是监控拼盘

很多人到现在还把监控和可观测性混为一谈。监控是什么?是你提前预判到可能出问题的节点,设好阈值——CPU超过80%报警,接口超时超过500ms报警,磁盘剩10%的时候报警。这东西好用,但它只能解决“已知的已知”。可观测性解决的是未知的未知问题——也就是那些你从来没预料到会发生的故障,比如某个依赖的第三方服务偷偷改了接口字段,比如某个机房的DNS解析出现了区域性的抖动,比如你写的某个定时任务在流量高峰的时候突然占满了数据库连接池。

电商大促期间可观测性告警风暴界面
电商大促期间可观测性告警风暴界面

我见过太多团队,把各个监控工具的数据往一个大盘上一拼,就对外宣称自己做了可观测性。实际上呢?指标存在Prometheus里,日志存在ELK里,trace存在专门的链路追踪系统里,三个系统的时间戳差个几秒都是常事。要查个线上问题,得开四个浏览器标签页,先从大盘上看到哪个接口错了,再复制traceId去日志系统搜,再去链路系统看调用路径,最后还要登服务器看进程状态。整套流程跑下来,半小时都过去了,用户早就投诉完了。这哪是可观测性,这是给技术人找罪受。

别被工具厂商的话术绕进去

现在打开任何一个可观测性厂商的官网,全是“全栈覆盖”“万亿级数据处理”“百款预制大盘”的宣传语。说实话,我真的想问一句,预制大盘对你家的业务有啥用?你是做生鲜电商的,核心链路是用户下单→库存扣减→骑手派单→配送路径规划,跟那些做企业SaaS的链路能有半毛钱关系?

之前接触过一个做在线教育的团队,咬咬牙上了某头部厂商的可观测性平台,年服务费二十多万。结果上线半个月就开始骂娘——平台默认的大盘全是服务器CPU、数据库连接数这些通用指标,他们最关心的“直播间卡顿率”“连麦信令延迟”“课件加载耗时”这些自定义指标,得自己写复杂的PromQL去拼,拼到最后发现,还不如他们之前用开源工具攒的大盘好用。

分布式链路追踪跨服务调用可视化界面
分布式链路追踪跨服务调用可视化界面

真正的可观测性从来不是给老板做汇报用的。它要解决的是线上故障发生时,技术人能不能最快速度定位根因。举个最实在的例子,当用户在APP上点“提交订单”没反应的时候,你能不能顺着这一次请求的trace,直接看到从网关到应用服务到库存系统到支付接口到消息队列,每一跳的耗时、返回状态、关联的错误日志,甚至能关联到这个用户当时的网络环境、手机型号、所在的机房节点。不用挨个@各个服务的负责人问“你那边有没有问题”,不用翻半天日志找报错栈。省下来的沟通时间,比啥都值钱。

落地别搞大而全先抓核心链路

很多团队一开始做可观测性,就抱着“要把所有系统的所有数据全接进来”的想法,光数据清洗、标签统一就能搞三个月,等好不容易把所有系统都接完,当初牵头做这个项目的技术负责人都离职了。

落地可观测性最忌讳贪多求全。你先把自己家最核心的三条业务链路捋清楚——对电商来说就是用户登录、商品下单、支付回调,对本地生活来说就是用户发单、骑手派单、订单完成,对在线教育来说就是进直播间、连麦互动、课程回放生成。就这三条链路,先把链路上所有服务的调用关系、每一跳的核心指标、关联的日志、全链路的traceId全打通。

我去年帮南京一个做社区团购的小团队梳理可观测性体系,他们一开始接了27个服务,配了180多条告警规则,每天告警响三百多次,大家早就把告警通知给关了。后来我们把非核心链路的所有告警全关了,只留三条核心链路的关键告警:链路整体成功率、P99接口耗时、核心依赖的错误率。剩下的所有告警全做聚合,按小时推一次摘要。调整完第一天,整个团队收到的告警数从三百多降到了7个,大家终于不会对告警麻木了。之前的告警跟狼来了没区别,真出事的时候没人愿意看。

可观测性这东西,从来不是买个贵的工具就能搞定的。它本质上是你团队对自己业务的熟悉程度。你连自己的核心链路有多少跳、哪个环节最容易出问题都数不清楚,买再贵的平台也白搭。

毕竟,工具永远是工具。

免责声明:市场有风险,选择需谨慎!此文仅供参考,不作买卖依据。如有侵权请联系删除。
文章名称:可观测性落地别当监控工具收藏家
文章链接:https://m.itcdj.com/it/325.html