哈铁工程建设公司网站,桓台做网站,安宁网站建设与制作,做网站使用明星照片可以吗本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。 本作品 (李兆龙 博文, 由 李兆龙 创作)#xff0c;由 李兆龙 确认#xff0c;转载请注明版权。 公有云时序数据库SLA 运营商产品每服务周期服务可用率不低于99.9%衡量服务不可用数据指标从采…本作品采用知识共享署名-非商业性使用-相同方式共享 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 Alarms5 分钟时间间隔内 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 ObjectiveService Level AgreementService Level Indicator之间的区别。 事实上在我看来SLO和SLA是偏向交付的概念更关心系统的整体运作水平而对于日常的运营工作我们更关注SLI的健康情况其次因为SLA与钱挂钩相对来讲厂商不会激进的设定SLA并会附加上严苛的免责条款但是对于日常运营在出现意外情况是我们仍然应该准确的获取SLI的值以此发现分析并解决问题。 KV系统模型链路均较为简单且约束明确存在时延可用性一致性约束我们可以设定如下指标作为内部人员分析问题的指标水平 失败量平均延时聚合分钟粒度最小成功率聚合分钟粒度最大P99 但是时序系统并不一样 首先写入链路复杂存在直连proxykafkaprometheus等写入方式写入请求不能用简单的写入时延成功率统计其次系统内部关心整体趋势对于零星的失败容忍性远大于KV系统只要重试成功问题就不是很大对于请求成功率本身要求并不是特别高慢查询是可预期的因为存在用户做长周期的分析需求时序的特殊性会导致扫描几乎全量数据这并不是错误的查询不能像kv一样统一分析也就是说P99指标用处不大有时与业务捆绑较深比如一个页面可能触发N次查询当多人同时点击页面时如果只是衡量系统侧每一个查询性能是片面的应该从用户的角度分析将一个session内的查询视为一个整体用session粒度去做分析这样服务降级也好做 暂且不考虑技术站在用户的角度我认为只有两点较为重要 数据产生到实际可读整体链路kafkaprometheus直连需要的时间包含错误/重试请求失败过载不care一个用户session内的查询时延 单次查询时延不care 站在开发的角度则需要更为细致的指标简单来讲如果我运营一个时序数据库系统如何能够衡量健康情况如何快速发现问题 数据产生到实际可读的时间消耗包含写入kafka延迟数据在Kafka停留时间接收到数据整体处理流程的时延包含总体失败重试时延一个用户session内查询总体时延体现在用户感受上失败量平均延时聚合分钟粒度最小成功率 聚合分钟粒度最大时延P99时间范围覆盖较小的查询请求失败量平均延时聚合分钟粒度最小成功率 聚合分钟粒度最大时延P99时间范围覆盖较大的预期慢查询所以需要感知慢查询对应的sql时间线和数据量要让慢查询预期的慢不符合预期的慢时需要分析原因 事实上这样决策的原因有这么几点 读写差异巨大读写的SLI设定应该分离而且写入偶尔的失败是可预料的频繁的告警没有意义数据库内的写可能只是链路的一部分我们希望跟踪全链路的写入指标时间范围不同的查询告警指标的设定应该不是一致的我们希望通过session做服务降级也希望更好的理解业务层面的SLI单独的查询分析不能cover这一场景 当然还有用于大盘数据展示集群整体趋势的监控数据指标这个不再细谈大体思路就是clusterpodaccountdatabaseaccountpartitionmeasurement级别的数据分析kafka本身topic/partition的待commit数生产速度消费速度等。 当然本篇文章只讨论读写CQ降采样流计算的SLI我们不讨论但是链路和指标本身也都很有考量的余地。 总结 工作已经一年多了从COS索引层到云原生多模数据库愈来愈发觉监控体系和运营手段之于一个云数据库系统的重要程度运营的能力和工具自动化也是各大厂商雄厚能力的体现当然也是工程师综合素质提升必须要过的一关不会运营永远不能有底气的说自己做过存储和DB。 参考 时序时空数据库TSDB服务等级协议金山云时序数据库InfluxDB服务等级协议天翼云时序数据库Influx版服务等级协议万字解读怎样激活 TDengine 最高性价比Lindorm Service Level AgreementAmazon CloudWatch Service Level AgreementCloudWatch Publish custom metrics时序数据库TSDB服务等级协议SLA(V2.0)腾讯云云数据库服务等级协议云数据库 GaussDB NoSQL GaussDB NoSQL服务等级协议InfluxDB Cloud 2.0 Service Level AgreementInfluxDB Cloud 3.0 Dedicated Service Level DescriptionAmazon Timestream Service Level Agreement