Práticas recomendadas do servidor Nagios?

Question

Eu corro um servidor Nagios de tamanho médio. Ele monitora aproximadamente 40 servidores com 180 serviços atualmente e só cresce a cada dia.

Eu migrei de uma configuração antiga do Nagios que foi configurada de uma maneira muito esotérica, forçando-me a reconfigurar tudo do zero.

Agora que o servidor está em execução e funciona para a maior parte do que precisamos , estou tentando torná-lo um pouco mais escalável; Atualmente, cada host é seu próprio arquivo em /etc/nagios/hosts/ e cada host tem todos os seus serviços no mesmo arquivo. Isso obviamente não é o ideal, mas também não ofusca toda a minha configuração em centenas de arquivos diferentes.

Então, minha pergunta é: para qualquer administrador experiente do Nagios, qual é a melhor maneira de usar hostgroups / servicegroups sem complicar demais a configuração?

    

Answer 1

Grupos de host e modelos.

Os modelos permitem-lhe definir turmas para os seus anfitriões e serviços, por ex. "serviço normal", "serviço crítico", "host de baixa prioridade". Eles também servem como uma maneira útil de dividir responsabilidades se você tiver várias equipes com responsabilidades diferentes, para que você possa ter um modelo "host Linux" e um modelo "host do Windows", com cada um definindo as informações de contato apropriadas. p>

Você pode usar vários modelos em um único recurso, para poder compor modelos ortogonais apropriados. Por exemplo, você pode ter

host foo {
    use windows-host,normal-priority-host
    ...
}

que extrairia as informações de contato (e escalações) para a equipe do Windows e as taxas de pesquisa e os limites para um host "normal".

Hostgroups permitem agrupar todas as verificações de um subconjunto de seus hosts. Tenha coisas como "baseline-linux-hosts" que verificam carga, espaço em disco, ssh capacidade e quaisquer outras coisas que devem estar em todos os hosts que você monitora. Adicione grupos como "https-servers" com verificações de conectividade HTTP, conectividade HTTPS e datas de expiração de certificados SSL; "servidores de arquivos" com verificações de acessibilidade NFS e SMB e talvez verificações de disco mais agressivas; ou "máquinas virtuais" com verificações para saber se as ferramentas de acessibilidade da VM estão funcionando corretamente.

Coloque cada host e host em seu próprio arquivo. Esse arquivo deve conter primeiro a definição do host ou do grupo de hosts, seguida pelas definições dos serviços que se aplicam a ele.

Se você usar a diretiva cfg_dir no seu arquivo nagios.cfg , o Nagios pesquisará recursivamente por esse diretório. Faça uso disso. Para uma configuração de cfg_dir=/etc/nagios/conf.d , você pode ter uma árvore de diretórios como a seguinte:

• /etc/nagios/conf.d/
  • comandos.d /
    • link
    • nrpe.cfg
    • smtp.cfg
    • ssh.cfg
  • hosts.d /
    • host1.cfg
    • host2.cfg
    • host3.cfg
  • hostgroups.d /
    • hostgroup1.cfg
    • hostgroup2.cfg

Eu costumo criar um diretório para cada tipo de recurso (comandos, grupos de contatos, contatos, escalações, grupos de hosts, hosts, servicegroups, timeperiods), exceto para serviços, que são agrupados com os hosts ou grupos de host que os utilizam.

A estrutura precisa pode variar de acordo com suas necessidades organizacionais. Em um trabalho anterior, usei subdiretórios em hosts.d para cada site diferente. No meu trabalho atual, a maioria das definições do host do Nagios é gerenciada pelo Puppet, então há um diretório para os hosts gerenciados pelo Puppet e um para os hosts gerenciados manualmente.

Observe que o acima também divide os comandos em vários arquivos, geralmente por protocolo. Assim, o arquivo nrpe.cfg teria os comandos check_nrpe e check_nrpe_1arg , enquanto http.cfg poderia ter check_http , check_http_port , check_https , check_https_port e check_https_cert . ¹

