Replies: 1 comment
-
如何做报警分级实践分享二告警对象打标签,根据标签扔到不同的群 我们业务报警是有不同的业务研发群,会根据规则向各自里丢,主要 webhook,群机器人 绝大多数能报警的组件都支持的,不需要写很多代码 脚本就好 就是从报警的标签和cmdb的关联比对要自己写代码,也不复杂 反正我现在关注最严重的一个群,出了问题,你们不处理,我就一个盯。这个群有问题必须处理。 也不落盘,就是快速通道 优先级,我也搞过,比较难定,系统不大可以定,系统大了,有时候你觉得是非关键的,但是对另外一个业务来说就是生死攸关 所以我就按产品分,各产品的sre和研发自己判断要不要处理 我们现在也不落,不过也有用到的时候,有次大数据的flink,按平时保留7天就行。结果他们一天搞出了10几天的日志量,就给拉坏了。 我们看的最多的是错误码的量 AI最重要的是学习,这个学习成本有点高 这个成本对90%的公司来说,招几个7*24监控初级工程师可能更划算 这就要 以后借助AI了。 其实我想过,AI能办到这个逻辑,不难 深度学习 我也相信未来会做好,这个是留给头部5%去做的 等5%的搞好了,在10%里面推广,然后10%把坑踩完,然后10%把使用成本减下来,然后我在用。。。美滋滋。。哈哈 跟老范说的,目前的学习成本太高。企业还是要考虑落地和实用性。 关心报警维度我现在关注的就是两个大盘指标,一个是全部日志的错误码量,一个就是报警数 这两个没有大规模的上升,就不会出啥特别大的事情 我们日志量大,一天二三十T,从里面捞错误码的量,一般来说按周同比不会有大的差异 我们专门把这个趋势抽出来,有大波动,基本就完蛋了。 出过好多次了,上次老板也在,怎么没有人关注。我跟他们说,你让谁看,一天大量的报警群,那个里面不是几千几万的。不分级,不梳理咂看。 各研发团队专门安排把业务的报警又调整了。有时要分级。 我们现在做一些简单的告警规则抑制,基本能降低百分之七八十 高招我们做了个告警 的中间层,把zabbix,skywalking,prometheus,NPM,日志,log,metic统一收集起来,判断要不要发,发给谁,怎么发 然后对关键节点做逃生告警,逃生告警是优先级最高的 然后再把这些数据源集中在grafana,权限开放给各个研发团队,我们写监控数据源的说明,培训研发,让他们自己配置自己关注的信息,自己配自己产品的报警 运维只关注大盘和基础架构 合理甩锅。。。。。。 各小团队定自己的看板和报警规则。 你自己的代码fgc多了,自己不看,能怪谁?哈哈 我们业务报警的判断是专门有个程序来判断的。 |
Beta Was this translation helpful? Give feedback.
-
可观测性解决什么问题
每当聊可观测性时,我就发现大家一致认为可观测性可以解决所有的问题,就好比一把屠龙刀,所过之处寸草不生。可你要是详细问问用可观测性做了什么的时候,就会有点时光倒流的感觉,又回到各种仪表盘,满屏指标的时代。你有可观测性的故事嘛?
监控难道就是一天看几百,上千的 面板。嘿嘿,这样不成机器人,累死了
监控告警定位
1、发现故障用的。 没有故障地方你天天看它干什么?2、那么多故障一个个都报上百上千的报警,短信都会把手机轰爆。何况人,根本最后没法看报警,报警要区分业务监控,系统监控的权重
我们线上很多业务,告警的地方特别多。 其实想想故障排查是人在做,那么多报警怎么做呢?
工程师很尴尬:短信几千个报警,每个都优先级高,怎么看?业务也不是全都懂啊,运维更闷逼。 这就是很多线上系统常遇到的事
如何做报警分级实践分享
真要分级的,我都是让把要死人的报警独立出来。其他各业务线自己负责自己一部分
主机宕了,核心ip,端口不通,要死人的那种业务的进程没了。。。
嗯,这点其实很有效:分级派发机制,把对应的报警精准发给 直接了解这块的人
我现在就盯几个关键的指标,其他都下放出去。
其他的内存高了,CPU高了,磁盘略高,带宽高了,根据监控对象的标签,直接扔到对应的群里面。对的,还有数据库,磁盘的
告警对象打标签,根据标签扔到不同的群。
反正我现在容器化,容器的CPU和内存一般不管。管宿主的核心指标。
Beta Was this translation helpful? Give feedback.
All reactions