1952108 李凯胤第二周任务 - XLab-Tongji/2021-WorkloadSimulation GitHub Wiki

1. Prometheus

1.1 Prometheus简介

Prometheus是一个开源的监控报警系统，它最初由SoundCloud开发。

2016年，Prometheus被纳入了由谷歌发起的Linux基金会旗下的云原生基金会（ Cloud Native Computing Foundation），并成为仅次于Kubernetes的第二大开源项目。自此，它成为了一个独立的开源项目，独立于任何公司进行维护。

Prometheus拥有非常活跃的开发人员和用户社区，目前在GitHub上已拥有三万多的Star。

1.2 Prometheus特点

提供多维度数据模型，使用指标名称和键值对标识的时间序列数据提供灵活的PromQL查询方式，还提供了HTTP查询接口，可以很方便地结合Grafana等组件展示数据。不依赖外部存储，支持单节点的本地存储。通过Prometheus自带的时序数据库，可以完成每秒百万及的数据存储，如果需要存储大量历史数据，还可以对接第三方的时序数据库。时间序列收集通过HTTP的拉取方式进行，并提供了开放的指标数据标准。支持向中间网关推送时序数据，可以更加灵活地适用于多种监控场景。支持通过动态服务发现和静态文件配置获取监控对象，目前已支持Kubernetes、Etcd、Consul等多种服务发现机制。支持多种模式的图形展示和仪表盘。大多数Prometheus的组件都是使用Go语言编写的，这使得它们很容易以二进制文件的形式构建和部署。

1.3 Prometheus架构

Prometheus生态圈由多个组件构成，其中许多组件是可选的：

Prometheus Server：用于收集、存储和查询时间序列数据。通过静态配置文件管理监控目标，也可以配合使用动态服务发现的方式动态管理监控目标，并从这些监控目标中获取数据。它将采集到的数据按照时间序列的方式存储在本地磁盘当中或者外部的时序数据库中，可通过PromQL语言对数据的查询以及分析。 Client Library：为被监控的应用生成相应的指标(Metric)数据并暴露给Prometheus Server。当Prometheus Server 来拉取时，直接返回实时状态的指标数据。 Push Gateway：主要用于短期存在的Jobs。由于这类Jobs存在时间较短，可能在Prometheus Server来拉取数据之前就消失了。所以，Jobs可以直接向Push Gateway推送它们的指标数据，然后Prometheus Server再从Push Gateway拉取。 Exporters：用于暴露已有的第三方服务的指标数据通过HTTP服务的形式暴露给Prometheus Server，比如HAProxy、StatsD、Graphite等等。Prometheus Server通过访问该Exporter提供的Endpoint，即可获取到需要采集的监控数据。 Alertmanager：从Prometheus Server接收到告警后，会进行去除重复数据，分组，并路由到对收的接受方式，发出报警。Alertmanager的告警方式非常灵活，支持通过邮件、slack或钉钉等多种途径发出告警。一些其他的组件。下面这张图展示了Prometheus的架构和各个组件是如何交互和协作的:

Prometheus架构图

其大概的工作流程是：

Prometheus Server直接从HTTP接口或者Push Gateway拉取指标(Metric)数据。 Prometheus Server在本地存储所有采集的指标(Metric)数据，并在这些数据上运行规则，从现有数据中聚合和记录新的时间序列，或者生成告警。 Alertmanager根据配置文件，对接收到的告警进行处理，发出报警。在Grafana或其他API客户端中，可视化收集的数据。

1.4 相关术语

1.4.1 Alert(警告)

警报是 Prometheus 中主动触发的警报规则的结果。警报从 Prometheus 发送到 Alertmanager。

1.4.2 Alertmanager(警报管理器)

该Alertmanager发生在警报，他们聚集成团，去重复，适用沉默，油门，然后发出通知email，Pagerduty，Slack等

1.4.3 Bridge(桥接器)

桥接器是从客户端库中获取样本并将其暴露给非 Prometheus 监控系统的组件。例如，Python、Go 和 Java 客户端可以将指标导出到 Graphite。

1.4.4 Client Library(客户端库)

客户端库是某种语言（例如 Go、Java、Python、Ruby）的库，它可以轻松地直接检测您的代码、编写自定义收集器以从其他系统提取指标并将指标公开给 Prometheus。

