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