许式伟的架构课
许式伟
七牛云 CEO
84945 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 89 讲
许式伟的架构课
15
15
1.0x
00:00/00:00
登录|注册

50 | 日志、监控与报警

接警:故障响应
添加监控项
日志系统作为监控与报警的基础
监控系统的设计哲学
监控的核心目标
好的监控与报警系统特点
监控与报警系统的复杂性
监控与报警系统

该思维导图由 AI 生成,仅供参考

你好,我是七牛云许式伟。
上一讲我们介绍了发布与升级,这是一项复杂的事务,有非常长的业务流程,包括:构建、测试、打包、部署以及配置变更。但总体上来说,发布与升级在 SRE 的工作范畴中,还并不是最难工程化的事务工作。我们简单分析就可以明白:发布与升级总体上来说,只和集群中服务之间的调用关系有关,而与具体服务的业务特性没有太大的相关性。
真正难工程化的是监控与报警。

好的监控与报警系统是怎样的?

监控一个复杂的业务系统本身就是一项极其复杂的事务。即使在具有大量现成的基础设施的情况下,设计监控项、收集数据指标、显示并提供报警支持这些工作,通常需在 10 人的 SRE 团队中,可能就需要有 1~2 人全职进行监控的构建和维护工作,这些工作都是非常定制化的,与具体业务密切相关。
如果我们把服务比作一个人的话,发布与升级更像是一个交通工具,尽管内部机制也许复杂,但是从功能上来说,它只是把我们载到某个目的地,人的个性在这里并不需要得到充分的重视。
但监控与报警不同,它更像是私人医生,需要因人而异,因地制宜,提供一套完整的健康保障方案。
监控与报警的目标是什么?
简单说,监控的核心目标就是要解决好两个问题:其一,什么东西出故障了。其二,为什么它出故障了,根因在哪里。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

监控与报警在SRE工作中扮演着重要角色,其优秀系统应能及时发现故障并找出根本原因。监控系统的黄金指标包括延迟、流量、错误和饱和度,应基于数学表达式并具有不同优先级。监控系统不仅用于报警,还可用于长期趋势分析、跨时间范围比较和临时性回溯分析。添加监控项是搭建监控系统后的挑战之一。优秀的监控与报警系统应具备高信噪比,能有效指引人员快速消除故障并找到根本原因。构建监控系统时需关注长尾问题、采用合适的精度以及监控项的设计哲学。接警后的第一哲学是尽快消除故障,每个监控项的报警应尽可能代表一个清晰的故障场景。解决故障后需进行根因分析,依靠异常现象分析和故障请求调用链分析。监控系统需要与不断演变的软件一起变化,且可能需要进行业务架构调整。负责业务监控的SRE需要经常重构监控指标,以最少的监控项全面覆盖系统的健康状况。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《许式伟的架构课》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(23)

  • 最新
  • 精选
  • J.Smile
    之前看许老师说,对于那些重点推荐的技术,以串联知识为要。学习服务治理应该也属于串联知识,但具体实施落地应该不需要开发工程师主导吧。如果开发工程师是治理的辅助角色,那其实这些治理知识其实知道并了解即可,不需要知道如何落地的细节步骤对吗?而且在一个不重视服务治理这一块的公司,就连知道了解都显得没有那么重要了!请老师解疑答惑!感觉我这个应该是属于角色定位的问题。

    作者回复: 架构师的思维方式一定要跳出职位分工本身。因为工种本身也是“架构设计”出来的。如果我们拘泥于既有的分工,就会无法发现落后的生产方式并且打破它。

    2020-01-12
    2
    19
  • alick
    将当前 CPU 利用率按秒记录。 按 5% 粒度分组,将对应的 CPU 利用率计数 +1。 将这些值每分钟汇总一次 ---------- 这里没太想明白:`将对应CPU利用率计数+1`具体是什么意思?汇总是指求和吗?

    作者回复: 5%粒度分组,cpu利用率就只有0-20这几种可能。如果当前这一秒cpu利用率是p%,那么就 counts[p/5取整]++。每分钟有60个点,也就是counts数组求和是60。这样我们就知道一分钟内cpu利用率的波动情况了。

    2019-10-23
    2
    7
  • J.Smile
    看完这节就产生了一个疑问,这些监控是否需要开发工程师去做呢?开发与运维(或者sre)的边界又在哪里呢?我常常会因为这样一篇文章就去学习容器或者日志系统等技术…

    作者回复: 在很多公司,这里不少东西不是让sre做,而是基础架构工程师来做。如果人力投入少,一般是sre做,多数情况下是选择合适的开源软件来做,而不是从零开始自己干。

    2020-01-12
    3
    3
  • Tesla
    老师,请问一些常规错误自动修复是依靠操作系统命令脚本吗?

    作者回复: 可以是任何语言的程序,shell脚本只是一种特例

    2019-12-22
    1
  • 王棕生
    许老师,文中说:先收集监控数据,再添加监控项。这里我有一个疑问:监控项都不知道,怎么去收集对应监控数据呢? 我们公司对应的做法是先定义监控项(qps delay error),然后再收集对应数据!

    作者回复: 其实是把运算放在收集数据前,还是放在监控侧的问题

    2020-08-02
  • 张裕
    对于客户端的监控,老师有什么建议?在某些数据如延时的监控上是否可以和服务端监控相互印证?

    作者回复: 客户端监控是指什么?

    2019-10-18
    2
  • Aaron Cheung
    本篇对 devops sre 都受益良多
    2019-10-18
    6
  • leslie
    老师今天的讲的这个其实是生产中蛮关键的:和一些研发或架构沟通过,甚至现实中很多中小企业会无视监控;合理的监控能精准的定位问题,而不是依赖人力去排除去沟通-尤其是软件上线后。 监控不是狼也不是摆设:合理的监控确实能方便定位问题;其实现在很典型的问题是有些大厂的云服务监控确实没有体现特性吧尤其是数据库这块,集成度越高的问题定位越模糊,在看似减轻运维操作的同时是反向增加了复杂度。耦合度越高,定位越困难;这是我现在深深的体会和感悟。
    2019-10-19
    5
  • 亢(知行合一的路上)
    日志、监控与报警太重要了,做好还是挺难的,对业务要深刻理解,才能评估出哪些是重要的指标。 之前日志记录一堆字段,看到就烦,后来去掉一些不必要的,瞬间清爽了,问题也容易发现了。 不断重构,哪里不爽就从哪里动手,让系统慢慢变好!
    2020-03-16
    3
  • 林铭铭
    少就是指数级的多!好的监控指标,出故障的时候能够一针见血发现问题。
    2021-08-13
    1
收起评论
显示
设置
留言
23
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部