Red Hat Training

A Red Hat training course is available for RHEL 8

26.7. Escrever um agente de alerta

Há três tipos de alertas de Pacemaker: alertas de nós, alertas de cercas e alertas de recursos. As variáveis de ambiente que são passadas aos agentes de alerta podem ser diferentes, dependendo do tipo de alerta. Tabela 26.2, “Variáveis Ambientais Passadas aos Agentes de Alerta” descreve as variáveis de ambiente que são passadas aos agentes de alerta e especifica quando a variável de ambiente é associada a um tipo de alerta específico.

Tabela 26.2. Variáveis Ambientais Passadas aos Agentes de Alerta

Variável AmbientalDescrição

CRM_alert_kind

O tipo de alerta (nó, vedação, ou recurso)

CRM_alert_version

A versão do Pacemaker enviando o alerta

CRM_alert_recipient

O destinatário configurado

CRM_alert_node_sequence

Um número seqüencial aumentado sempre que um alerta é emitido no nó local, que pode ser usado para referenciar a ordem na qual os alertas foram emitidos pela Pacemaker. Um alerta para um evento que aconteceu mais tarde de forma confiável tem um número seqüencial maior do que os alertas para eventos anteriores. Esteja ciente de que este número não tem um significado de agrupamento.

CRM_alert_timestamp

Um carimbo de tempo criado antes da execução do agente, no formato especificado pela meta opção timestamp-format. Isto permite que o agente tenha um tempo confiável e de alta precisão de quando o evento ocorreu, independentemente de quando o próprio agente foi invocado (o que poderia ser potencialmente atrasado devido à carga do sistema ou outras circunstâncias).

CRM_alert_node

Nome do nó afetado

CRM_alert_desc

Detalhe do evento. Para alertas de nó, este é o estado atual do nó (membro ou perdido). Para alertas de esgrima, este é um resumo da operação de esgrima solicitada, incluindo origem, alvo e código de erro da operação de esgrima, se houver. Para alertas de recursos, este é um equivalente de string legível de CRM_alert_status.

CRM_alert_nodeid

Identificação do nó cujo status mudou (fornecido apenas com alertas de nó)

CRM_alert_task

A operação de esgrima ou recurso solicitada (apenas com alertas de esgrima e recursos)

CRM_alert_rc

O código numérico de retorno da operação de cercado ou recurso (fornecido apenas com alertas de cercado e recurso)

CRM_alert_rsc

O nome do recurso afetado (somente alertas de recursos)

CRM_alert_interval

O intervalo da operação do recurso (somente alertas de recurso)

CRM_alert_target_rc

O código numérico de retorno esperado da operação (somente alertas de recursos)

CRM_alert_status

Um código numérico utilizado pela Pacemaker para representar o resultado da operação (apenas alertas de recursos)

Ao escrever um agente de alerta, você deve levar em conta as seguintes preocupações.

  • Agentes de alerta podem ser chamados sem destinatário (se nenhum estiver configurado), portanto, o agente deve ser capaz de lidar com esta situação, mesmo que só saia nesse caso. Os usuários podem modificar a configuração em etapas, e adicionar um destinatário mais tarde.
  • Se mais de um destinatário estiver configurado para um alerta, o agente de alerta será chamado uma vez por destinatário. Se um agente não for capaz de operar simultaneamente, ele deverá ser configurado com apenas um único destinatário. O agente é livre, entretanto, para interpretar o destinatário como uma lista.
  • Quando ocorre um evento de cluster, todos os alertas são disparados ao mesmo tempo em que os processos são separados. Dependendo de quantos alertas e destinatários são configurados e do que é feito dentro dos agentes de alerta, pode ocorrer uma explosão de carga significativa. O agente pode ser escrito para levar isto em consideração, por exemplo, enfileirando ações de recursos intensivos em alguma outra instância, em vez de executá-las diretamente.
  • Os agentes de alerta são executados como o usuário hacluster, que tem um conjunto mínimo de permissões. Se um agente requer privilégios adicionais, recomenda-se configurar sudo para permitir que o agente execute os comandos necessários como outro usuário com os privilégios apropriados.
  • Tenha o cuidado de validar e higienizar parâmetros configurados pelo usuário, tais como CRM_alert_timestamp (cujo conteúdo é especificado pelo usuário-configurado timestamp-format), CRM_alert_recipient, e todas as opções de alerta. Isto é necessário para proteger contra erros de configuração. Além disso, se algum usuário pode modificar a CIB sem ter acesso aos nós de cluster em hacluster, esta é uma preocupação potencial de segurança também, e o usuário deve evitar a possibilidade de injeção de código.
  • Se um cluster contém recursos com operações para as quais o parâmetro on-fail está definido para fence, haverá múltiplas notificações de falha da cerca, uma para cada recurso para o qual este parâmetro está definido mais uma notificação adicional. Tanto o pacemaker-fenced como o pacemaker-controld enviarão notificações. O marcapasso realiza apenas uma operação de cerca real neste caso, entretanto, não importa quantas notificações sejam enviadas.
Nota

A interface de alertas é projetada para ser retrocompatível com a interface de scripts externos utilizada pelo recurso ocf:pacemaker:ClusterMon. Para preservar esta compatibilidade, as variáveis de ambiente passadas aos agentes de alerta estão disponíveis com CRM_notify_ bem como CRM_alert_. Uma quebra na compatibilidade é que o recurso ClusterMon executou scripts externos como usuário root, enquanto os agentes de alerta são executados como usuário hacluster.