Monitorando Debian 5, 6, 7 hosts com icinga2

1

Instalei com sucesso icinga2 e icinga2-web no Debian 8. O problema é que preciso monitorar servidores com o Debian 5, 6 e 7 instalados. É mesmo possível?

Se bem entendi - eu preciso de um cliente icinga2 instalado no host que eu quero monitorar e não existe um cliente específico no icinga2 - é necessário instalar todo o pacote icinga2.

Eu tentei instalar este pacote no squeeze de backports (instruções encontradas aqui: link ) mas sem sucesso.

Quando inicio minha aventura com monitoramento - agradeço toda ajuda. Agradecemos antecipadamente.

    
por user326343 09.12.2015 / 15:20

3 respostas

3

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

    
por 09.12.2015 / 21:27
2

Icinga é uma bifurcação de nagios e usa os mesmos plugins / clientes para monitoramento. O que você precisa é do daemon nrpe e nagios-plugins.

O daemon nrpe está sendo executado nos servidores que você deseja monitorar e está atendendo a pedidos de nagios / icinga remotos. Quando tal requisição vier, ele pode executar um plugin em particular e retornar o resultado ao seu servidor icinga.

Os plug-ins nagios são conjuntos de pequenos programas que verificam o status de um determinado serviço / recurso e relatam com OK, WARNING, CRITICAL dependendo das condições.

Os pacotes de que você precisa são:

  • nagios-plugins
  • nagios-nrpe-server

Você precisa instalá-los em cada servidor que deseja monitorar.

    
por 09.12.2015 / 16:07
0

Se você precisar verificar apenas a disponibilidade de serviços disponíveis externamente (como o HTTP), não será necessário instalar o software no cliente.

    
por 14.12.2015 / 17:31

Tags