1.4.5 Collector(收集器)

收集器是表示一组指标的导出器的一部分。如果它是直接检测的一部分，如果它可能是单个指标，而如果它从另一个系统提取指标，则它可能是多个指标。

1.4.6 Direct instrumentation(直接测量)

直接检测是使用客户端库作为程序源代码的一部分内联添加的检测。

1.4.7 Endpoint(端点)

可以抓取的指标来源，通常对应于单个流程。

1.4.8 Exporter(导出器)

导出器是与您要从中获取指标的应用程序一起运行的二进制文件。导出器公开 Prometheus 指标，通常通过将以非 Prometheus 格式公开的指标转换为 Prometheus 支持的格式。

1.4.9 Instance(实例)

实例是唯一标识作业中目标的标签。

1.4.10 Job(作业)

具有相同目的的一组目标，例如监视一组为可扩展性或可靠性而复制的类似进程，称为作业。

1.4.11 Notification(通知)

通知代表一组一个或多个警报，由 Alertmanager 发送到Email、Pagerduty、Slack 等。

1.4.12 Promdash

Promdash 是 Prometheus 的原生仪表板构建器。它已被弃用并被Grafana取代。

1.4.13 Prometheus(普罗米修斯)

Prometheus 通常指的是 Prometheus 系统的核心二进制文件。它也可以指整个 Prometheus 监控系统。

1.4.14 PromQL

PromQL是 Prometheus 查询语言。它允许进行广泛的操作，包括聚合、切片和切块、预测和连接。

1.4.15 Pushgateway(中间网关)

该Pushgateway坚持从批处理作业指标的最新推。这允许 Prometheus 在它们终止后抓取它们的指标。

1.4.16 Remote Read(远程读取)

远程读取是 Prometheus 的一项功能，它允许从其他系统（例如长期存储）透明读取时间序列作为查询的一部分。

1.4.17 Remote Read Adapter(远程读取适配器)

并非所有系统都直接支持远程读取。远程读取适配器位于 Prometheus 和另一个系统之间，在它们之间转换时间序列请求和响应。

1.4.18 Remote Read Endpoint(远程读取端点)

远程读取端点是 Prometheus 在进行远程读取时与之对话的端点。

1.4.19 Remote Write(远程写入)

远程写入是 Prometheus 的一项功能，允许将摄取的样本动态发送到其他系统，例如长期存储。

1.4.20 Remote Write Adapter(远程写入适配器)

并非所有系统都直接支持远程写入。远程写入适配器位于 Prometheus 和另一个系统之间，将远程写入中的样本转换为其他系统可以理解的格式。

1.4.21 Remote Write Endpoint(远程写入端点)

远程写入端点是 Prometheus 在进行远程写入时与之对话的对象。

1.4.22 Sample(样本)

样本是时间序列中某个时间点的单个值。

在 Prometheus 中，每个样本由一个 float64 值和一个毫秒精度的时间戳组成。

1.4.23 Silence

Alertmanager 中的 silence 可阻止带有与silence匹配的标签的警报包含在通知中。

1.4.24 Target（目标）

目标是要抓取的对象的定义。例如，要应用的标签、连接所需的任何身份验证或定义抓取将如何发生的其他信息。

1.5 最佳实践

指标名称

必须符合有效字符的数据模型。
应该有一个与度量所属的域相关的（单字）应用程序前缀。对于特定于应用程序的指标，前缀通常是应用程序名称本身。然而，有时指标更通用，例如客户端库导出的标准化指标。例子：
- prometheus_notifications_total （特定于 Prometheus 服务器）
- process_cpu_seconds_total （由许多客户端库导出）
- http_request_duration_seconds （对于所有 HTTP 请求）
必须有一个单位（即不要将秒与毫秒或秒与字节混合）。
应该使用基本单位（例如秒、字节、米——而不是毫秒、兆字节、公里）。请参阅下面的基本单位列表。
该有一个后缀描述单位，复数形式。如果适用，除了单位之外，累积计数还有后缀。
应该代表在所有标签维度上测量的相同逻辑事物。
- 请求持续时间
- 数据传输字节
- 瞬时资源使用百分比

