Uso de los flujos de trabajo para acciones de alerta

Los flujos de trabajo se pueden ejecutar de manera opcional como alerta. Para que un flujo de trabajo pueda ser elegible como acción de alerta, la acción alert del flujo de trabajo debe estar configurada con el valor true.

Cuando se ejecutan como acciones de alerta, los flujos de trabajo asumen la identidad del usuario que los creó. Por este motivo, todo flujo de trabajo que deba ser elegible como acción de alerta debe tener el parámetro setid configurado con el valor true. Las acciones de alerta tienen un parámetro de objeto único que tiene los siguientes miembros:

Tabla 4-8  Miembros requeridos para el contexto de ejecución de las alertas

Miembro obligatorio Tipo Descripción class Cadena Clase de alerta. code Cadena Código de alerta. items Objeto Objeto que describe la alerta. timestamp Fecha Fecha/hora de la alerta.

El miembro items del objeto de parámetros tiene los siguientes miembros:

Tabla 4-9  Miembros requeridos para el miembro de elementos

Miembro obligatorio Tipo Descripción url Cadena Dirección URL de la página web en donde se describe la alerta. action Cadena Acción que debe realizar el usuario en respuesta a la alerta. impact Cadena Impacto del evento que generó la alerta. description Cadena Cadena en lenguaje natural en donde se describe la alerta. severity Cadena Gravedad del evento que generó la alerta.

Los flujos de trabajo que se ejecutan como acciones de alerta pueden utilizar la función audit para generar entradas de log de auditoría. Se recomienda generar toda la información de depuración relevante para el log de auditoría mediante la función audit. Por ejemplo, en el siguiente flujo de trabajo, se ejecuta el failover si se tiene el estado de cluster, pero se realiza una auditoría de los fallos que puedan producirse al reiniciar:

Ejemplo 4-9  Flujo de trabajo auditoría de errores al reiniciar

Por ejemplo, en el siguiente flujo de trabajo, se ejecuta el failover si se tiene el estado de cluster, pero se realiza una auditoría de los fallos que puedan producirse al reiniciar:

var workflow = {
       name: 'Failover',
       description: 'Fail the node over to its clustered peer',
       alert: true,
       setid: true,
       execute: function (params) {
               /*
                * To failover, we first confirm that clustering is configured
                * and that we are in the clustered state.  We then reboot,
                * which will force our peer to takeover.  Note that we're
                * being very conservative by only rebooting if in the
                * AKCS_CLUSTERED state:  there are other states in which it
                * may well be valid to failback (e.g., we are in AKCS_OWNER,
                * and our peer is AKCS_STRIPPED), but those states may also
                * indicate aberrent operation, and we therefore refuse to
                * failback.  (Even in an active/passive clustered config, a
                * FAILBACK should always be performed to transition the
                * cluster peers from OWNER/STRIPPED to CLUSTERED/CLUSTERED.)
                */
               var uuid = params.uuid;
               var clustered = 'AKCS_CLUSTERED';

               audit('attempting failover in response to alert ' + uuid);

               try {
                       run('configuration cluster');
               } catch (err) {
                       audit('could not get clustered state; aborting');
                       return;
               }

               if ((state = get('state')) != clustered) {
                       audit('state is ' + state + '; aborting');
                       return;
               }

               if ((state = get('peer_state')) != clustered) {
                       audit('peer state is ' + state + '; aborting');
                       return;
               }

               run('cd /');
               run('confirm maintenance system reboot');
       }
};