Práticas recomendadas para o servidor Nagios?

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

Migrei de uma instalaçã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 na maior parte do que precisamos , estou pensando em torná-lo um pouco mais escalável; atualmente, cada host possui seu próprio arquivo /etc/nagios/hosts/e cada host possui todos os seus serviços no mesmo arquivo. Obviamente, isso não é o ideal, mas também não ofusca toda a minha configuração em centenas de arquivos diferentes.

Então, minha pergunta é a seguinte: para qualquer administrador experiente do Nagios por aí, qual é a melhor maneira de fazer uso de grupos de host / grupos de serviços sem complicar demais a configuração?

Grupos de host e modelos.

Os modelos permitem definir classes para seus hosts e serviços, por exemplo, "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 Windows", com cada um definindo as informações de contato apropriadas.

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

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

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

Os grupos de host permitem agrupar todas as verificações de um subconjunto de seus hosts. Tenha coisas como "baseline-linux-hosts" que verificam a carga, o espaço em disco, a sshcapacidade e qualquer outra coisa que esteja em todos os hosts que você monitora. Adicione grupos como "https-servers" com verificações de conectividade HTTP, HTTPS e datas de validade do certificado 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 verificar se as ferramentas de acessibilidade da VM estão funcionando corretamente.

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

Se você usar a cfg_dirdiretiva em seu nagios.cfgarquivo, o Nagios pesquisará recursivamente nesse 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/
  • commands.d /
    • http.cfg
    • nrpe.cfg
    • smtp.cfg
    • ssh.cfg
  • hosts.d /
    • host1.cfg
    • host2.cfg
    • host3.cfg
  • hostgroups.d /
    • hostgroup1.cfg
    • hostgroup2.cfg

Costumo criar um diretório para cada tipo de recurso (comandos, grupos de contatos, contatos, escalações, grupos de hosts, hosts, grupos de serviços, períodos de tempo), exceto os serviços, que são agrupados com os hosts ou grupos de hosts que os utilizam.

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

Observe que o acima também divide os comandos em vários arquivos, geralmente por protocolo. Assim, o nrpe.cfgarquivo teria os comandos check_nrpee check_nrpe_1arg, ao mesmo tempo http.cfgpoderia ter check_http, check_http_port, check_https, check_https_port, e check_https_cert. ¹

Normalmente, não tenho um número enorme de modelos, por isso geralmente só tenho um hosts.d/templates.cfgarquivo e um services.d/templates.cfgarquivo. Se você usá-los com mais intensidade, eles podem entrar em arquivos com nome apropriado em um templates.ddiretório.

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

Faça uso extensivo de serviços, grupos de hosts e modelos. Crie grupos de hosts e atribua serviços aos grupos de hosts. Use grupos de serviços para dependências, escalações e agrupamento lógico na interface do usuário da web.

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

Leia os documentos sobre herança e também a página de truques para economizar tempo . A herança múltipla pode se tornar complicada, mas, quando usada corretamente, economiza muito tempo.

Eu estava acostumado a configurar meus servidores nagios (antes de mudar para Icinga) dessa maneira, e não há falta de desempenho até que você alcance mais de 500 serviços, pelo menos, com um servidor de 512Mb de memória / 1 CPU. grupos de host e grupos de serviços podem ser tratados completamente separadamente, e eu recomendo essa abordagem, pois permite ter um arquivo por servidor (serviços para este servidor definido neste arquivo) e, em seguida, no arquivo por grupo de host / grupos de serviços. Isso é apenas mais compreensível / claro.

Se você encontrar problemas de escalabilidade, consulte o nagios-nrpe-server, que realiza verificações no lado do cliente e tudo o que o servidor nagios faz está pedindo apenas resultados; que poupam o recurso da verificação. (O Nagios lança check_nrpe, o cliente é solicitado, executa verificações localmente e responde de volta aos nagios). Tendo em mente que todas as verificações não podem ser tratadas dessa maneira (SNMP, por exemplo).

Para finalizar, e mesmo que pareça fora do escopo em relação à sua pergunta, sugiro que mude para o Icinga, que é muito mais escalável, apoiado por uma comunidade mais forte, realmente preocupada com implementações de novos recursos e suporte ao usuário. A configuração é a mesma (mesmos arquivos de configuração, mesma sintaxe).

Estou usando este esquema:

• anfitriões,
• grupos de host,
• serviços remotos,
• serviços locais.

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

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

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

E para o arquivo ou a parte de 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 estiver usando, poderá informar automaticamente a todos os hosts / janelas ou hosts Linux para serem membros de um grupo de hosts definido que você criou.