1953700 叶婧鑫 第二周任务 - XLab-Tongji/2021-WorkloadSimulation GitHub Wiki
WESSBAS:提取用于负载测试和性能预测的概率工作负载规范——基于会话的应用程序系统的模型驱动方法
-
挑战：定义尽可能准确地代表实际工作负载的工作负载规范
-
**WESSBAS：**用于基于会话的应用系统的负载测试和基于模型的性能预测提出一种自动提取和转换工作负载规范的方法。
-
三个主要组件：
- 系统和工具无关的领域特定语言(DSL)允许对基于会话的系统的工作负载规范进行分层建模。
- 从生产系统记录的会话日志自动提取该DSL的实例。
- 将实例转换为负载生成工具和基于模型的性能评估工具的可执行工作负载规范。
-
准确性依据：
-
作负载特定的特征(例如，会话长度和到达率)
-
性能特征(例如，响应时间和CPU利用率)
-
-
两种评估方法：
- 负载测试：工作负载规范作为负载测试的输
- 基于模型的性能评估方法
-
**关键需求：**确保这些规范与实际工作负载相比具有代表性。
-
**瓶颈：**缺乏支持通用的自动提取和工作负载规范的方法，对于每种方法和工具，工作负载的提取和规范是分别完成的（原因：方法不是集成的，工作负载规范是根据不同的细节级别定义的）
-
**WESSBAS：**用于指定和提取基于会话的应用程序系统的代表性工作负载。（对于验证性能模型也很有用）
-
**WESSBAS-DSL的(DSL)：**支持对工作负载规范进行系统和工具无关的建模。
-
过程：记录的会话日志被用作自动提取WESSBAS-DSL实例的基础。在创建这些实例的过程中，将标识显示相似导航模式的不同客户组。请求执行过程中的请求间依赖关系（请求的执行通常依赖于先前请求的结果）(守卫和动作(GaAs))也会被自动学习。最后，集成了生成可执行负载测试所需的协议信息
-
共享一个公共工作负载模型：
从生产系统中提取工作负载并将其转换为性能模型的负载测试和工作负载规范
- 减少了创建和指定负载测试和性能模型的工作量。
- 支持软件开发和操作(DevOps)的集成。
此篇论文还将讲述：
- 用于建模基于会话的概率工作负载规范的DSL。
- 从记录的系统日志中自动提取DSL实例，包括导航模式的集群。
- 从DSL实例到可执行的JMeter测试计划和Palladio组件模型(PCM)的工作负载规范的转换。
- 此方法的工具支持。
使网格服务发送和接收的所有流量（数据平面流量）通过 Envoy 进行代理，从而可以轻松地引导和控制网格周围的流量，而无需对您的服务进行任何更改。
图书信息应用可实现功能： Istio 的流量路由、故障注入、速率限制等
Bookinfo 与虚拟机
-
Traffic Management
- 请求路由：将动态请求路由配置到微服务的多个版本。
- 故障注入：注入故障以测试应用程序的弹性。
- 交通转移：将流量从服务的旧版本迁移到新版本。
- TCP流量转移：将 TCP 流量从 TCP 服务的旧版本迁移到新版本。
- 请求超时： 在 Envoy 中设置请求超时。
- 断路：为连接、请求和异常值检测配置断路。
- 镜像：Istio 的流量镜像/阴影功能。
- 局部负载平衡：在 Istio 中配置本地负载均衡。
- 入口：控制 Istio 服务网格的入口流量。
- 出口：控制 Istio 服务网格的出口流量。
-
Security
- 证书管理：在 Istio 中管理证书。
- 验证：控制网格服务的双向 TLS 和最终用户身份验证。
- 授权：展示如何控制对 Istio 服务的访问。
-
Policy Enforcement
- 使用 Envoy 启用速率限制：动态限制服务的流量。
-
Observability
-
指标：演示了 Istio 中指标的收集和查询。
-
日志： Istio 中的日志收集。
-
分布式追踪：收集跟踪跨度。
-
可视化网络：在 Istio 网格中可视化我们的服务。
-
远程访问：对 Istio 遥测插件集的外部访问。
-
Prometheus 是一个监控平台，它通过抓取监控目标上的指标 HTTP 端点来从这些目标收集指标。
Prometheus将所有数据存储为时间序列——属于同一指标和同一组标记维度的时间戳值流。除了存储的时间序列，Prometheus 可能会生成临时派生的时间序列作为查询的结果。
-
Metric names and labels
- 每个时间序列都由Metric names和labels 的可选键值对唯一标识。
- **Metric names：**指定了测得的系统的一般特征，可包含 ASCII 字母和数字，以及下划线和冒号。它必须匹配正则表达式
[a-zA-Z_:][a-zA-Z0-9_:]*。 -
labels：启用 Prometheus 的维度数据模型，更改任何标签值，包括添加或删除标签，都会创建一个新的时间序列。标签名称可以包含 ASCII 字母、数字和下划线。它们必须匹配正则表达式
[a-zA-Z_][a-zA-Z0-9_]*。
-
Samples
- 样本构成了实际的时间序列数据。
- 每个样本包括：一个 float 64 值+毫秒精度的时间戳
-
Notation：
<metric name>{<label name>=<label value>, ...}
-
**counter：**一个累积指标单调递增计数器，计数器的值只能在重新启动增加或归零。（可以使用计数器来表示服务的请求数、完成的任务数或错误数）
-
**Gauge:**通常用于测量值(如温度或当前内存使用情况)，也用于可以上下浮动的“计数”(如并发请求的数量)
-
**Histogram:**样本观测（如请求持续时间或响应大小）和计数它们配置的桶中，还提供所有观测值的总和。
- 观察桶的累积计数器：
<basename>_bucket{le="<upper inclusive bound>"} - 所有观察值的总和：
<basename>_sum - 已观察到的事件的计数：
<basename>_count=<basename>_bucket{le="+Inf"}
- 观察桶的累积计数器：
-
**Summary:**与histogram类似，样本观察（请求持续时间和响应大小之类的东西）。提供观察的总数和所有观察值的总和并且计算滑动时间窗口内的可配置分位数。
-
观察事件的流式φ-分位数(0 ≤ φ ≤ 1)：
<basename>{quantile="<φ>"} -
所有观察值的总和：
<basename>_sum -
已观察到的事件的计数：
<basename>_count
-
-
instance: 可以抓取的端点（通常对应于单个进程）
-
**job:**具有相同目的instances的集合
举例：
job:
api-server- instance 1:
1.2.3.4:5670 - instance 2:
1.2.3.4:5671 - instance 3:
5.6.7.8:5670 - instance 4:
5.6.7.8:5671
- instance 1:
-
自动生成的标签和时间序列
-
job：目标所属的配置作业名称。 -
instance：<host>:<port>// 目标 URL 中被抓取的部分。 -
up{job="<job-name>", instance="<instance-id>"}:1//1可达，0失败 -
scrape_duration_seconds{job="<job-name>", instance="<instance-id>"}//抓取持续时间 -
scrape_samples_post_metric_relabeling{job="<job-name>", instance="<instance-id>"}//标记后剩余样本数 -
scrape_samples_scraped{job="<job-name>", instance="<instance-id>"}//目标暴露样本数 -
scrape_series_added{job="<job-name>", instance="<instance-id>"}//抓取新系列的大致数据
-
-
metric
-
必须符合有效字符的数据模型（详见数据模型）。
-
应该有一个与度量所属的域相关的应用程序前缀（前缀通常是应用程序名称本身）
-
**prometheus**_notifications_total（特定于 Prometheus 服务器） -
**process**_cpu_seconds_total（由许多客户端库导出） -
**http**_request_duration_seconds（对于所有 HTTP 请求）
-
-
必须有一个单位并使用基本单位。
基本单位如下表
Family Base unit Remark Time seconds Temperature celsius celsius is preferred over kelvin for practical reasons. kelvin is acceptable as a base unit in special cases like color temperature or where temperature has to be absolute. Length meters Bytes bytes Bits bytes To avoid confusion combining different metrics, always use bytes, even where bits appear more common. Percent ratio Values are 0–1 (rather than 0–100). ratiois only used as a suffix for names likedisk_usage_ratio. The usual metric name follows the patternA_per_B.Voltage volts Electric current amperes Energy joules Power Prefer exporting a counter of joules, then rate(joules[5m])gives you power in Watts.Mass grams grams is preferred over kilograms to avoid issues with the kilo prefix. -
有一个后缀描述单位，复数形式。
http_request_duration_**seconds**node_memory_usage_**bytes**-
http_requests_**total**（对于无单位累计计数） -
process_cpu_**seconds_total**（对于带单位的累计计数） -
foobar_build**_info**（对于提供有关正在运行的二进制文件的元数据的伪度量）
-
代表在所有标签维度上测量的相同逻辑事物。
-
请求持续时间
-
数据传输字节
-
瞬时资源使用百分比
-
-
-
**label **
使用标签来区分被测量事物的特,不能将标签名称放在metric名称中，因为这会引入冗余，并且如果将各个标签聚合在一起会导致混淆。
-
api_http_requests_total- 区分请求类型：operation="create|update|delete" -
api_request_duration_seconds- 区分请求阶段：stage="extract|transform|load"
-
- 控制台上的图形不超过 5 个。
- 每个图形上的图（线）不超过 5 个。如果它是堆叠/面积图，您可以摆脱更多。
- 使用提供的控制台模板示例时，请避免右侧表格中的条目超过 20-30 个。
-
尽量减少警报。
-
在线服务系统：通常警告堆栈中有尽可能高的高延迟和错误率。
-
对于离线处理系统，关键指标是数据通过系统需要多长时间。
-
批处理作业，如果批处理作业最近没有足够成功需要分页。
-
接近容量通常需要人工干预以避免在不久的将来发生中断。
-
通用的
level:metric:operations。-
level表示规则输出的聚合级别和标签。 -
metric是指标名称，除了_total在使用rate()or时剥离计数器外，应保持不变irate()。 -
operations是应用于指标的操作列表，最新的操作最先。
-
-
_sum如果有其他操作则省略. -
关联操作可以合并（
min_min→min) -
没有明显的操作可以使用使用
sum -
聚集起来
_count和_sum，后缀使用rate。 -
使用的
without表示正在聚合的标签。
-
一种中介服务，可以从无法抓取的job中传送metrics。
-
用于捕获服务级别批处理作业的结果效果较好。
- 每个远程写入目标启动一个队列，该队列从预写日志中读取，将样本写入分片拥有的内存队列，然后向配置的端点发送请求。
- 使用远程写入会增加 Prometheus 的内存占用。
- 所有相关参数都可以在
queue_config远程写入配置部分下找到。- capacity
- max_shards：最大分片数或并行度,Prometheus 将用于每个远程写入队列。
- min_shards：最小分片数，是远程写入开始时使用的分片数
- max_samples_per_send：每次发送的最大样本数，可以根据使用的后端进行调整。
- batch_send_deadline：批量发送截止时间设置单个分片发送之间的最长时间。
- min_backoff ：控制重试失败请求之前等待的最短时间。当远程端点重新联机时，增加退避会分散请求。对于每个失败的请求，退避间隔加倍
max_backoff。 - max_backoff：控制重试失败请求之前等待的最长时间。