系统架构¶
此页面展示了 Watcher 系统的当前技术架构。
概述¶
以下是一个图表，显示了 Watcher 的主要组件
组件¶
AMQP 总线¶
AMQP 消息总线处理 Watcher 不同组件之间的内部异步通信。
数据源¶
此组件存储与集群相关的指标。
它可能依赖于任何合适的存储系统（InfluxDB、OpenTSDB、MongoDB 等），但使用 时间序列数据库 时性能可能更高，这些数据库针对处理时间序列数据进行了优化，时间序列数据是按时间（日期时间或日期时间范围）索引的数字数组。
Watcher API¶
此组件实现了 Watcher 系统向外部世界提供的 REST API。
它使 管理员 可以通过连接到此 API 的任何交互机制来控制和监控 集群 中的 Watcher 系统
Horizon 插件
Python SDK
您还可以阅读 Watcher API 的详细说明。
Watcher Applier¶
此组件负责执行由 Watcher 决策引擎 构建的 行动计划。Taskflow 是 Watcher 的默认工作流引擎。
它连接到 消息总线，并在专用 AMQP 队列上收到触发消息时启动 行动计划。
触发消息包含行动计划 UUID。
然后，它从 Watcher 数据库 获取有关 行动计划 的详细信息，该数据库包含要启动的 操作 列表。
然后，它循环遍历每个 操作，获取关联的类并调用该类的 execute() 方法。大多数情况下，此方法首先向 Keystone API 请求令牌，如果允许，则向处理此类 原子操作 的 OpenStack 服务的 REST API 发送请求。
请注意，一旦 Watcher Applier 开始处理列表中的给定 操作，就会在 消息总线 上发送一条通知消息，指示操作的状态已更改为 正在进行。
如果 操作 成功，Watcher Applier 会在 总线 上发送一条通知消息，通知其他组件。
如果 操作 失败，Watcher Applier 会尝试回滚到 受管资源 的先前状态（即在将命令发送到底层 OpenStack 服务之前）。
在 Stein 中，添加了一个新的配置选项 ‘action_execution_rule’，它是一种字典类型。其键字段是策略名称，值是 ‘ALWAYS’ 或 ‘ANY’。‘ALWAYS’ 表示回调函数像往常一样返回 True。‘ANY’ 表示返回值取决于之前的操作执行结果。如果之前的操作失败，回调返回 True，引擎继续运行下一个操作。如果之前的操作执行成功，回调返回 False，则忽略下一个操作。对于不在 ‘action_execution_rule’ 中的策略，回调始终返回 True。如果您的策略需要此功能，请在 watcher.conf 文件中添加下一节。
[watcher_workflow_engines.taskflow]
action_execution_rule = {'your strategy name': 'ANY'}
Watcher CLI¶
Watcher 命令行界面 (CLI) 可用于与 Watcher 系统交互，以控制它或了解其当前状态。
请阅读 关于 Watcher CLI 的详细文档。
Watcher Dashboard¶
Watcher Dashboard 可用于通过 Horizon 与 Watcher 系统交互，以控制它或了解其当前状态。
Watcher 数据库¶
此数据库存储所有 Watcher 领域对象，这些对象可以由 Watcher API 或 Watcher CLI 请求
Watcher 领域在这里是“优化 OpenStack 系统提供的某些资源”。
Watcher 决策引擎¶
此组件负责计算一组潜在的优化 操作，以实现 审计 的 目标。
它首先读取 审计 的参数，以了解要实现的目标。
除非另有说明，否则它会从可用策略列表中选择最合适的 策略 来实现此目标。
然后通过 stevedore 动态加载 策略。 Watcher 决策引擎 执行该策略。
以下是一个序列图，显示了决策引擎如何构建和维护策略使用的 集群数据模型。
策略的执行然后产生一个由一组 操作 以及一组 效能指标 组成的解决方案。
这些 操作 由 Watcher 规划器 安排时间（即，它生成一个 行动计划）。
数据模型¶
下图显示了 Watcher 的数据模型，特别是从参与者（管理员、客户）的角度来看对象的功能依赖关系（目标、审计、行动计划等）
以下是一个从数据库角度表示 Watcher 中的主要对象的图表
序列图¶
以下段落显示了 Watcher 用于最常用场景的不同组件之间交换的消息。
创建一个新的审计模板¶
一个名称
要实现的目标
一个可选的策略
Watcher API 确保指定的 goal（必需）及其关联的策略（可选）在将新的审计模板存储到 Watcher 数据库 之前在 Watcher 数据库 中注册。
创建并启动一个新的审计¶
管理员 可以通过提供先前创建的 审计模板 的唯一 UUID 来启动一个新的 审计
管理员 还可以指定审计类型和间隔（在 CONTINUOUS 类型的情况下）。审计有三种类型：ONESHOT、CONTINUOUS 和 EVENT。ONESHOT 审计启动一次，如果成功，将提供新的行动计划列表；CONTINUOUS 审计以指定的间隔（以秒或 cron 格式，cron 间隔可以像这样使用：*/5 * * * *）创建行动计划，如果创建了行动计划，所有以前的行动计划都将变为 CANCELLED 状态；EVENT 审计在接收到 webhook API 时启动。
一条消息被发送到 AMQP 总线，这会触发 Watcher 决策引擎 中的审计
Watcher 决策引擎 从 Watcher 数据库 读取审计参数。它实例化适当的 策略（使用入口点），同时考虑 审计 的 目标 和父 审计模板 关联的策略。如果审计模板没有关联策略，则策略由决策引擎动态选择。
Watcher 决策引擎 还构建 集群数据模型。此数据模型由 策略 需要，以了解被审计的 OpenStack 集群 的当前状态和拓扑。
“决策引擎”调用实例化“策略”的 execute() 方法，并将数据模型作为输入参数提供。此方法计算一个“解决方案”以实现目标，并将其返回给“决策引擎”。此时，动作尚未被调度。
“决策引擎”动态加载在 Watcher 中配置（通过入口点）的“规划器”实现，并使用解决方案作为输入参数调用该类的 schedule() 方法。此方法会考虑到一些调度规则（例如动作之间的优先级），找到合适的“动作”调度。它生成一个新的“行动计划”，状态为 RECOMMENDED，并将其保存到“Watcher 数据库”。保存的行动计划现在是动作的调度流程，其中与相关的“目标”关联着全局效能以及多个“效能指标”。
如果每个步骤都成功执行，“决策引擎”会将审计的当前状态更新为 SUCCEEDED，存储在“Watcher 数据库”中，并在总线上发送通知，告知其他组件“审计”已成功。
决策引擎遵循的内部工作流程来执行审计，可以在下面的序列图中看到
启动行动计划¶
一条消息被发送到“AMQP 总线”，从而触发“应用器”中的“行动计划”。
“应用器”将从“Watcher 数据库”中获取“动作”流程的描述，并为每个“动作”实例化相应的“动作”处理程序 Python 类。
validate_parameters()：此方法将确保所有提供的输入参数都有效。
如果所有参数都有效，“应用器”将继续下一步。
如果无效，则会引发错误，并且不会执行该动作。会向总线发送通知，告知其他组件失败情况。
preconditions()：此方法将确保在执行动作之前满足所有条件（例如，它确保在尝试迁移实例之前实例仍然存在）。如果在此阶段未满足动作特定的先决条件，则该动作的状态设置为 SKIPPED，并且不会执行。
execute()：此方法触发对其他 OpenStack 服务（例如 Nova 等）的实际命令，以更改目标资源状态。如果动作成功执行，则会向总线发送通知消息，指示该动作的新状态为 SUCCEEDED。
如果行动流程中的每个动作都已成功执行，则会向总线发送通知，指示整个“行动计划”已 SUCCEEDED。
状态机图¶
审计状态机¶
“审计”具有生命周期，其当前状态可能是以下之一
SUCCEEDED：“审计”已成功执行，并且找到至少一个解决方案。
FAILED：在执行“审计”时发生错误。
DELETED：“审计”仍然存储在“Watcher 数据库”中，但不再通过 Watcher API 返回。
下图显示了“审计”的不同可能状态以及使状态更改为新值的事件
行动计划状态机¶
“行动计划”具有生命周期，其当前状态可能是以下之一
FAILED：在执行“行动计划”时发生错误。
DELETED：“行动计划”仍然存储在“Watcher 数据库”中，但不再通过 Watcher API 返回。
CANCELLED：“行动计划”处于 RECOMMENDED、PENDING 或 ONGOING 状态，并被“管理员”取消。
SUPERSEDED：“行动计划”处于 RECOMMENDED 状态，并且由于到期延迟或“集群数据模型”的更新而被 Watcher 自动取代。
下图显示了“行动计划”的不同可能状态以及使状态更改为新值的事件
动作状态机¶
“动作”具有生命周期，其当前状态可能是以下之一
SUCCEEDED：“动作”已成功执行。
FAILED：在尝试执行“动作”时发生错误。
DELETED：“动作”仍然存储在“Watcher 数据库”中，但不再通过 Watcher API 返回。
下图显示了“动作”的不同可能状态以及使状态更改为新值的事件
