28.7. 编写集群警报代理
Pacemaker 集群警报有三种类型：节点警报、隔离警报和资源警报。传递给报警代理的环境变量可能会由于报警类型而有所不同。下表描述了传递给警报代理的环境变量，并指定环境变量何时与特定警报类型关联。
表 28.2. 传递给报警代理的环境变量
| 环境变量 | 描述 |
|---|---|
|
| 报警类型（节点、隔离或资源） |
|
| 发送报警的 Pacemaker 版本 |
|
| 配置的接收者 |
|
| 每当在本地节点上发出报警时，序列号就会增加，它可以用来参考 Pacemaker 所发出报警的顺序。发生时间较晚的事件的报警序列号比发生时间较早的事件的报警序列号要高。请注意，这个数字没有集群范围的含义。 |
|
|
执行代理前创建的时间戳，使用由 |
|
| 受影响节点的名称 |
|
|
有关事件的详情。对于节点报警，这是节点的当前状态（成员或丢失）。对于隔离报警，这是请求的隔离操作的总结，其中包括起源、目标以及隔离操作错误代码（若有的话）。对于资源报警，这是等同于 |
|
| 状态更改了的节点 ID（仅由节点报警提供） |
|
| 请求的隔离或资源操作（仅由隔离和资源报警提供） |
|
| 保护或资源操作的数字返回代码（仅由隔离和资源警告提供） |
|
| 受影响的资源的名称（仅限资源报警） |
|
| 资源操作的时间间隔（仅限资源报警） |
|
| 操作的预期数字返回码（仅用于资源报警） |
|
| Pacemaker 用来表示操作结果的数字码（仅用于资源报警） |
在编写报警代理时，您必须考虑以下问题。
- 警告代理可以在没有接收者的情况下被调用（如果没有配置任何接收者），因此代理必须能够处理这种情况，即使它只在那种情况下才会退出。用户可以修改配置阶段，并在以后添加一个接收者。
- 如果为报警配置了多个接收者，则会为每个接收者调用一次报警代理。如果代理无法同时运行，则应该只使用单个的接收者进行配置。不过，代理可以自由地将接收者解析为一个列表。
- 当发生集群事件时，所有报警作为单独的进程同时被触发。根据配置了多少报警和接收方以及报警代理中的操作，可能会发生严重的负载突发。可以编写代理来考虑这一点，例如将资源密集型操作排队到其他实例中，而不是直接执行。
-
报警代理以
hacluster 用户身份运行，该用户具有最小权限集。如果代理需要额外的特权，建议配置sudo以允许代理以具有适当特权的另一用户的身份运行必要的命令。 -
请小心地验证和清理用户配置的参数，如
CRM_alert_timestamp（其内容由用户配置的timestamp-format指定）、CRM_alert_recipient和所有报警选项。这是防止配置错误所必需的。此外，如果某些用户可以在不具有hacluster级别权限访问集群节点的情况下修改了 CIB，则这也是一个潜在的安全问题，您应该避免注入代码的可能性。 -
如果集群包含资源，而对资源操作的
on-fail参数设为fence，则失败时会有多个隔离通知，每个设置了此参数的资源都有一个通知，另外还有一个通知。pacemaker-fenced和pacemaker-controld将发送通知。pacemaker 在这种情况下只能执行一个实际隔离操作，无论发送了多少条通知。
报警接口设计为与 ocf:pacemaker:ClusterMon 资源使用的外部脚本接口向后兼容。为了保持这种兼容性，传递给报警代理的环境变量会带有 CRM_notify_ 和 CRM_alert_ 前缀。兼容性方面的一个问题是 ClusterMon 资源以 root 用户身份运行外部脚本，而报警代理则以 hacluster 用户身份运行。
