浅谈DevOps & Observability

公司内部分享

公司20年老系统+传统组织, 正面临数位转型中
团队管理与开发定义SLO目标
DevOps这文化带给传统开发团队的新思维与习惯
纪录,监控与可观测性带给开发与维运双方团队的好处

文章连结

Talking About DevOps & Observability

Outline

运维盲区Operational Blindness
监控Monitoring
纪录Logging
指标Metrics
Observability

前言

主要针对公司内部现况做分享.
站在DevOps的右侧, 偏运维角度看事情
Observability的部分只是介绍

Operational Blindness

War Story

Note:
某天中午, 运维组内暴发出警报通知, 一堆讯息涌现. 大家也跳了起来, 发现网站瘫痪了, 外部监控近几次健康检查都没过, 而触发了警报.

Note:
发现网站瘫痪了

Black-Box Monitoring

Note:
登入主机监控系统, 发现网站的系统指标正常, 记忆体也还有, CPU没到100%, Disk跟IO也还在容许范围内, 资料库也活着

Note:
不知道原因只好把问题扩大到开发团队, 因为主机与网站服务的进程本身看起来还算正常

Note:
开发团队也不确定要看什麽, 且它们没有直接登入正式环境主机的权限; 也不会让所有人都有权限进入主机, 管理成本高与资安风险高

Note:
开发团队只好与运维团队一起工作并且只能发号施令
最终在资料库上发现, 一堆慢查询跟一堆连线处於CLOSE_WAIT状态
在Web服务上也看到有几乎一样多数量的进程
推测很可能Web服务已经达到了最大处理容量并停止响应新的request(例如healthcheck)
最後把db的query session都砍掉, Web服务上的请求队列也清空, 就正常了

Note:
查找这些问题的根源, 浪费了很多时间;
当问题被升级时, 被波及的人也没足够权限查看对找问题有用的主机资讯与服务资讯.
最终还是得依赖运维团队.且在这种情境下, 每一分钟的无法服务或停机时间都是要钱的
运维团队之所以只能把问题扩大, 是因为他们能看到的就几乎只有主机的监控指标,

Question

Dev/Ops团队的分离, 这样的组织与沟通方式, 有间接成本的产生
Note:
传统的结构上, 有一条明显的红线把开发与运维的职责划分开.
运维团队负责主机与基础设施, 使得应用程序的交付成为可能.

Note:
Developer与Operations如果组织结构与合作方式上职责分的太开, 往往会像拔河一般, 分散了力道.
相互拉扯中, 复原时间就流逝了.

Note:
最可怕的还是, 使用者对平台提供的服务品质没信心了, 跳去竞品平台了

DevOps

What is SRE | Tasks and Responsibilities of an SRE | SRE vs DevOps

Note:
Developer与Operations不应该相互拉扯在拔河, 而分散了众人的力道.

非同步系统的服务水准保证浅谈非同步系统的 SLO 设计-91APP

Note:
SLI（service level indicator）
指的是指标，例如：QPS，TPS，Duration，准确性，延迟，性能等

不是所有的metric都视为SLI，选择尽可能少的SLI，但这些SLI却能说明服务是否稳定，可靠。

SLO（service level objective）:服务等级目标
指的是一段时间内的目标，例如：1个月内的QPS 99.99%，响应时间<10ms等等

SLO是一组值的范围，这个值就是由SLI定义的服务级别数值。自然的SLO定义就是，某SLI在正常情况下需要小於某值或者处於某个大小值之间。
选择一个合适的SLO并不是一件容易的事情，当然一开始并不需要设定好这个范围

SLA （service level agreement）:服务等级协议
指的是整个协议，协议的内容包含了SLI，SLO以及恢复的方式和时间等等一系列所构成的协议

基於时间的可用性

