26.7. Escribir un agente de alerta
Hay tres tipos de alertas de Pacemaker: alertas de nodo, alertas de cercado y alertas de recursos. Las variables de entorno que se pasan a los agentes de alerta pueden variar, dependiendo del tipo de alerta. Tabla 26.2, “Variables de entorno transmitidas a los agentes de alerta” describe las variables de entorno que se pasan a los agentes de alerta y especifica cuándo la variable de entorno está asociada a un tipo de alerta específico.
Variable de entorno | Descripción |
---|---|
| El tipo de alerta (nodo, cercado o recurso) |
| La versión de Pacemaker que envía la alerta |
| El destinatario configurado |
| Un número de secuencia que se incrementa cada vez que se emite una alerta en el nodo local, que puede utilizarse para referenciar el orden en el que Pacemaker ha emitido las alertas. Una alerta para un evento que ocurrió más tarde en el tiempo tiene confiablemente un número de secuencia más alto que las alertas para eventos anteriores. Tenga en cuenta que este número no tiene ningún significado en todo el clúster. |
|
Una marca de tiempo creada antes de ejecutar el agente, en el formato especificado por la opción meta |
| Nombre del nodo afectado |
|
Detalle del evento. Para las alertas de nodo, es el estado actual del nodo (miembro o perdido). Para las alertas de esgrima, es un resumen de la operación de esgrima solicitada, incluyendo el origen, el objetivo y el código de error de la operación de esgrima, si lo hay. Para las alertas de recursos, se trata de una cadena legible equivalente a |
| ID del nodo cuyo estado ha cambiado (sólo se proporciona con las alertas de nodo) |
| La operación de cercado o de recursos solicitada (sólo se proporciona con las alertas de cercado y de recursos) |
| El código numérico de retorno de la operación de esgrima o de recursos (sólo se proporciona con las alertas de esgrima y de recursos) |
| El nombre del recurso afectado (sólo alertas de recursos) |
| El intervalo de la operación de recursos (sólo alertas de recursos) |
| El código de retorno numérico esperado de la operación (sólo alertas de recursos) |
| Un código numérico utilizado por Pacemaker para representar el resultado de la operación (sólo alertas de recursos) |
A la hora de redactar un agente de alerta, hay que tener en cuenta los siguientes aspectos.
- Los agentes de alerta pueden ser llamados sin destinatario (si no está configurado ninguno), por lo que el agente debe ser capaz de manejar esta situación, aunque sólo salga en ese caso. Los usuarios pueden modificar la configuración por etapas, y añadir un destinatario más tarde.
- Si se configura más de un destinatario para una alerta, el agente de alerta será llamado una vez por cada destinatario. Si un agente no puede ejecutarse simultáneamente, debe configurarse con un solo destinatario. Sin embargo, el agente es libre de interpretar el destinatario como una lista.
- Cuando se produce un evento de cluster, todas las alertas se disparan al mismo tiempo como procesos separados. Dependiendo de cuántas alertas y destinatarios se configuren y de lo que se haga dentro de los agentes de alertas, puede producirse una explosión de carga significativa. El agente podría escribirse para tener esto en cuenta, por ejemplo, poniendo en cola las acciones que consumen muchos recursos en alguna otra instancia, en lugar de ejecutarlas directamente.
-
Los agentes de alerta se ejecutan como el usuario
hacluster
, que tiene un conjunto mínimo de permisos. Si un agente requiere privilegios adicionales, se recomienda configurarsudo
para permitir que el agente ejecute los comandos necesarios como otro usuario con los privilegios adecuados. -
Tenga cuidado de validar y sanear los parámetros configurados por el usuario, como
CRM_alert_timestamp
(cuyo contenido está especificado por el usuariotimestamp-format
),CRM_alert_recipient
, y todas las opciones de alerta. Esto es necesario para protegerse de los errores de configuración. Además, si algún usuario puede modificar el CIB sin tenerhacluster
-nivel de acceso a los nodos del clúster, esto es una preocupación potencial de seguridad también, y usted debe evitar la posibilidad de inyección de código. -
Si un clúster contiene recursos con operaciones para las que el parámetro
on-fail
está configurado comofence
, habrá múltiples notificaciones de valla en caso de fallo, una por cada recurso para el que esté configurado este parámetro más una notificación adicional. Tantopacemaker-fenced
comopacemaker-controld
enviarán notificaciones. Sin embargo, Pacemaker sólo realiza una operación de valla real en este caso, sin importar cuántas notificaciones se envíen.
La interfaz de alertas está diseñada para ser compatible con la interfaz de scripts externos utilizada por el recurso ocf:pacemaker:ClusterMon
. Para preservar esta compatibilidad, las variables de entorno que se pasan a los agentes de alertas están disponibles precedidas de CRM_notify_
así como de CRM_alert_
. Una ruptura en la compatibilidad es que el recurso ClusterMon
ejecutaba los scripts externos como el usuario root, mientras que los agentes de alerta se ejecutan como el usuario hacluster
.