请选择 进入手机版 | 继续访问电脑版

ITIL,DevOps,ITSS,ITSM,IT运维管理-ITIL先锋论坛

 找回密码
 微信、QQ、手机号一键注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 164|回复: 0

Google SRE 如何做监控解密

[复制链接]
发表于 2020-12-14 11:01:25 | 显示全部楼层 |阅读模式
今天,结合《SRE Google运维解密》,尝试提炼出所有关于监控系统设计的精髓,希望能捕捉到对现有系统有建设性的改进意见。
$ t% g  h# z: E* D; R" r& r6 M8 H) H
1.png
2.png
3.png
5 \6 F6 D# S" m. T; I1 s5 w- A# O
脑图整理的很详细,若图看不清,想办法放大,下面开始重点讲解。
6 X$ l) }7 Y+ d

7 \: Z- b* l  i. F为什么要做监控?  g: `. C1 c/ w

0 T& |: |' f  l' h
. U5 r* T6 a' `- i" M- Y9 {" d
在远程办公的当下,你所负责的系统,能正常提供服务显得尤其重要。倘若没有一套监控机制,犹如系统在线上裸奔,时不时需要靠人肉去判断系统是不是崩掉了,你肯定忍不了,你肯定会想要是打造一款监控系统。

0 T, o* Q' H( O- D
监控为什么重要?Google SRE 解密,离开了监控系统,我们就没法辨别一个服务是不是在正常提供服务;没有一套设计周全的监控体系,就如同蒙着眼睛狂奔;监控系统是服务运维中不可或缺的一部分。
) y) `: E& g# v, x# B8 v: T
无论是研发、运维,估计几乎每天都会发问几句:什么东西出故障了?为什么出故障?

& @3 V" M9 x& e% f
其实,什么东西出故障了,是问题的现象;为什么出故障,是问题的原因。例如,网站正在返回 HTTP 500 或者 404,究其原因是数据库服务器拒绝链接;接口响应速度很慢,分析原因是 CPU 被某个排序操作占满啦。
0 u) e; l& t8 w& @, d! o  M2 q
监控解决啥问题?Google SRE 解密,监控系统应该解决现象与原因两个主要问题。
; j$ x  _% k4 A8 M  Q; ^6 W! t$ `
为什么要监控呢?Google SRE 解密,监控一个系统有多个原因,主要包括如下几项。
1、分析长期趋势。例如数据库目前的数据量,以及增长速度;每日活跃用户的数量增长的速度等。
2、跨时间范围的比较。增加节点后,memcache 的缓存命中率是否增加;网站速度是否比上周速度要慢等。
3、报警。当某项东西出现故障了,需要立刻有人修复,或者需要有人尽快查看。
4、监控台页面 dashboard。用来回答有关服务的一些基本问题。
5、临时性的回溯分析。
% \* `- i. R" R8 L: F- q- n
5 ^- ^; P3 \9 Z4 A% _/ Z+ b
做监控要搞懂哪些术语?
7 Y$ P7 q+ ?- T) j; J$ n4 `
8 K  u1 j" ~% o! M7 Q
  c. g3 G  }/ k+ y, K7 G, e/ N3 m
2020 年计划在 AIOps 上有所建树,相关概念性的东西还是要普及,底盘还是要打扎实一些。

5 R/ N3 R# u# Y8 j. T+ t, w/ ]
4.png

: M5 a/ P- t$ U. o
有关监控的部分相关术语,脑图中整理的很详细了(一定要好好看图呦),不再赘述。

9 n9 U& i# w) R$ S9 k" N. F: f
在这里,要重点说一下服务质量术语,尤其是当我们想在指标监控上有所尝试时,这些术语显得尤其重要。
. l) @; C2 Y, @  F9 x

" _; T  K6 t0 [* u
什么是服务质量指标呢?服务的某项服务质量的一个具体量化指标,例如系统吞吐量,每秒请求数量;请求延迟,处理请求所消耗的时间。

! q8 j  V1 ]& ^
5.png

