从一到无穷大 #18 时序数据库运营SLI思考

本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。

本作品 (李兆龙 博文, 由 李兆龙 创作)，由 李兆龙 确认，转载请注明版权。

公有云时序数据库SLA

运营SLI指定

读者首先应该理解Service Level Objective，Service Level Agreement，Service Level Indicator之间的区别。

事实上在我看来SLO和SLA是偏向交付的概念，更关心系统的整体运作水平，而对于日常的运营工作，我们更关注SLI的健康情况；其次因为SLA与钱挂钩，相对来讲厂商不会激进的设定SLA，并会附加上严苛的免责条款，但是对于日常运营，在出现意外情况是我们仍然应该准确的获取SLI的值，以此发现，分析并解决问题。

KV系统模型，链路均较为简单，且约束明确（存在时延，可用性，一致性约束），我们可以设定如下指标作为内部人员分析问题的指标水平：

1. 失败量
2. 平均延时
3. 聚合分钟粒度最小成功率
4. 聚合分钟粒度最大P99

但是时序系统并不一样：

1. 首先写入链路复杂，存在直连proxy，kafka，prometheus等写入方式（写入请求不能用简单的写入时延，成功率统计）；
2. 其次系统内部关心整体趋势，对于零星的失败容忍性远大于KV系统，只要重试成功问题就不是很大（对于请求成功率本身要求并不是特别高）
3. 慢查询是可预期的，因为存在用户做长周期的分析需求，时序的特殊性会导致扫描几乎全量数据，这并不是错误的（查询不能像kv一样统一分析，也就是说P99指标用处不大）
4. 有时与业务捆绑较深，比如一个页面可能触发N次查询，当多人同时点击页面时，如果只是衡量系统侧每一个查询性能是片面的，应该从用户的角度分析，将一个session内的查询视为一个整体，用session粒度去做分析，这样服务降级也好做；

暂且不考虑技术，站在用户的角度我认为只有两点较为重要：

1. 数据产生到实际可读整体链路（kafka，prometheus，直连）需要的时间，包含错误/重试（请求失败，过载不care）
2. 一个用户session内的查询时延 （单次查询时延不care）

站在开发的角度则需要更为细致的指标，简单来讲如果我运营一个时序数据库系统，如何能够衡量健康情况，如何快速发现问题：

1. 数据产生到实际可读的时间消耗（包含写入kafka延迟，数据在Kafka停留时间，接收到数据整体处理流程的时延，包含总体失败重试时延）
2. 一个用户session内查询总体时延（体现在用户感受上）：失败量，平均延时，聚合分钟粒度最小成功率 ，聚合分钟粒度最大时延P99；
3. 时间范围覆盖较小的查询请求：失败量，平均延时，聚合分钟粒度最小成功率 ，聚合分钟粒度最大时延P99；
4. 时间范围覆盖较大的预期慢查询，所以需要感知慢查询对应的sql，时间线和数据量，要让慢查询预期的慢，不符合预期的慢时需要分析原因；

事实上这样决策的原因有这么几点：

1. 读写差异巨大，读写的SLI设定应该分离，而且写入偶尔的失败是可预料的，频繁的告警没有意义
2. 数据库内的写可能只是链路的一部分，我们希望跟踪全链路的写入指标
3. 时间范围不同的查询告警指标的设定应该不是一致的
4. 我们希望通过session做服务降级，也希望更好的理解业务层面的SLI，单独的查询分析不能cover这一场景

当然还有用于大盘数据展示集群整体趋势的监控数据指标，这个不再细谈，大体思路就是cluster，pod，account，database，account，partition，measurement级别的数据分析；kafka本身topic/partition的待commit数，生产速度，消费速度等。

当然本篇文章只讨论读写；CQ，降采样，流计算的SLI我们不讨论，但是链路和指标本身也都很有考量的余地。

总结

工作已经一年多了，从COS索引层到云原生多模数据库，愈来愈发觉监控体系和运营手段之于一个云数据库系统的重要程度，运营的能力和工具自动化也是各大厂商雄厚能力的体现，当然也是工程师综合素质提升必须要过的一关，不会运营永远不能有底气的说自己做过存储和DB。

参考：

1. 时序时空数据库（TSDB）服务等级协议
2. 金山云时序数据库InfluxDB服务等级协议
3. 天翼云时序数据库Influx版服务等级协议
4. 万字解读｜怎样激活 TDengine 最高性价比？
5. Lindorm Service Level Agreement
6. Amazon CloudWatch Service Level Agreement
7. CloudWatch Publish custom metrics
8. 时序数据库TSDB服务等级协议SLA(V2.0)
9. 腾讯云云数据库服务等级协议
10. 云数据库 GaussDB NoSQL （GaussDB NoSQL）服务等级协议
11. InfluxDB Cloud 2.0 Service Level Agreement
12. InfluxDB Cloud 3.0 Dedicated Service Level Description
13. Amazon Timestream Service Level Agreement