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

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

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

公有云时序数据库SLA

运营商产品	每服务周期服务可用率不低于99.9%	衡量服务不可用	数据指标从采集到用户可查询的延时
阿里云TSDB[1]	✅	当某一分钟内，客户所有试图与指定的云数据库实例建立连接的连续尝试均失败，则视为该分钟内该云数据库实例服务不可用。在一个服务周期内云数据库实例不可用分钟数之和即服务不可用分钟数。
金山云influxdb[2]	✅	当客户所有试图与指定的单个InfluxDB实例建立连接的尝试均失败，且该状态持续一分钟或更长时间则视为该InfluxDB实例服务不可用。
天翼云influx[3]	✅	指依照时序数据库Influx版服务系统中日志记录，因天翼云原因时序数据库Influx版实例连续超过五分钟无法访问，低于五分钟的不可用时间不计算在内
TDengine[4]	✅	没在公开页面找到
Lindorm[5]	✅	一个计费月内，您的服务中所有运行实例均无法与外部连接或无法运行的总分钟数。
Amazon CloudWatch [6]	✅	对于 Amazon CloudWatch Metrics API 调用和 Amazon CloudWatch Logs Data Ingestion API 调用，此类功能处理的请求在 5 分钟时间间隔内因服务器错误而失败的百分比；以及对于 Amazon CloudWatch Alarms，5 分钟时间间隔内 Amazon CloudWatch Alarms 未处理的规则百分比。	并没有规定在SLA中[7]
百度云TSDB[8]	✅	当用户所有试图与指定的TSDB实例建立连接的连续尝试均失败，且状态持续超过5分钟以上，则视为该分钟内该TSDB实例服务不可用。在一个服务周期内TSDB实例不可用分钟数之和即服务不可用分钟数
腾讯云数据库[9]	99.95%	当某一分钟内，客户所有试图与指定的云数据库实例建立连接或者读写请求连续尝试均失败，且该状态持续1分钟以上，则视为该分钟内该云数据库实例服务不可用。
GaussDB NoSQL （GaussDB NoSQL）[10]	✅	指依照云数据库GaussDB NoSQL系统中日志记录，因华为云原因导致云数据库GaussDB NoSQL实例连续超过五分钟无法访问的情形，不超过五分钟的不可用时间不计算在内。
influxdb cloud 2.0[11]	✅	通过 InfluxDB API 发起的任何读取、写入、任务或管理操作，"不可用"表示在一分钟间隔内对服务的所有连续请求均失败并返回 5xx 错误代码。"不可用"具有相应的含义
influxdb cloud 3.0[12]	✅	通过 InfluxDB API 发起的任何读取、写入、任务或管理操作，不可用"是指在一分钟间隔内对服务的所有连续请求均失败并返回 5xx 错误代码
Amazon Timestream[13]	99.99%	"不可用"和"不可用"是指所有时间流请求在 5 分钟间隔内响应错误。"错误"是指返回 500 或 503 错误代码的任何请求

运营SLI指定

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

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

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

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

但是时序系统并不一样：

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

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

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

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

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

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

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

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

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

总结

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

参考：