71 lines
2.2 KiB
Markdown
71 lines
2.2 KiB
Markdown
|
# 第六章 分布式系统的监控
|
||
|
|
|
||
|
|
|
||
|
|
## 术语定义
|
||
|
|
|
||
|
|
关于监控的一些术语定义。
|
||
|
|
|
||
|
|
### 监控(monitoring)
|
||
|
|
|
||
|
|
收集、处理、汇总，并且显示关于某个系统的实时量化数据。
|
||
|
|
|
||
|
|
### 白盒监控(white-box monitoring)
|
||
|
|
|
||
|
|
依靠系统内部暴露的一些性能指标进行监控。
|
||
|
|
|
||
|
|
### 黑盒监控(black-box monitoring)
|
||
|
|
|
||
|
|
通过测试某种外部用户可见的系统行为进行监控。
|
||
|
|
|
||
|
|
### 监控台页面(dashboard)
|
||
|
|
|
||
|
|
提供某个服务核心指标一览服务的应用程序。
|
||
|
|
|
||
|
|
### 警报(alert)
|
||
|
|
|
||
|
|
目标对象是某个人发向某个系统地址的一个通知。
|
||
|
|
|
||
|
|
### 根源问题(root cause)
|
||
|
|
|
||
|
|
指系统(软件或流程)中的某个缺陷，如果这个缺陷被修复，就可以保证这个问题不会再以同样的方式发生。
|
||
|
|
|
||
|
|
### 节点或者机器(node/machine)
|
||
|
|
|
||
|
|
指物理机、虚拟机或者容器内运行的某个实例。
|
||
|
|
|
||
|
|
### 推送(push)
|
||
|
|
|
||
|
|
关于某个服务正在运行的软件或者其配置文件的任何改动。
|
||
|
|
|
||
|
|
## 监控系统的四个黄金指标
|
||
|
|
|
||
|
|
1. 延迟
|
||
|
|
服务处理某个请求需要的时间。
|
||
|
|
2. 流量
|
||
|
|
使用系统中某个高层次的指标对系统负载需求所进行的度量。
|
||
|
|
3. 错误
|
||
|
|
请求失败的速率(包括显示或隐式失败)。
|
||
|
|
4. 饱和度
|
||
|
|
服务容量有多满。通常是系统中目前最为受限的某种资源的某个具体指标的度量。
|
||
|
|
|
||
|
|
## 监控系统设计理念
|
||
|
|
|
||
|
|
监控系统设计的核心理念是简化，直到不能再简化。
|
||
|
|
|
||
|
|
- 对于最能反映真是故障的规则应该越简单越好，可预测性强，非常可靠
|
||
|
|
|
||
|
|
- 对于不常用的数据收集汇总以及警报配置应该定时删除
|
||
|
|
|
||
|
|
- 收集到的信息，但是没有暴露给任何监控台或者没有被任喝警报规则使用的，应该定时删除。
|
||
|
|
|
||
|
|
度量指标时应使用合适的精度，系统的不同部分应该以不同的精度度量。
|
||
|
|
|
||
|
|
## 应对警报的深层理念
|
||
|
|
|
||
|
|
1. 紧急警报应该是立即需要进行某种操作的，每天只能进入紧急状态几次，避免导致狼来了效应。
|
||
|
|
|
||
|
|
2. 紧急警报应该是可以具体操作的
|
||
|
|
|
||
|
|
3. 紧急警报的回复都应该需要某种智力分析过程。对于只需要一个固定的机械动作的警报，不应成为紧急警报。
|
||
|
|
|
||
|
|
4. 紧急警报都应该是关于某个新问题的，不应该彼此重叠
|