根据经验，给定指标的所有维度sum()或avg()所有维度都应该是有意义的（尽管不一定有用）。如果没有意义，请将数据拆分为多个指标。例如，在一个指标中包含各种队列的容量是好的，而将队列的容量与队列中的当前元素数量混合则不好。出于监控目的，服务通常可以分为三种类型：在线服务、离线处理和批处理作业。它们之间存在重叠，但每项服务都倾向于非常适合这些类别之一。

Prometheus 采集中常见的服务分三种：

在线服务：如 Web 服务、数据库等，一般关心请求速率，延迟和错误率即 RED 方法。

离线服务：如日志处理、消息队列等，一般关注队列数量、进行中的数量，处理速度以及发生的错误即 Use 方法。

批处理任务：和离线任务很像，但是离线任务是长期运行的，批处理任务是按计划运行的，如持续集成就是批处理任务，对应 K8S 中的 job 或 cronjob，一般关注所花的时间、错误数等，因为运行周期短，很可能还没采集到就运行结束了，所以一般使用 Pushgateway，改拉为推。

作为一般规则，对于每一行日志代码，有一个递增的计数器。如果您发现一条有趣的日志消息，您希望能够看到它发生的频率和持续时间。如果同一函数中有多个密切相关的日志消息（例如，if 或 switch 语句的不同分支），有时为所有这些消息增加一个计数器是有意义的。导出应用程序作为一个整体记录的信息/错误/警告行的总数，并在发布过程中检查显着差异通常也很有用。

要注意使用标签，而且不要过度使用标签

控制台和仪表板

以下指南非常有效：

控制台上的图形不超过 5 个。
每个图形上的图（线）不超过 5 个。如果它是堆叠/面积图，您可以摆脱更多。
使用提供的控制台模板示例时，请避免右侧表格中的条目超过 20-30 个。

警报

保持简单的警报，对症状发出警报，拥有良好的控制台以允许查明原因，并避免出现无事可做的页面。警报应该链接到相关的控制台，并可以很容易地找出哪个组件有问题。

在线服务系统通常警告堆栈中尽可能高的高延迟和错误率。对于离线处理系统，关键指标是数据通过系统需要多长时间，因此页面是否足够高以导致用户影响。对于批处理作业，如果批处理作业最近没有足够成功，则分页是有意义的，这将导致用户可见的问题。

容量虽然不是直接对用户造成影响的问题，但接近容量通常需要人工干预以避免在不久的将来发生中断。

记录规则

记录规则的一致命名方案可以更容易地一目了然地解释规则的含义。它还通过突出不正确或无意义的计算来避免错误。记录规则应该是通用的level:metric:operations。 level表示规则输出的聚合级别和标签。 metric是指标名称，除了_total在使用rate()or时剥离计数器外，应保持不变 irate()。operations是应用于指标的操作列表，最新的操作最先。

2. istio 服务网格

2.1 什么是istio

云平台为使用它们的组织提供了丰富的好处。然而，不可否认的是，采用云技术会给devops团队带来压力。开发人员必须使用微服务来设计可移植性，同时运营商正在管理非常大的混合和多云部署。istio允许您连接、保护、控制和观察服务。

在高层次上，ISTIO有助于减少这些部署的复杂性，并减轻开发团队的压力。它是一个完全透明的开源服务网格，透明地覆盖现有的分布式应用程序。它也是一个平台，包括允许它集成到任何日志平台、遥测或策略系统中的api。istio的多种功能集使您能够成功、高效地运行分布式微服务体系结构，并提供一种统一的方式来保护、连接和监视微服务。

2.2 什么是服务网格

ISTIO解决了开发人员和运营商在单片应用程序向分布式微服务架构过渡时面临的挑战。要了解如何实现，可以更详细地查看istio的服务网格。

服务网格用于描述组成此类应用程序的微服务网络以及它们之间的交互。随着服务网格的规模和复杂性的增长，它变得越来越难以理解和管理。它的需求可以包括发现、负载平衡、故障恢复、度量和监视。服务网格通常还具有更复杂的操作需求，如a/b测试、金丝雀部署、速率限制、访问控制和端到端身份验证。

ISTIO提供了对整个服务网格的行为洞察力和操作控制，提供了一个完整的解决方案来满足微服务应用程序的各种需求。

2.3 为什么要使用istio