Normalmente, não tenho um grande número de modelos, por isso, normalmente, só tenho um arquivo hosts.d/templates.cfg e um arquivo services.d/templates.cfg . Se você usá-los com mais intensidade, eles poderão entrar em arquivos com nomes apropriados em um diretório templates.d .

¹ Eu também gosto de ter um comando check_http_blindly , que é basicamente check_http -H $HOSTADDRESS$ -I $HOSTADDRESS$ -e HTTP/1. ; ele retorna OK mesmo se receber um código de resposta 403.

    

Answer 2

Faça uso extensivo de serviço e grupos de host e modelos. Crie grupos de host e atribua serviços aos grupos de host. Use grupos de serviços para dependências, escalações e agrupamentos lógicos na interface da Web.

Se você tiver grupos para tudo, adicionar um novo host é apenas 3 ou 4 linhas: nome, endereço, modelo (s) e (opcionalmente) grupos de host. Tudo pode ser modelado.

Não deixe de ler os documentos sobre herança e também o página de truques que economizam tempo . A herança múltipla pode ser complicada, mas quando usada corretamente, é uma grande economia de tempo.

    

Answer 3

Eu estava acostumado a configurar meus servidores nagios (antes de mudar para o Icinga) dessa forma, e não faltam performances até que você atinja mais de 500 serviços pelo menos com um servidor de 512Mb de memória / 1 CPU. grupos de hosts e grupos de serviços podem ser tratados completamente separadamente, e eu recomendo essa abordagem, pois ela permite ter um arquivo por servidor (serviços para esse servidor definido nesse arquivo) e, em seguida, em arquivo por grupo de hosts / grupos de serviços. Isso só é mais compreensível / claro.

Se você se deparar com problemas de escalabilidade, você pode querer dar uma olhada no nagios-nrpe-server, que executa verificações no lado do cliente e tudo o que seu servidor faz é pedir apenas resultados; que poupa o recurso do cheque. (Nagios lança check_nrpe, o cliente é solicitado, realiza verificações localmente e responde de volta aos nagios). Tendo em mente que todas as verificações não podem ser tratadas desta maneira (SNMP por exemplo).

Para terminar, e mesmo que pareça fora do escopo da sua pergunta, sugiro mudar para a Icinga, que é mais escalável, mantida por uma comunidade mais strong, realmente interessada em novas implementações de recursos e suporte ao usuário. A configuração é a mesma (mesma configuração, mesma sintaxe).

    

Answer 4

Estou usando este esquema:

• hosts,
• grupos de host,
• serviços remotos,
• serviços locais.

Cada entidade possui seu próprio arquivo. Além dos modelos, você sempre pode tornar o seu limpador de configuração mais legível. Por exemplo, você pode ter média de carga, espaço em disco, memória em cada host. Por isso, é muito fácil e prático criar um modelo genérico e usá-lo.

    

Answer 5

Você não pode complicar a configuração com grupos. Como asciiphil dizer, você faz um arquivo ou você pode definir os mesmos grupos em alguns dos arquivos existentes como (hosts.cfg ou o que nunca), e você faz este arquivo ou você diz ao nagios que este arquivo está ativo (isto é, se você cria um novo campo, se não já está ativo), e isso está no arquivo nagios.cfg onde você coloca o caminho do arquivo recém-criado. "cfg_file = / usr / local / nagios / etc / objetos / NEW_FILE.cfg"

A outra coisa é apenas fazer grupos dependendo da sua infraestrutura. Se, por exemplo, eu tenho o servidor linux e windows, eu farei dois grupos diferentes, um para o linux e outro para o windows. É o mesmo com os serviços. Dependendo de como você gostaria de configurar e ver quando você monitora no monitor, como você gostaria de vê-los como grupos.

E para o arquivo ou a parte como criar um grupo, é simples.

    define hostgroup{
    hostgroup_name novell-servers
    alias Novell Servers
    members netware1,netware2,netware3,netware4
    }

E na configuração do host / ou se você estiver usando o modelo ou se já tiver definido um modelo ou serviço de host e usado, será possível dizer automaticamente a todos os hosts / janelas ou hosts Linux como membros de um grupo de host definido você criou.