Embora possa ser confuso que você tenha apenas instalado o pacote binário icinga2 em um nó que está chamando de "cliente", é razoável fazê-lo.
Dessa forma, você se beneficiará das seguintes coisas:
- Mesma configuração para todos os nós em sua configuração distribuída (cluster), seja mestre, satélite, cliente, agente ou qualquer outra função que você atribuir a eles.
- Mesma configuração dsl para todos os nós envolvidos
- Os clientes usam os mesmos benefícios que os nós de cluster: SSL x509, IPv4 & Suporte a IPv6, log de repetição na perda de conexão, etc.
A configuração de clientes é auxiliada por cli wizards e mecanismos de assinatura automática de CSR. No entanto, se você já estiver familiarizado com o conceito de zona e endpoint no Icinga 2, também poderá usar suas próprias ferramentas para configurar os clientes, bem como implantar os certificados SSL (por exemplo, reutilizando o CA Puppet).
Embora ao longo do tempo, havia três métodos diferentes usados pela comunidade, que agora são populares, exigindo que eles sejam explicados em detalhes nos documentos (o que é confuso para ler e ainda na lista de afazeres para reescrever).
1) Clientes com configuração local. O Icinga 2 vem com algumas verificações de exemplo básicas que monitoram o nó local. Adicionando novas verificações localmente e reiniciando o Icinga 2, o núcleo no cliente começará a executar as verificações e relatá-las ao nó mestre do conector. No mestre, você é capaz de listar os nós do repositório coletado, preto / whitelist-los e, em seguida, gerar configuração usando 'node update-config'.
Caso você esteja achando complicado gerenciar a configuração de cada cliente - isso é verdade, mas em termos de automação e configuração local ainda é um ponto válido.
2) Central de configuração mestre com (satélites e) clientes. Esse método reutiliza o mecanismo Zone e Endpoint do cluster Icinga 2 e permite distribuir a configuração do mestre para os clientes. Dessa forma, você apenas gerenciará os objetos host / service no master e deixará que o Icinga 2 cuide do resto. Há ainda espaço para uma zona global, incluindo modelos, comandos de verificação, etc.
Nesse cenário, você apenas configurará o cliente uma vez e permitirá que o mestre cuide do resto. Você também obterá o benefício de um agendador local no cliente, que continua a verificar e reproduzir novamente o histórico de verificação no restabelecimento da conexão (o que certamente é útil para relatórios de SLA).
3) Se você está procurando por um NRPE como a execução de verificação sem um agendador local, mas um executor de plug-in de comando rápido, você pode usar os clientes como "ponte de execução de comando". Nesse cenário, você inicialmente configurará o cliente uma vez e adicionará sua configuração de terminal / zona ao mestre. Os objetos de host / serviço verificáveis também são configurados no mestre, mas fazem referência ao chamado "ponto_de_controlo". Isso faz com que Icinga 2 envie a execução da verificação para o cliente Icinga 2, que executa de forma assíncrona a verificação e envia o resultado de volta ao mestre.
Você ainda precisará das definições locais do CheckCommand no cliente. A Biblioteca de Modelos Icinga (ITL) já fornece muitos deles, mas no caso de você querer adicionar seus próprios, você deve considerar tomar 2) com apenas uma zona global sincronizando a configuração de comando.
Dessa forma, você também pode garantir que certos parâmetros de comando passados no mestre possam ser desabilitados em clientes específicos (o infame parâmetro "-a" do nrpe, mas de uma maneira mais controlada).
Mais pode ser encontrado na documentação: link
Quando se trata do Debian 5 Lenny - que é o fim da vida e, portanto, não é suportado pelo Icinga 2. Vá para check_by_ssh então. link