谷歌SRE理论读书札记：监控分布式系统

谷歌称自己对于建立监控告警系统已经形成了一些基本理论，同时也有一些很好的实践经验。

一些名词定义

Monitoring
包含以下几部分：收集（collecting）处理（processing）聚合（aggregating）展示（displaying）一个系统的实时数值型数据，如请求数与类型，错误数与类型，处理时间与服务寿命。
white-box monitoring
白盒监控，根据系统内部暴露的指标进行monitoring，如服务产生的日志，或者JVM的profiling接口
black-box monitoring

dashboard
展示服务核心数据的概览（summary view）
dashboard可以有过滤器与选择器，但最核心的是上面的指标一定要和这个系统的直接用户息息相关
dashboard还可以用于展示ticket queue（这个东西有点类似工单的意思），搞优先级bug的列表，目前处于on-call状态工程师的信息（谷歌SRE在后面有专门讲on-call的章节，由此可以窥探当工具和工作模式相互关联成网之后的样貌）
alert
给人读的提示（关键是，有了必须得去读，如果某类alert没人关注，那不如没有）alert会被分成 tickets,emails alerts 以及pages
root cause
node and machine
push
对于系统软件或配置的一次变更

为啥要Monitoring?

1，分析长期趋势
其实根据上文的定义，就可以看到，所谓monitoring，并不仅仅是做个花里胡哨的dashboard，而是一个辅助主要业务系统的子系统
monitoring要能帮助分析（这里可能是对于运营人员）我们的数据库已经多大了，增长的有多快？我们当前的存储有没有可能无法满足30天之后服务需求？
我们服务每天的活跃用户增长有多少？
从这几个问题也可以看出，SRE并不是只关心软件，同样也关心服务的实际情况（也就是业务）
2，对实验组进行对比
帮助解决诸如以下问题：我的memcache集群添加一个额外节点之后，缓存命中率有没有提升？ng代理的版本由1.17升级到1.18后核心性能指标有无变化
个人认为，这里的意思，大致就是制定好架构之后，也可以通过系统的monitoring数据给架构设计以反馈
3，alerting
告警，没什么好说的，告诉你有东西出问题，需要人给尽快处理好
4，创建dashboard
dashboard是服务的概览（后面会提到服务的黄金4指标）
5，帮助debug系统问题

对monitoring设置合理的期望

症状vs根源

黑盒vs白盒

黄金4指标

简单说，如果你的monitoring提供不了下面4项数据，那么你在dashboard上设置再多的指标意义也不是很大

latency
服务用于一个请求需要花费的时间，并且应该区分成功请求、异常请求的处理延迟，最好能将不同的异常请求进一步分类与统计

traffic
流量，对于一个流形系统，这项指标会比较关注网络IO与并发会话的情况。而对于一个key value存储系统，这项指标会衡量读写（transaction and retrive)

errors
错误率（也需要精细化，比如HTTP服务的50X错误，需要能分开统计）

saturation
服务饱和度，上面几项都比较好理解

Worrying About Your Tail

这部分的大致意思是选取直方图(histogram)

选择一个合适的粒度

尽可能简单

把规则绑在一起

为长期而做monitoring