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.

Tabla 26.2. Variables de entorno transmitidas a los agentes de alerta

Variable de entornoDescripción

CRM_alert_kind

El tipo de alerta (nodo, cercado o recurso)

CRM_alert_version

La versión de Pacemaker que envía la alerta

CRM_alert_recipient

El destinatario configurado

CRM_alert_node_sequence

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.

CRM_alert_timestamp

Una marca de tiempo creada antes de ejecutar el agente, en el formato especificado por la opción meta timestamp-format. Esto permite que el agente tenga una hora fiable y de alta precisión de cuándo ocurrió el evento, independientemente de cuándo se invocó el propio agente (que podría retrasarse debido a la carga del sistema u otras circunstancias).

CRM_alert_node

Nombre del nodo afectado

CRM_alert_desc

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 CRM_alert_status.

CRM_alert_nodeid

ID del nodo cuyo estado ha cambiado (sólo se proporciona con las alertas de nodo)

CRM_alert_task

La operación de cercado o de recursos solicitada (sólo se proporciona con las alertas de cercado y de recursos)

CRM_alert_rc

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)

CRM_alert_rsc

El nombre del recurso afectado (sólo alertas de recursos)

CRM_alert_interval

El intervalo de la operación de recursos (sólo alertas de recursos)

CRM_alert_target_rc

El código de retorno numérico esperado de la operación (sólo alertas de recursos)

CRM_alert_status

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 configurar sudo 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 usuario timestamp-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 tener hacluster-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 como fence, 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. Tanto pacemaker-fenced como pacemaker-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.
Nota

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.