ISTIO使创建一个包含负载平衡、服务到服务身份验证、监视等功能的已部署服务的网络变得非常容易，而服务代码中很少或根本没有代码更改。通过在整个环境中部署一个特殊的sidecar代理来为服务添加istio支持，该代理拦截微服务之间的所有网络通信，然后使用其控制平面功能配置和管理istio，包括：

HTTP、GRPC、WebSocket和TCP流量的自动负载平衡。通过丰富的路由规则、重试、故障转移和故障注入对流量行为进行细粒度控制。支持访问控制、速率限制和配额的可插入策略层和配置api。集群内所有流量的自动度量、日志和跟踪，包括集群入口和出口。使用基于身份的强身份验证和授权来保护群集中的服务到服务通信。istio是为可扩展性而设计的，可以满足不同的部署需求。

2.4 核心功能

ISTIO在服务网络中统一提供了许多关键功能：

2.4.1.流量管理

istio的简单规则配置和流量路由允许您控制服务之间的流量和api调用。ISTIO简化了诸如断路器、超时和重试等服务级别属性的配置，并使设置重要任务（如A/B测试、金丝雀卷展和具有基于百分比的流量分割的分阶段卷展）变得轻而易举。

有了更好的流量可见性和开箱即用的故障恢复功能，可以在问题产生之前发现问题，使呼叫更可靠，网络更健壮，无论面临什么情况。

2.4.2 安全

ISTIO的安全功能使开发人员可以在应用程序级别上专注于安全性。ISTIO提供了底层的安全通信通道，并按比例管理服务通信的身份验证、授权和加密。使用istio，服务通信在默认情况下是安全的，允许您在不同的协议和运行时一致地执行策略—所有这些都很少或根本没有应用程序更改。

虽然istio是独立于平台的，与kubernetes（或基础设施）网络策略一起使用，但它的好处更大，包括在网络和应用层保护pod到pod或服务到服务通信的能力。

2.4.3 可观察性

istio强大的跟踪、监视和日志记录功能让您深入了解服务网格部署。通过ISTIO的监视功能，您可以真正了解服务性能如何影响上游和下游的情况，而其自定义的仪表板提供了对所有服务性能的可见性，并让您了解该性能如何影响其他流程。

ISTIO的mixer组件负责策略控制和遥测收集。它提供了后端抽象和中介，将istio的其余部分与单个基础架构后端的实现细节隔离开来，并为操作员提供了对网格和基础架构后端之间的所有交互的细粒度控制。

所有这些特性使您能够更有效地设置、监视和强制服务上的slo。当然，底线是您可以快速有效地检测和修复问题。

2.4.4 平台支持性

ISTIO是独立于平台的，设计用于在各种环境中运行，包括跨越云、内部部署、Kubernetes、Mesos等环境。你可以把istio部署在 Kubernetes, Nomad with Consul 。ISTIO目前支持：

Kubernetes上的服务部署 Consul注册服务在单个vm上运行与k8s 的结合

2.5 集成与定制

ISTIO的策略执行组件可以被扩展和定制，以与ACL、日志记录、监视、配额、审计以及更多的现有解决方案集成。

2.5.1 istio的架构

istio服务网格在逻辑上分为数据平面和控制平面。

数据平面由一组部署为sidecar智能代理（特使）组成。这些代理中介和控制微服务与Mixer、通用策略和遥测集线器之间的所有网络通信。

控制平面管理和配置代理以路由业务。此外，控制平面配置Mixer以强制执行策略和收集遥测。

下图显示了构成每个平面的不同组件：

2.5.2 Envoy

istio使用的是Envoy代理的扩展版本。特使是C++开发的高性能代理，用于服务网格中所有服务的所有入站和出站通信。ISTIO利用了特使的许多内置功能。

Envoy是作为一个sidecar部署到相关服务在K8S的pod里。此部署允许istio将大量关于流量行为的信号提取为属性。反过来，istio可以在mixer中使用这些属性来强制执行策略决策，并将它们发送到监视系统，以提供有关整个网格行为的信息。

SIDECAR代理模型还允许您将ISTIO能力添加到现有的部署中，而不需要重新构建或重写代码。

2.5.3 Mixer

Mixer是独立于平台的组件。mixer在服务网格中实施访问控制和使用策略，并从特使代理和其他服务收集遥测数据。代理提取请求级属性，并将其发送到mixer进行评估。您可以在我们的混音器配置文档中找到有关此属性提取和策略评估的更多信息。

