Salt框架最强大的功能之一就是事件反应器。 由于反应器功能处在一个开发迭代的过程中，Salt Cloud会定期更新以支持更多的事件反应器功能。 因此，在使用Salt Cloud执行创建和销毁云主机实例时会有很多个环节都会向Salt Master发出事件通知，而事件反应器就可以对这些事件做进一步的管理和使用。
撰写本文时，Salt Cloud中的所有事件都有一个标签，其中包括要管理的实例的ID，以及一个有效负载，该负载描述了当前正在处理的任务。 撰写本文时，Salt Cloud中的所有事件都有一个标签，其中包括要管理的实例的ID，以及一个有效负载，该负载描述了当前正在处理的任务。 Salt Cloud标签看起来像：
salt/cloud/<minion_id>/<task>例如，创建名为web1的实例时触发的第一个事件如下所示：
salt/cloud/web1/creating假设此实例使用的是ec2-centos配置文件，而该配置文件又使用了ec2-config provider驱动程序，则此标签的有效负载会如下所示：
{'name': 'web1',
'profile': 'ec2-centos',
'provider': 'ec2-config:ec2'}在Salt Cloud中创建实例时，无论是通过map、profile配置文件还是直接通过API创建，通常都会触发至少五个事件。 根据所使用的云提供商，可能会有更多。 下面介绍一些常见事件。
该事件仅说明创建实例的过程已经开始。 目前，尚无实际工作执行。 此事件的有效负载包括：
name, profile, provider
Salt Cloud即将向云提供商发出创建实例的请求。 此时，已经收集了发出请求所需的所有变量，事件的有效负载将反映那些通常不会带来安全风险的变量。 返回的内容取决于云提供商。 一些常见的变量是：
name, image, size, location
已成功请求该实例，但是尚无法登录到该实例,因为缺少必要的信息，例如IP地址。 此事件标志着等待该信息的过程的开始。
此事件的有效负载通常仅包含instance_id。
已检索到登录实例所需的信息，但不一定已准备好访问该实例。 在此事件之后，Salt Cloud将等待IP地址响应ping，然后等待指定的端口（通常为22）响应连接，并且在Linux系统上使SSH服务可用。 Salt Cloud将尝试在远程系统上发出date命令，以作为检查可用性的一种方法。 如果未指定ssh_username，将尝试使用用户名列表（从root开始）。 如果为ssh_username配置了一个或多个用户名，它们将按顺序添加到列表的开头。
此事件的有效负载通常仅包含ip_address。
已检测到必需的端口可用，现在Salt Cloud可以登录到实例，上传用于部署的所有文件，然后运行部署脚本。 脚本完成后，Salt Cloud将重新登录到实例并删除所有剩余文件。
许多变量用于部署实例，其中大部分都将在有效负载中可访问。 任何密钥、密码或其他敏感数据都将被从有效载荷中删除。 返回的大多数变量将与profile配置文件或provider驱动程序配置有关，以及服务配置会使用且未被变更过的参数默认值。
部署工作已完成，实例已经可用，已部署了salt并可以使用。 在将实例信息返回给用户并退出之前，此事件是Salt Cloud的最终任务。
此事件的有效负载仅包含初始的 creating 事件。 所有云提供商中都需要此事件。
创建VM时，可以使用某些标签来过滤将多少信息发送到事件总线。 可以在任何provider驱动程序上使用的过滤标签为：
- salt/cloud/<minion_id>/creating
- salt/cloud/<minion_id>/requesting
- salt/cloud/<minion_id>/created
其他提供商可能允许其他标签被过滤； 在这种情况下，该提供程序的文档将包含更多详细信息。
要过滤信息，请在/etc/salt/cloud文件中创建一个名为filter_events的配置段落。 只使用事件标签字符串的最后一段，代表将要过滤的目标标签。 例如，使用creating来表示salt/cloud/<minion_id>/creating：
filter_events:
creating:
keys:
- name
- profile
- provider此处列出的所有键都将添加到已设置为该provider驱动程序显示的默认键中。 如果您希望使用一个更简洁的state，只显示指定的键，请添加另一个名为use_defaults的选项并将其设置为False。
filter_events:
creating:
keys:
- name
- profile
- provider
use_defaults: FalseEvent Reactor内置在Salt Master进程中，因此可以通过master配置文件进行配置。 通常，这是一个位于/etc/salt/master的YAML文件。 此外，主配置项可以YAML格式存储在/etc/salt/master.d/目录中。
这些配置项可以存储在任何一个位置。 但是，它们只能存储在一个位置。 出于组织和安全目的，最好在/etc/salt/master.d/reactor文件中创建一个仅包含事件反应器配置的配置文件。
事件反应器使用称为reactor的top-level配置项。 该块包含要监视的标签列表，每个标签还包括相应的sls文件列表。 例如：
reactor:
- 'salt/minion/*/start':
- '/srv/reactor/custom-reactor.sls'
- 'salt/cloud/*/created':
- '/srv/reactor/cloud-alert.sls'
- 'salt/cloud/*/destroyed':
- '/srv/reactor/cloud-destroy-alert.sls'应将Reactor sls文件放置在/srv/reactor/目录中，以确保环境资源分布风格的一致性，但是Salt目前不强制这样做。
Reactor sls文件遵循与Salt中其他sls文件类似的格式。 默认情况下，它们是用YAML编写的，并且可以使用Jinja进行模板化，但是由于它们是通过Salt的渲染系统处理的，因此同样可以使用任何可用的渲染器（JSON，Mako，Cheetah等）。
与其他sls文件一样，每个节都将以声明ID开头，然后是将要运行的函数，然后是该函数的所有参数。 例如：
# /srv/reactor/cloud-alert.sls
new_instance_alert:
cmd.pagerduty.create_event:
- tgt: alertserver
- kwarg:
description: "New instance: {{ data['name'] }}"
details: "New cloud instance created on {{ data['provider'] }}"
service_key: 1626dead5ecafe46231e968eb1be29c4
profile: my-pagerduty-account当事件反应器收到通知其已创建新实例的事件时，此sls将使用配置的PagerDuty帐户在PagerDuty中创建新事件。
在此示例中，声明ID为new_instance_alert。 调用的函数为cmd.pagerduty.create_event。 此函数的cmd部分指定将调用执行模块和函数，在本例中为pagerduty.create_event函数。
因为指定了执行模块，所以必须指定要在其上调用函数的目标（tgt）。 在这种情况下，使用了一个名为Alertserver的minion。 传递给函数的所有参数都在kwarg块中声明。
当Salt Cloud创建实例时，默认情况下，它将Salt minion和所有指定的Minion配置一起安装配置到该实例上，并自动在master服务器上接受该Minion的密钥。可以指定的配置选项之一是startup_states，通常将其设置为highstate。这将告诉minion一旦有能力则立即申请执行一次highstate。
这可能会在某些云主机上的某些系统镜像上遇到问题。例如，可以将Salt Cloud配置为以root用户或具有sudo访问权限的用户身份登录。虽然某些主机通常使用镜像来锁定远程root访问权限，并要求具有sudo特权的用户登录（尤其是EC2，要求使用其ec2-user的用户），但是大多数云主机会回退到使用root作为所有镜像上的默认登录名，包括适用于通常不允许远程root登录的操作系统（例如Ubuntu）。
对于这些操作系统的用户，可以理解的是，highstate将包含特定的配置以阻止再次的远程root登录。但是，Salt Cloud可能在minion进程开始正常运行之前尚未完成清理部署文件的工作，就开始了highstate的运行。用户曾报告说，Salt Cloud由于尝试清除部署文件而遇到权限被锁定导致的错误。
使用事件反应器可以实现以上管理startup状态的目标。因为一个minion能够在接收命令的同时触发一个事件，所以可以有效地在反应器系统内部使用此事件。以下内容将反应器系统指向正确的sls文件：
reactor:
- 'salt/cloud/*/created':
- '/srv/reactor/startup_highstate.sls'以下sls文件将在目标minion上启动一次highstate状态运行：
# /srv/reactor/startup_highstate.sls
reactor_highstate:
cmd.state.apply:
- tgt: {{ data['name'] }}由于只有在Salt Cloud完成了清除工作后才能触发此事件，因此highstate运行不会踩到Salt Cloud的脚趾。 而且，由于minion上的每个文件都是可配置的，包括/etc/salt/minion，如果需要，仍可以将startup_states配置为将来的minion重启时必须执行的指定配置状态。