$ f1 X! m  g/ \6 h
+ w( \7 p) `  F: j% }8 G/ M
如图中整理所示,不同类型的系统,指标也略有不同。例如,用户可见的服务系统的指标,通常关心可用性、延迟,以及吞吐量;存储系统的指标则强调延迟、可用性和数据持久性;大数据系统的指标,通常关心吞吐量和端到端的延迟。

" O1 A9 Q3 c0 @
Google SRE 建议我们,在设计时,要考虑指标的标准化,构建一套可以重用的指标模板。设计监控系统时一定要追求简化,指标简化,直到不能再简化。

$ k4 m* v7 a/ C# a6 t1 h1 l' Y1 T/ M5 z& E6 v
什么是服务质量目标呢?服务质量目标说的是服务某个指标的目标值或者范围。
- y% h: X) e4 Z/ n
Google SRE 建议我们,在实践时,应该从思考用户最关心的方面入手,而非从现在能度量什么入手;另外,与其选择指标,再想出对应的目标,不如从想要的目标反向推导出具体的指标。
3 x; |+ x: \  U6 n* `( Z
9 P' ~  h! X' d9 Z/ x
监控的四个黄金指标
  M% t, s8 l6 M& O) t& d& f
; X7 Q$ B1 V# y! J$ s  L& V" h- H) K/ N. ?
监控系统的四个黄金指标分别是延迟、流量、错误和饱和度。
. A' [0 }4 ~, o! }" T# Z& E& V7 `
6.png
& j6 p; D3 N' h4 k% {* e
如果我们度量所有这四个黄金指标,同时在某个指标出现故障时,或者对于饱和度来说,快要发生故障时,能发出警报,若能做到这些,服务的监控就基本差不多了。

9 W2 h4 C1 X: c- h" v! N& @! A
+ Z0 s# W3 `+ i  J+ |: }4 b
监控的三类重要输出3 R/ @& H5 w* {) y9 U- p2 A
/ C% F; E5 ~" R. N; g$ H4 C
: h- ]: p# \; M  S+ z; I0 c/ F
如开篇对话场景对应的系统,设计时采取的便是针对某个特定的情况或者监控值,一旦出现情况或者监控值超过阈值就触发 E-mail 警报,也就是所谓的最普遍和传统的报警策略。

/ z. C* j4 I# E- X1 _  b# L5 _
SRE 解密:这样的报警策略并不是非常有效:一个需要人工阅读邮件和分析警报,来决定目前是否需要采取某种行动的系统,从本质上就是错误的。监控系统,不应该依赖人来分析警报信息,而是应该由系统自动分析,仅当需要用户执行某种操作时,才需要通知用户。

  ^  z- J3 y/ N
这或许就是现有很多监控系统可以优化改进之处。

1 d& k+ D: @$ T& c. {
另外,一个好的监控系统应该只有下列三种输出。
: A- d) z6 C) J
7.png

/ [5 x4 c/ X, ~+ Q
Google SRE 建议我们:每当收到紧急警报时,应该立即需要我执行某种操作;每天只能进入紧急状态几次,太多就会导致「狼来了」效应;每个紧急警报都应该是关于某个新问题的,不应该彼此重叠。
" W" i3 W0 A$ p: M. k
5 O# a) D% h- Q# W5 u  W! }; b# b
实践才是硬道理# ^" S6 F# \* ^! B# A! h
. l/ o- }! s/ W7 K: S
十年磨一剑,Google 的监控系统 Borgmon 仍在不断的改进和完善。

2 R8 A' Y7 J2 @% X/ u
8.png
2 k: x4 _+ V$ D0 c
虽然 Borgmon 仍是 Google 内部工具,但是近年来,监控系统也经历了爆发式增长:Prometheus、Riemann、Heka、Bosun 都是开源软件中与 Borgmon 理念类似的系统,尤其是 Prometheus。
: M& Q9 d) z- F, V" P: Z
所以,我们可以利用开源软件,尝试落地监控和报警的理念。

7 {* e+ }$ X- |! |9 Z4 D: E




上一篇:读《SRE:Google运维解密》之后,我想到了什么
下一篇:SRE学习小心得

本版积分规则

本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

QQ|小黑屋|手机版|Archiver|艾拓先锋网 ( 粤ICP备11099876号-1 )|网站地图

Baidu

GMT+8, 2021-1-20 07:26 , Processed in 0.162978 second(s), 33 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表