Mixer包括一个灵活的插件模型。此模型使istio能够与各种主机环境和基础架构后端进行接口。因此，istio从这些细节中抽象出了特使代理和istio管理的服务。

2.5.4 Pilot

Pilot为sidecar提供服务发现、智能路由的流量管理功能（如A/B测试、金丝雀推出等）和弹性（超时、重试、断路器等）。

pilot将控制流量行为的高级路由规则转换为特定于envoy的配置，并在运行时将它们传播到sidecars。Pilot抽象了特定于平台的服务发现机制，并将其合成为任何符合特使数据平面API的Sidecar都可以使用的标准格式。这种松耦合允许istio在多个环境（如kubernetes、consul或nomad）上运行，同时为流量管理维护相同的操作员界面。

2.5.5 Citadel

citadel通过内置的身份和凭据管理实现了强服务到服务和最终用户身份验证。您可以使用Citadel升级服务网格中的未加密流量。使用citadel，运营商可以基于服务标识而不是相对不稳定的第3层或第4层网络标识来实施策略。从0.5版开始，您可以使用istio的授权功能来控制谁可以访问您的服务。

2.5.6 Galley

Galley是ISTIO的配置验证、摄取、处理和分发组件。它负责将其余的istio组件与从底层平台（例如k8S）获取用户配置的细节隔离开来。

2.6 ISTIO的设计目的

一些关键的设计目标告知了istio的架构。这些目标对于使系统能够处理大规模和高性能的服务至关重要。

最大化透明度：采用ISTIO，操作员或开发人员需要尽可能少的工作量来获得来自系统的实际价值。为此，istio可以自动将自己注入到服务之间的所有网络路径中。ISTIO使用SIDACAR代理来捕获流量，并且在可能的情况下，自动编程网络层以通过这些代理路由流量，而不必对部署的应用程序代码进行任何更改。

可扩展性：随着运营商和开发人员越来越依赖istio提供的功能，系统必须随着他们的需求而增长。在我们继续添加新特性的同时，最大的需求是能够扩展策略系统，与其他策略和控制源集成，并将网格行为的信号传播到其他系统进行分析。策略运行时支持插入其他服务的标准扩展机制。此外，它允许扩展其词汇表，以允许基于网格生成的新信号实施策略。

可移植性：使用istio的生态系统在许多方面都不同。ISTIO必须在任何云端或本地环境中运行，只需最少的努力。将基于istio的服务移植到新环境的任务必须很简单。使用istio，您可以操作部署到多个环境中的单个服务。例如，可以在多个云上部署以实现冗余。

策略一致性：将策略应用于服务之间的api调用，可以提供对网格行为的大量控制。但是，将策略应用于不一定在api级别表示的资源也同样重要。例如，将配额应用于ml训练任务消耗的cpu量比将配额应用于启动工作的调用更有用。为此，istio使用自己的api将策略系统维护为一个独立的服务，而不是将策略系统烘焙到代理sidecar中，允许服务根据需要直接与之集成。

3.WESSBAS Abstract & Introduction

3.1 title

WESSBAS：提取用于负载测试和性能预测的概率工作负载规范（一种基于会话的应用程序系统的模型驱动方法）

3.2 abstract

为了使用负载测试和基于模型的性能预测来评估应用系统的性能特征，需要工作负载规范。本文提出了一种方法(WESSBAS)，旨在自动提取和转换工作负载规范。方法步骤：

首先，与系统和工具无关的领域特定语言 (DSL) 允许对基于会话的系统的工作负载规范进行分层建模。
第二，该 DSL 的实例是从生产系统的记录会话日志中自动提取的。
第三，将这些实例转化为负载生成工具和基于模型的性能评估工具的可执行工作负载规范。

通过使用负载测试工具Apache JMeter和Palladio组件模型，使用行业标准基准 SPECjEnterprise2010 和 1998 年世界杯访问日志进行评估后发现：

特定于工作负载的特征（例如，会话长度和到达率）和性能特征（例如，响应时间和 CPU 利用率）表明提取的工作负载与测量的工作负载高度匹配。

3.3 Introduction

工作负载的规范和执行对于评估应用系统的性能属性至关重要。为了评估是否可以满足这些系统的非功能性性能要求，应用了负载测试和基于模型的性能评估方法。

