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.
| Variável Ambiental | Descrição |
|---|---|
|
| O tipo de alerta (nó, vedação, ou recurso) |
|
| A versão do Pacemaker enviando o alerta |
|
| O destinatário configurado |
|
| 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. |
|
|
Um carimbo de tempo criado antes da execução do agente, no formato especificado pela meta opção |
|
| Nome do nó afetado |
|
|
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 |
|
| Identificação do nó cujo status mudou (fornecido apenas com alertas de nó) |
|
| A operação de esgrima ou recurso solicitada (apenas com alertas de esgrima e recursos) |
|
| O código numérico de retorno da operação de cercado ou recurso (fornecido apenas com alertas de cercado e recurso) |
|
| O nome do recurso afetado (somente alertas de recursos) |
|
| O intervalo da operação do recurso (somente alertas de recurso) |
|
| O código numérico de retorno esperado da operação (somente alertas de recursos) |
|
| 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 configurarsudopara 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-configuradotimestamp-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 emhacluster, 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-failestá definido parafence, 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 opacemaker-fencedcomo opacemaker-controldenviarão notificações. O marcapasso realiza apenas uma operação de cerca real neste caso, entretanto, não importa quantas notificações sejam enviadas.
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.
