2023-7-12
今日已办
SLI学习
选择SLI
- 直接衡量服务的指标来接近客户的幸福感，从客户的角度考虑服务的可靠性，量化数据来估算用户的总体快乐或不快乐程度
- 一个好的SLI是与客户幸福感有可预测关系的SLI
- SLI应该旨在回答这个问题，服务是否按照用户的期望工作？
- SLI 应表示为两个数字的比率，即良好事件除以有效事件
- 在相当长的时间窗口内聚合SLI，以消除噪声，维持一定的稳定性
- 系统指标（如负载平均值、CPU 利用率、内存使用情况或带宽）通常以图形形式显示在监视仪表板上
测量SLI
- 处理服务器端请求日志，内置逻辑处理，不利于促发紧急响应，如请求延迟、未到达系统或没离开
- 前端负载平衡基础结构，云提供商，无状态的，因此无法跟踪会话，并且它们无法深入了解响应数据
- 使用合成客户端，模拟交互，验证响应，只是近似值
- 开发客户端代理并将指标从客户端应用程序导出到我们的系统，复杂成本大
常见的SLI
| 方面 | 指标 |
|---|---|
| 性能 | 响应时间(latency) 吞吐量(throughput) 请求量(qps) 实效性(freshness) |
| 可用性 | 运行时间(uptime) 故障时间/频率 |
| 质量 | 准确性(accuracy) 正确性(correctness) 完整性(completeness) 覆盖率(coverage) 相关性(relevance) |
| 内部指标 | 队列长度(queue length) 内存占用(RAM usage) CPU占用(CPU usage) |
| 因素人 | 响应时间(time to response) 修复时间(time to fix) 修复率(fraction fixed) |
| 可靠性 | 错误率 |
-
时延是站在某个掐表计时的实体的角度，不同角度（或不同实体），得到的时间不同，即使是对于同一个动作
-
Throughtput也需要用统计概率来描述，幸运的是，我们用一段很长的时间，比如秒，来描述Throughput，所以，从统计角度，它一般是个稳定值。（记住：在计算机世界里，1秒是个相当长的时间）
-
对于并发，我们不能通过Latency简单换算成Throughput
SLI修改
SLI修改意见
- 吞吐量和吞吐率包含一起，不用重复
- 吞吐量、时延（性能）+ 错误率（可靠性）+ 正常运行比例（可用性）
常见的SLI
| SLI指标 | 描述 | 获取方法 | 例子 |
|---|---|---|---|
| 服务可用性（Service Availability） | 系统可用的时间占总时间的比例，通常用于衡量应用程序的可靠性和可用性 | 通过监控工具收集某个服务的可用性数据，计算可用时间占总时间的比例 | 某个服务一周内可用的时间占总时间的比例 |
| 处理时间（Latency） | 完成某项操作所需的时间，通常用于衡量应用程序的性能和效率。 | 通过监控工具收集应用程序的请求和响应时间数据，计算完成操作所需的时间 | 从发送请求到接收到响应的时间。 |
| 吞吐量（Throughput） | 单位时间内完成的操作数量，通常用于衡量应用程序的性能和效率 | 通过监控工具收集应用程序的请求数据，计算单位时间内完成的操作数量 | 每秒钟能够处理的请求数量。 |
| 错误率（Error Rate） | 处理请求时发生错误的比例，通常用于衡量应用程序的错误率。 | 通过监控工具收集应用程序的错误请求数据，计算错误请求占总请求数的比例。 | 某个API的错误请求占总请求数的比例 |
| 错误码率（Error Code Rate） | 返回错误码的比例，通常用于衡量应用程序的错误率 | 通过监控工具收集应用程序的错误码数据，计算返回错误码占总请求数的比例 | 某个API返回错误码占总请求数的比例 |
| 容量利用率（Capacity Utilization） | 使用的资源占总资源的比例，通常用于衡量应用程序的资源利用率 | 通过监控工具收集应用程序的资源利用率数据，计算资源使用率占总资源的比例。 | 某个服务器的CPU使用率。 |
| 网络延迟（Network Latency） | 数据在网络中传输的时间，通常用于衡量应用程序与网络交互的效率和性能 | 通过监控工具收集应用程序与网络交互的时间数据，计算数据在网络中传输的时间。 | 从发送数据到接收到响应数据的时间。 |
| 正确性（Correctness） | 数据的正确性是指数据与实际情况的符合程度。一个数据集中的数据越准确，就越能够反映出实际场景中的情况 | 通过比对应用程序的数据查询结果和实际情况来判断数据的正确性 | 某个应用程序的数据查询结果中的数据是否与实际情况相符 |
| 完整性（Completeness） | 数据的完整性是指数据集是否包含了全部需要的数据。一个数据集越完整，就越能够反映出实际场景中的情况 | 通过比对应用程序的数据集和实际情况来判断数据的完整性。 | 某个应用程序的数据集是否包含了所有需要的数据 |
修改的SLI
| SLI指标 | 描述 | 获取方法 |
|---|---|---|
| 4个阶段【解包、初始化性能事件、解析事件、写回kafka】的错误率（Error Rate） | 执行操作时发生错误的比例 | 收集执行过程发生的错误，计算错误次数占总操作次数的比例 |
| 4个阶段【解包、初始化性能事件、解析事件、写回kafka】的时延（Latency） | 完成操作所需的时间 | 计算完成操作所需的时间，取平均值 |
| 4个阶段【解包、初始化性能事件、解析事件、写回kafka】的吞吐量（Throughput） | 单位时间内完成的操作数量 | 收集特定时间范围的完成操作的次数 |
| 完整分析、处理数据操作的错误率（Error Rate） | 处理数据时发生错误的比例 | 收集处理过程发生的错误，计算错误次数占总操作次数的比例 |
| 完整分析、处理数据操作的时延（Latency） | 完成处理数据所需的时间 | 计算完成操作所需的时间，取平均值 |
| 完整分析、处理数据操作的吞吐量（Throughput） | 单位时间内完成的操作数量 | 收集特定时间范围的完成操作的次数 |
| 服务可用性（Availability） | 系统可用的时间占总时间的比例 | 在特定的时间范围内，收集宕机时间，计算可用时间占总时间的比例 |
| 系统CPU利用率（CPU Utilization) | 使用的CPU资源占总资源的比例 | 收集服务在每个时间节点的CPU利用率 |
| 系统内存利用率（Memory Utilization) | 使用的内存资源占总资源的比例 | 收集服务在每个时间节点的内存利用率 |
| 上报数据到OTEL-Collector的错误率（Error Rate） | 返回错误码的比例 | 收集上报响应的错误码数据，计算返回错误码占总请求数的比例 |
| 上报数据到OTEL-Collector的耗时（Latency） | 完成上报操作所需的时间 | 计算请求到接收到响应所需的时间，取平均值 |
| 上报数据到OTEL-Collector的吞吐量（Throughput） | 单位时间内完成的操作数量 | 收集特定时间范围的完成操作的次数 |
明日待办
- 组内会议讨论完善SLI设计、SDK和Collector的学习实践情况
- 分工Collector、提交SLI设计
扫一扫
194
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