在基于会话的应用系统中，尤其是基于 Web 的系统中，不同类型的用户以一系列相互依赖的请求与系统交互。这些交互的复杂性使工作负载规范成为一项艰巨的任务。因此，手动创建这些工作负载规范非常耗时且容易出错。主要挑战之一是确保这些规范与实际工作负载相比具有代表性。然而，工作负载的提取和规范是针对每种方法和每种工具单独完成的，这会导致额外的规范和维护工作。原因是这些方法没有集成，并且工作负载规范是在不同的详细级别上定义的。

为了应对这些挑战，本文介绍了 WESSBAS为基于会话的应用系统指定和提取代表性工作负载的方法。引入了一种称为 WESSBAS-DSL 的 (DSL)，它支持对这些工作负载规范进行系统和工具无关的建模。记录的会话日志用作自动提取 WESSBAS-DSL 实例的基础。在创建这些实例的过程中识别出显示类似导航模式的不同客户组。此外，自动学习请求执行之间的请求间依赖关系（Guards 和 Actions (GaAs)）。这些依赖来自这样一个事实，即请求的执行通常取决于先前请求的结果。概率和 GaAs 的组合需要计算条件概率，这些概率也是自动确定的。最后,生成可执行负载测试所需的协议信息。

例如，将生成的 WESSBAS-DSL 实例转换为通用负载测试工具 Apache JMeter 的可执行工作负载规范，包括在之前的工作中开发的 Markov4JMeter 扩展。此外，DSL 实例被转换为代表架构级性能建模语言的 Palladio 组件模型的工作负载规范。我们专注于架构级性能模型，因为它们允许对系统架构、执行环境和工作负载规范进行单独建模。

在系统生命周期中，共享一个通用工作负载模型对这两种方法都有几个关键的好处。例如，在开发期间，系统规范（例如，统一建模语言 (UML) 图）或来自专家访谈的信息是可用的，以便推导出关于工作负载概况的估计。这些知识可以在 WESSBAS-DSL 中编码，然后转换为性能模型以进行早期性能预测。一旦应用系统运行并且应该执行负载测试，负载测试的部分（例如，用户场景和工作负载强度）可以基于WESSBAS-DSL生成。因此，两种方法只需要创建一次工作负载。

为了评估新版本的性能特征，通常在测试系统上进行负载测试。这些测试期间使用的工作负载应该与生产系统的工作负载相当。这样做的优点是可以以更高的概率发现生产系统中也出现的瓶颈。因此，从生产系统中提取工作负载并将其转换为负载测试和性能模型的工作负载规范有两个好处。

第一个好处是减少了创建和指定负载测试和性能模型的工作量。由于生产工作负载会随着时间的推移而发生变化，因此可以通过一种简单的方式再次提取最新的工作负载，以减少维护工作。
第二个好处是支持软件开发和运营（DevOps）的集成。操作期间提取的工作负载可用于基于测量的和基于模型的持续集成方法，以检测开发期间的性能回归。

WESSBAS 方法也可用于验证性能模型。为了验证性能模型的正确性，将仿真结果与从系统导出的测量结果进行比较。为了这些结果的可比性，必须确保模拟结果和测量结果是通过应用相同的工作负载规范得出的。

WESSBAS 是第一种实现从运行时数据到可执行负载测试和性能预测方法的过程的方法。是用于自动提取基于会话的应用程序系统的概率工作负载规范，包括：

用于建模基于会话的概率工作负载规范的 DSL。
从记录的系统日志中自动提取 DSL 实例，包括导航模式的聚类。
从 DSL 实例到可执行的 JMeter 测试计划以及 Palladio 组件模型 (PCM) 的工作负载规范的转换。
这种方法的工具支持。

本文建立在工作负载规范的提取和规范方面的工作的基础上，包含以下主要改进和扩展：

工具支持将任意系统日志转换为所需的会话日志格式。
GaAs 的自动学习和条件概率的计算。
生成可执行的负载测试（这包括协议信息的提取和集成）。
根据行业标准基准 SPECjEnterprise2010 和 1998 年世界杯访问日志对工作负载特征（例如，会话长度和操作计数）和性能特征（例如，响应时间和 CPU 利用率）进行综合评估。

参考文献：