基於时间的可用性 = 系统正常运行时间 / (系统正常运行时间 + 停机时间)
SLO 99.95%, 以一年来看, 不可用占了4小时22分钟
SLO 99.99%, 以一年来看, 不可用占了52分钟

基於次数合计的可用性

基於合计的可用性 = 成功请求数 / 请求数总和
SLO 99.99%, 如果一天要接受2.5M个请求, 每天错误个数应<250个

事件处理案例

基於延迟

SLO 99% 前台每秒User访问延迟 < 300ms

[架构师的修练] #2, SLO - 如何确保服务水准?

Monitoring

Types of Monitoring

Multi-Cloud Monitoring

Monitoring Layers

Logging

Deal with discrete events

Application debug or error messages
Audit-trail events
Request-specific metadata
Specific events
Note:
应用程序错误讯息、稽核事件、HTTP请求事件

Log Monitoring

Troubleshooting
Monitor

Clearly log level
Good log message (Structured Log)
Log aggregation
Note:
Show Loki
单行Log, 又是JSON格式, 针对各种类型的服务定义出固定的metadata key

Defect of Log Monitor

Low value density

[INFO] .... initializing...
[INFO] ... request from xxx.xxx.xxx.xxx user_id xxxxxx

Note:
有价值的资讯密度太低, 很多都是第一行那样的无价值资讯

这部影片主要讲了很多
Log Cetralize and Monitor的好处
跟Log要怎清楚的表达
Logging in the age of Microservices and the Cloud

Write log into RDBMS
- log如果并发写入很高, 写入的资料库又是RDBMS, 并发事务量不会很高
  - 就算buffer pool加大, 也是有极限的, 也不建议
- log字段很多种类, 索引选择困难
- DB真出事了, 想登入看log也没法, 搞不好还没写进去
- 很容易就是压死DB的那根树枝
- 让DB回归, 业务状态与资料的存储与存取吧

Metrics

4 Golden Signals

Latency : time to serivce a request
Traffic : requests/second
Error : error rate of request
Saturation : fullness of a service

SRE-book

Observability: Metric, Logging, and Tracing, Oh My!

Note:
反映用户体验，衡量系统核心性能。如：系统的处理时间，作业计算系统的作业完成时间等。

反映系统的服务量。如：请求数，发出和接收的网络封包大小等。

帮助发现和定位故障和问题。如：错误总量、调用服务失败率等。

反映系统的饱和度和负载。如：系统占用的内存、作业队列的长度等。

Metrics for Prometheus
- metric name and label sets

<metric name>{<label name>=<label value>, ...}

# TYPE http_requests_total counter
|--------------------------- Metric ----------------------------|-timestamp -|-value-|
|--- metric name --|------------------ labelsets ---------------|
http_requests_total{code="200",handler="prometheus",method="get"}               721

Note:
label sets代表了这个metric name下的一个维度,可以有多个维度方便做聚合操作

Metric Types

- Counters (rate)
- Gauges (value)
- Distribution 
	- Histogram (heatmap)
	- Summary

Observability of Distributed Systems

Note:
counter只增不减, 通常用来取得request总量, 任务完成的数量, 错误发生次数, 或者计算某段时间内的rate变化率; 能事前透过压力与负载测试能取得可预期的上限, 做监控与警告;
查询当前系统中，访问量前10的HTTP URL.

gauge即时变化情况, 随着时间不断变化, 通常用来记录cpu, mem用量, coroutine数量, pool usage, 并发请求数...;
透过计算样本的线性回归模型, 对数据的变化趋势进行预测.

Histogram会对观测数据取样，然後将观测数据放入有数值上界的桶中，并记录各桶中数据的个数，所有数据的个数和数据数值总和, 请求时延, 各种有样本数据;用来区分是平均的慢还是长尾的慢,快速了解监控样本的分布情况
Summary 与 Histogram 类似，会对观测数据进行取样，得到数据的个数和总和。此外，还会取一个滑动窗口，计算窗口内样本数据的分位数。