wxya（个人网站）SRE指标
监控的4个黄金指标
《SRE：Google运维解密》中提出，监控系统的四个黄金指标是：延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation）。
SRE的四个黄金指标是构建成功的监控和告警系统的一些基本原则和最佳实践
- 延迟：延迟是信息发送方和接收方之间的时间延迟，以毫秒（ms）为单位。而原因往往是由于数据包丢失网络拥塞和网络抖动造成的，称为“数据包延迟差异”延迟对客户体验有直接影响，转化为成功请求的延迟和失败请求的延迟。
- 流量：流量是系统工作量带来的压力。它通过每秒查询数（QPS）或每秒事务数（TPS）来衡量。企业通过数量来衡量这一点：关键绩效指标（KPI）是在给定时间来到站点的人数。这与商业价值有直接关系。
- 错误：错误是根据整个系统中发生的错误来衡量的。被认为是服务错误率的重要指标！有两类错误：显式错误，如失败的HTTP请求（500个错误代码，例如）；隐含错误是成功的响应，但内容错误或响应时间长。
- 饱和度：饱和度定义了服务的过载程度。它衡量系统利用率，强调服务的资源和整体容量。这通常适用于CPU利用率、内存使用、磁盘容量和每秒操作数等资源。仪表板和监控警报是帮助你密切关注这些资源并帮助你在容量饱和之前主动调整容量的理想工具
监控指标设计原则
长尾问题
假设一个web服务的http请求平均耗时为100ms,单看这个数据觉得服务性能没问题，但可能有1%的请求耗时超过5s，而这1%的请求就有可能引发用户投诉或其它风险。由于是计算的平均值而容易被忽略，最好的方法是将请求延迟分段统计。
采用合适的精度
监控数据的高频率收集、存储、分析成本很高，要根据监控对象以及监控目标合理设置监控周期、监控频率等。
减少告警误报
现在很多公司抱着“宁可错杀一万，也不能放走一个”的原则制定监控标准，这样做的后果就是运维人员疲于奔命，时间一长就会造成"狼来了"的后果。增加新的监控规则时，可以遵循以下原则：
- 收到紧急告警时，应该立即需要进行某种操作。每天只能进入紧急状态几次，太多就会导致“狼来了”效应。
- 紧急告警都应该是可以具体操作的。
- 紧急告警的回复都应该需要某种智力分析过程。如果某个紧急告警只是需要一个固定的机械动作，那么它就不应该成为紧急告警。
- 紧急告警都应该是关于某个新问题的，不应该彼此重叠。
监控系统建设原则
以上关于监控指标的讨论累加起来就会形成一个复杂的监控系统。
监控系统尽量简化
复杂是没有止境的，过于复杂的监控系统维护起来麻烦，而且经常出问题。
- 那些最能反映真实故障的规则应该越简单越好。
- 那些不常用的数据收集、汇总，以及告警配置应该定时删除。
- 收集到的信息，但是没有暴露给任何监控台，或者被任何告警规则使用的应该定时删除。
监控系统应作为一个独立的系统运行
保持监控系统相对独立、清晰简单。和其他系统保持松耦合，可以采用API来收集性能数据。
监控系统需要长期维护
监控系统需要跟随不断演变的软件一起变化，软件经常重构，负载特性和性能目标也经常变化。现在的某个不常见的、自动化比较困难的告警可能很快就会变成一个经常触发、需要一个临时的脚本来应对的问题。这时，应该去寻找和消除背后的根源问题：如果这种解决办法不可行，那么这条告警的应对就必须要完全自动化。
Loading...