MK Livestatus.
1. Como acessar os dados de status do Nagios.
1.1. Acessando dados de status hoje.
A maneira clássica de acessar o status atual de seus hosts e serviços é lendo e analisando o status do arquivo. dat, que é criado por Nagios regularmente. O intervalo de atualização é configurado via status_update_interval em nagios. cfg. Um valor típico é de 10 segundos. Se a sua instalação estiver ficando maior, talvez seja necessário aumentar esse valor para minimizar o uso da CPU e o IO do disco. A interface da web nagios usa status. dat para exibir seus dados.
Parar status. dat não é muito popular entre os desenvolvedores de addons. Muitos usam outra abordagem: NDO. Este é um módulo NEB que é carregado diretamente no processo Nagios e envia todas as atualizações de status através de um soquete UNIX para um processo auxiliar. O processo auxiliar cria instruções SQL e atualiza várias tabelas em um banco de dados MySQL ou PostgreSQL. Esta abordagem tem várias vantagens sobre status. dat:
Os dados são atualizados imediatamente, não apenas a cada 10 ou 20 segundos. As aplicações têm acesso fácil aos dados via SQL. Nenhum analisador para status. dat é necessário. Em grandes instalações, o acesso para os addons aos dados é mais rápido, em seguida, lendo status. dat.
Infelizmente, no entanto, a NDO também possui algumas deficiências graves:
Tem uma configuração complexa. Ele precisa de um banco de dados (em rápido crescimento) para ser administrado. Ele come uma parcela significativa de seus recursos de CPU, apenas para manter o banco de dados up-todate. O arrumação regular do banco de dados pode pendurar seu Nagios por minutos ou até uma hora por dia.
1.2. O futuro.
Desde a versão 1.1.0, o Check_MK oferece uma abordagem completamente nova para acessar o status e também dados históricos: Livestatus. Assim como o NDO, Livestatus faz uso da Nagios Event Broker API e carrega um módulo binário em seu processo Nagios. Mas, então, NDO, a Livestatus não escreve ativamente dados. Em vez disso, ele abre um soquete pelo qual os dados podem ser recuperados sob demanda.
O soquete permite que você envie um pedido para hosts, serviços ou outros dados e obtenha uma resposta imediata. Os dados são lidos diretamente das estruturas de dados internas da Nagios. Livestatus não cria sua própria cópia desses dados. A partir da versão 1.1.2, você também pode recuperar dados históricos dos arquivos de log Nagios via Livestatus.
Esta não é apenas uma abordagem incrivelmente simples, mas também extremamente rápida. Algumas vantagens são:
Ao contrário do NDO, o uso do Livestatus não impõe nenhuma carga mensurável ao seu CPU. Apenas no processamento de consultas, é necessária uma quantidade muito pequena de CPU. Mas isso nem vai bloquear Nagios. O Livestatus produz zero disco IO ao pesquisar dados de status. Acessar os dados é muito mais rápido do que analisar status. dat ou consultar um banco de dados SQL. Nenhuma configuração é necessária, nenhuma base de dados é necessária. Nenhuma administração é necessária. Livestatus escala bem para grandes instalações, mesmo para além de 50.000 serviços. O Livestatus oferece acesso a dados específicos de Nagios que não estão disponíveis para qualquer outro método de acesso de status disponível - por exemplo, a informação se um host está atualmente em seu período de notificação.
Ao mesmo tempo, Livestatus fornece sua própria linguagem de consulta que é simples de entender, oferece a maior parte da flexibilidade do SQL e, ainda mais, em alguns casos. Seu protocolo é rápido, leve e não precisa de um cliente binário. Você pode até obter acesso a partir do shell sem qualquer software auxiliar.
1.3. O presente.
Livestatus ainda é uma tecnologia jovem, mas já muitos addons suportam Livestatus como fonte de dados ou até mesmo o propõem como padrão. Aqui está uma lista (incompleta) de addons com o suporte Livestatus: NagVis - nagvis NagiosBP - bp-addon. monitoringexchange Thruk - thruk CoffeeSaint - vanheusden / java / CoffeeSaint / RealOpInsight - realopinsight e, claro: Check_MK Multisite!
Por favor, envie-nos se você acha que esta lista está incompleta.
2. Configurando e usando o Livestatus.
2.1. Configuração automática.
A maneira típica de configurar o Livestatus é apenas responder a sim quando solicitado pela configuração Check_mk. Você precisa de todas as ferramentas instaladas que são necessárias para compilar programas C ++. Estes são pelo menos: O compilador GNU C ++ (embalado como g ++ no Debian) O utilitário faz (compactado como make) Os arquivos de desenvolvimento para o libc (libc6-dev) Os arquivos de desenvolvimento para a biblioteca padrão C ++ (libstdc ++ 6-dev )
O script setup. sh compila um módulo chamado livestatus. o e o copia para / usr / lib / check_mk (se você não alterou esse caminho). Ele também adiciona duas linhas ao seu nagios. cfg, que são necessárias para carregar o módulo. Depois disso, você só precisa reiniciar o Nagios e um soquete Unix com o nome ao vivo deve aparecer no mesmo diretório que o Nagios.
2.2. Configuração manual.
Existem várias situações em que uma configuração manual é preferível, por exemplo: se você não deseja usar o Check_MK, mas apenas o Livestatus Se a configuração automática não funcionar corretamente (o que é improvável, mas não impossível). Se você quiser fazer alterações no código-fonte do Livestatus.
Para configurar manualmente o Livestatus, você pode baixar o código fonte independente do Check_MK na página de download. Desembale o tarball em um local conveniente e mude para o diretório recém-criado:
Agora vamos compilar o módulo. O Livestatus usa um padrão de configuração - script e, portanto, é compilado com ./configure && make.
Se você estiver executando em uma CPU multicore você pode acelerar a compilação adicionando - j 4 ou - j 8 para fazer:
. e assim por diante. . Após a compilação bem-sucedida, uma instalação de instalação instalará um único arquivo chamado livestatus. o em / usr / local / lib / mk-livestatus e o pequeno programa unixcat em / usr / local / bin (como de costume, você pode alterar os caminhos com opções padrão para configurar ):
Sua última tarefa é carregar o livestatus. o em Nagios. Recomenda-se a Nagios que carregue esse módulo e envie todos os eventos de atualização de status para o módulo pelas duas linhas a seguir em nagios. cfg:
O único argumento obrigatório é o caminho completo para o soquete UNIX que o Livestatus deve criar (/ var / lib / nagios / rw / live no nosso exemplo). Por favor, mude isso se necessário. O melhor é provavelmente colocá-lo no mesmo diretório que o tubo Nagios. Assim como o Nagios faz com o seu tubo, Livestatus cria o soquete com as permissões 0660. Se o diretório em que o soquete estiver localizado tenha o bit SGID para o conjunto de grupos (chmod g + s), o soquete será de propriedade do mesmo grupo que o diretório.
Depois de configurar o Livestatus - por setup. sh ou manualmente - reinicie o Nagios. Duas coisas agora devem acontecer: o arquivo de soquete é criado. O arquivo de log de Nagios mostra que o módulo foi carregado:
2.3. Opções para nagios. cfg.
Livestatus entende várias opções, que podem ser adicionadas à linha que começa com broker_module:
Aqui está um exemplo de como adicionar parâmetros:
3. Usando Livestatus.
Uma vez que seu módulo Livestatus esteja configurado e executado, você pode usar o seu soquete unix para recuperar dados de status ao vivo. Toda linguagem de programação relevante no Linux tem uma maneira de abrir esse soquete. Vamos mostrar como acessar o soquete com o shell e com o Python. Outras linguas de programação são deixadas como um exercício para o leitor.
3.1. Acessando Livestatus com o shell.
Um soquete unix é muito semelhante a um pipe nomeado, mas tem duas diferenças importantes: você pode ler e escrever para ele (enquanto um tubo é unidirecional). Você não pode acessá-lo com eco ou gato.
Livestatus vem com um pequeno utilitário chamado unixcat que pode se comunicar através de um soquete unix. Ele envia todos os dados é lido de stdin no soquete e grava todos os dados provenientes do socket para stdout.
O comando a seguir mostra como enviar um comando para o soquete e recuperar a resposta - neste caso uma tabela de todos os seus hosts:
Se você conseguir esse resultado, tudo está funcionando bem e você pode querer continuar lendo com o capítulo The Livestatus Query Language.
3.2. Acessando Livestatus com Python.
O acesso a partir do Python não precisa de uma ferramenta externa. O exemplo a seguir mostra como enviar uma consulta, recuperar a resposta e analisá-la em uma tabela de Python. Depois de instalar o check_mk, você encontra este programa no diretório / usr / share / doc / check_mk:
4. LQL - O Livestatus Query Language.
LQL - pronunciado "Liquel" como em "líquido" - é um idioma simples para dizer Livestatus quais os dados que deseja e como deve ser formatado. Faz muito o mesmo que o SQL, mas faz isso em outro, de maneira mais simples. Sua sintaxe reflete (mas não é compatível com) o HTTP.
Cada consulta consiste em: Um comando composto pela palavra GET e o nome de uma tabela. Um número arbitrário de linhas de cabeçalho consistindo de uma palavra-chave, dois-pontos e argumentos. Uma linha vazia ou o fim da transmissão (ou seja, o cliente fecha a direção de envio do soquete)
Todas as palavras-chave, incluindo GET, diferenciam maiúsculas de minúsculas As linhas são encerradas por alimentação de linha única (não & lt; CR & gt;). A versão atual do Livestatus implementa as seguintes tabelas: hosts - seus serviços de host Nagios - seus serviços Nagios, juntou-se a todos os dados dos hosts host - você Nagios grupos de atendimento dos grupos de servidores - você Nagios servicegroups grupos de contatos - você Nagios grupos de contato serviços por grupo - todos os serviços agrupados por serviço grupos de serviços por grupo de acolhimento - todos os serviços agrupados por host groups hostsbygroup - todos os hosts agrupados por contatos de grupos de hosts - seus comandos de contatos do Nagios - seus períodos de tempo de comandos definidos do Nagios - definições de período de tempo (apenas o nome e o alias) - todos os tempos de parada programados do host e do serviço com dados de hosts e serviços. comentários - todos os logs de comentários de host e serviço - um acesso transparente aos status de logs do nagios (incluindo arquivos arquivados) - status geral e informações de status. Esta tabela contém exatamente um conjunto de dados. colunas - uma lista completa de todas as tabelas e colunas disponíveis via Livestatus, incluindo descrições! statehist - 1.2.1i2 estatísticas sla para hosts e serviços, juntou-se aos dados dos hosts, serviços e log.
Como em um banco de dados SQL, todas as tabelas consistem em várias colunas. Se você consulta a tabela sem qualquer parâmetro, você recupera todas as colunas disponíveis em ordem alfabética. A primeira linha da resposta contém os nomes das colunas. Observe que as colunas disponíveis vão mudar de versão para versão. Assim, você não deve depender de uma determinada ordem das colunas!
Exemplo: Recuperar todos os contatos:
4.1. Selecionando as colunas para recuperar.
Quando você escreve um aplicativo usando Livestatus, você provavelmente precisa da informação apenas das colunas selecionadas. Adicione as colunas do cabeçalho para selecionar as colunas a serem recuperadas. Isso também define a ordem das colunas na resposta. O exemplo a seguir recupera apenas o nome e alias das colunas:
Se você quiser testar isso com o Unixcat, uma maneira simples é colocar sua consulta em uma consulta de arquivo de texto e ler isso ao usar o & lt; :
Como você pode ter notado neste exemplo: se você usar Colunas: então, nenhum cabeçalho de coluna será exibido. Você não precisa deles - como você os especificou. Isso torna a análise mais simples.
4.2. Filtros.
Um conceito importante do Livestatus é a sua capacidade de filtrar dados para você. Isso não é apenas mais conveniente do que apenas recuperar todos os dados e selecionar as linhas relevantes. Também é muito mais rápido. Lembre-se de que Livestatus tem acesso direto a todas as estruturas de dados internas de Nagios e pode acessá-las com a velocidade de C. nativo.
Os filtros são adicionados usando Filter: headers. Esse cabeçalho tem três argumentos: um nome de coluna, um operador e um valor de referência - todos separados por espaços. O valor de referência - sendo o último na linha - pode conter espaços. Exemplo:
Esta consulta obtém todos os serviços com o estado atual 2 (crítico). Se você adicionar mais Filtro: cabeçalhos, você verá apenas dados que passem todo o seu filtro. O próximo exemplo exibe todos os serviços críticos que estão atualmente dentro do período de notificação:
Estão disponíveis os seguintes oito operadores:
Algumas notas: os operadores.
4.3. Correspondência de expressões regulares.
4.4. Listas correspondentes.
Algumas colunas não contêm números ou textos, mas listas de objetos. Um exemplo para isso é a coluna contatos de hosts ou serviços que contém todos os contatos atribuídos ao objeto de dados. Os operadores disponíveis em colunas de valores de lista são:
Exemplo: devolver informações sobre serviços em que "harri" é um dos contatos designados:
Outro exemplo: Retorna o nome de todos os hosts que não têm pais:
Existe um caso especial quando a filtragem é feita nos membros ou membros com as colunas de estado da tabela de grupos de serviços: o valor a ser combinado deve ter o nome do host do formulário | Descrição do Serviço .
4.5. Correspondência de listas de atributos.
A versão 1.1.4 do Livestatus oferece acesso à lista de atributos modificados de hosts, serviços e contatos. Desta forma, você pode consultar quais atributos foram alterados dinamicamente pelo usuário e, portanto, diferem dos atributos configurados nos arquivos de objetos Nagios.
Essas novas colunas vêm em duas variantes: modified_attributes e modified_attributes_list. A primeira variante produz um número inteiro representando uma combinação bit a bit dos números internos do Nagios. A segunda variante exibe uma lista de nomes de atributos, como notifications_enabled ou active_checks_enabled. Quando você define um filtro, ambas as variantes de coluna são tratadas exatamente da mesma maneira, e ambas permitem usar o número ou a representação da lista separada por vírgulas.
Exemplo 1: Encontre todos os hosts com atributos modificados:
Exemplo 2: Localizar hosts onde a notificação foi ativamente desativada:
Exemplo 3: Localizar hosts onde as verificações ativas ou passivas foram modificadas:
4.6. Combinando filtros com e, ou com a negação.
Por padrão, um conjunto de dados deve passar todos os filtros para serem exibidos. Alternativamente, você pode combinar uma série de filtros com uma operação "ou" lógica usando o cabeçalho Ou:. Este cabeçalho leva um número inteiro X como argumento e combina os últimos filtros X em um novo filtro usando uma operação "ou". O exemplo a seguir seleciona todos os serviços que estão no estado 1 ou no estado 3:
O próximo exemplo mostra todos os serviços não OK que estão dentro de um tempo de inatividade programado ou que estão em um host com um tempo de inatividade programado:
Também é possível combinar filtros com uma operação And. Isso só é necessário se você deseja agrupar os filtros antes de "ou" fazer-os. Se, por exemplo, você quiser obter todos os serviços que sejam críticos e reconhecidos ou OK, é assim como fazê-lo:
O And: 2-header combina os dois primeiros filtros com um novo filtro, que é então "ou" ed com o terceiro filtro.
Na versão 1.1.11i2, o novo cabeçalho Negado: foi introduzido. Isso bloqueia logicamente o filtro mais recente. O exemplo a seguir exibe todos os hosts que não têm um nem um no seu nome:
5. Estatísticas e Contagens.
5.1. Por que contar?
SQL tem uma declaração "SELECT COUNT (*) FROM". O que conta o número de linhas que correspondem a determinados critérios. Estatísticas do LQL: - Header permite algo semelhante. Além disso, ele pode recuperar várias contagens ao mesmo tempo.
As estatísticas: - Header tem a mesma sintaxe do filtro: mas outro significado: em vez de filtrar os objetos que os conta. Assim que pelo menos um Stats: cabeçalho é usado, nenhum dado é exibido mais. Em vez disso, uma única linha de dados é emitida com uma coluna para cada Estatística: mostrando o número de linhas que correspondem aos critérios.
O exemplo a seguir exibe o número de serviços que estão OK, WARN, CRIT ou UNKNOWN:
Um exemplo de saída parece assim:
Você deseja restringir a saída aos serviços aos quais o contato harri é atribuído? Não há problema, basta adicionar um filtro: cabeçalho:
5.2. Combinando com e / ou.
Assim como os cabeçalhos de filtro, os cabeçalhos de estatísticas podem ser combinados com e / ou ou operações. Importante saber é que eles formam sua própria pilha. Você combina com StatsAnd e StatsOr. Aqui está uma consulta um pouco mais complexa que verifica todos os serviços das janelas do grupo de serviços que estão dentro do período de notificação e não estão dentro de um tempo de inatividade do host ou do serviço. Calcula sete contagens: a quantidade de serviços com o estado difícil OK O número de serviços não reconhecidos em estado difícil AVISO O número de serviços reconhecidos em estado difícil AVISO O número de serviços não reconhecidos em estado difícil CRÍTICO O número de serviços reconhecidos em estado difícil CRÍTICO O número de serviços não reconhecidos em estado difícil DESCONHECIDO O número de serviços reconhecidos em estado difícil DESCONHECIDO.
Na versão 1.1.11i2, o novo cabeçalho StatsNegate: foi introduzido. Não requer argumentos e lógicamente anula as estatísticas mais recentes - Filtro.
5.3. Agrupamento.
Deixar Livestatus contar itens é bom e rápido. Mas, em nossos exemplos até agora, a resposta foi restrita a uma linha de números para um conjunto de filtros predefinido. Em algumas situações, você deseja obter estatísticas para cada objeto de um determinado conjunto. Você pode querer exibir uma lista de hosts e, para cada um desses hosts, o número de serviços que estão OK, WARN, CRIT ou UNKNOWN.
Em tais situações, você pode adicionar o cabeçalho Colunas: à sua consulta. Existe uma noção simples e ainda poderosa por trás disso: você especifica uma lista de colunas da sua tabela. As estatísticas são computadas e exibidas separadamente para cada combinação de valores diferentes dessas colunas.
A seguinte consulta conta o número de serviços nos vários estados para cada host na janela do grupo de host:
O resultado é assim:
Como você pode ver, uma coluna adicional foi prépendida para o resultado que contém o valor da coluna do grupo. Aqui está outro exemplo que conta o número total de serviços agrupados pelo comando de verificação (a expressão do filtro fofo é sempre verdadeira, então cada serviço é contado).
Aqui está um exemplo de saída dessa consulta:
Um terceiro exemplo mostra outra maneira de contar o número total de serviços agrupados por seus estados sem um cabeçalho estatístico explícito para cada estado:
Nesse exemplo, nenhum dos serviços estava no estado DESCONHECIDO. Por isso, nenhuma contagem para esse estado foi exibida.
Uma última nota sobre o agrupamento: a implementação atual permite apenas colunas dos tipos de seqüência de caracteres ou para serem usadas para o agrupamento. Além disso, você está limitado a uma coluna de grupo.
Observação: antes da versão 1.1.10 havia o cabeçalho StatsGroupBy: em vez de Colunas:. Esse cabeçalho está obsoleto, embora ainda esteja funcionando.
6. Soma, Mínimo, Máximo, Média, Desvio Padrão.
A partir da versão 1.1.2, a Livestatus suporta algumas operações estatísticas de base. Eles permitem, por exemplo, consultar o tempo médio de execução da verificação ou o desvio padrão da latência da verificação de todas as verificações.
Essas operações estão usando uma das palavras-chave soma, min, max, avg, std, suminv ou avginv. A consulta a seguir exibe o tempo de execução de verificação mínimo, máximo e médio de todas as verificações de serviço no estado OK:
Tal como acontece com os cabeçalhos de status "normais", a saída pode ser agrupada por uma coluna, por exemplo pelo nome_do_ host:
Na versão 1.1.13i1, apresentamos as funções de agregação fornecidas e avginv. Eles calculam a soma ou a média do inverso dos valores. Por exemplo, o inverso do check_interval de um serviço é o número de vezes que é verificado por minuto. O fornecimento de todos os serviços é o número total de cheques que devem ser executados por minuto, se nenhuma verificação estiver sendo adiada.
6.1. Dados de desempenho.
A partir da versão 1.1.11i2, o MK Livestatus agora suporta agregação de dados de desempenho do Nagios. Os dados de desempenho são informações adicionais de saída por checagens, formatadas como uma string como usuário = 6.934 ;;;; sistema = 6.244 ;;;; wait = 0,890 ;;;; . Se você criar uma consulta de estatísticas usando soma, min, max, avg ou std em vários serviços com dados de desempenho compatíveis, o Livestatus agora agregará esses valores a uma nova cadeia de dados de desempenho. Veja os seguintes exemplos. Primeiro, uma consulta de dois serviços sem agregação:
Vamos supor que ele produz a seguinte saída:
Aqui está a mesma consulta, mas agregando os dados usando a média:
Este é o resultado:
7. Formatação de saída e codificação de caracteres.
O Livestatus suporta os formatos de saída CSV, JSON e Python, sendo o CSV o padrão.
7.1. Saída CSV.
A saída CSV vem em dois sabores: csv (minúsculas) e CSV (maiúsculas). Por motivos de compatibilidade reversa, a variante em minúsculas é a padrão, mas tem algumas peculiaridades. A recomendação é usar a variável de maiúsculas e, quando você realmente precisa de mais estrutura em seus dados. Você está muito melhor com JSON ou Python.
saída csv (quebrada)
Os conjuntos de dados são separados por Linefeeds (ASCII 10), os campos são separados por ponto-e-vírgula (ASCII 59), os elementos da lista (como nos contatos) são separados por vírgulas (ASCII 44) e as combinações do nome do host e a descrição do serviço são separadas por um símbolo de pipe (ASCII 124).
Para evitar problemas com o ponto e vírgula do separador de campo padrão que aparecem em valores (como dados de desempenho), é possível substituir os caracteres separadores por outros símbolos. Isso é feito especificando quatro números inteiros após o cabeçalho Separadores :. Cada um desses é o código ASCII de um separador em decimal. Os quatro números significam:
O separador de conjunto de dados (padrão é 10: alimentação de linha) O separador de coluna (padrão é 59: ponto e vírgula) O separador para listas como contatos na tabela de hosts (padrão é 44: vírgula) O separador para hosts e serviços em listas de serviço (padrão é 124: barra vertical)
É possível até mesmo usar caracteres não imprimíveis como separadores. O exemplo a seguir usa bytes com os valores 0, 1, 2 e 3 como separadores:
Saída CSV.
Este é o formato "real" CSV (veja RFC 4180), que é semelhante à variante minúscula acima, mas com citação correta e CR / LF como separador de conjunto de dados. Por causa da citação, não é necessário o separador: cabeçalho, portanto, é ignorado para este formato.
7.2. Saída JSON.
Você pode obter sua saída no formato JSON se você adicionar o cabeçalho OutputFormat: json, como no exemplo a seguir:
Como o CSV, o JSON é um formato baseado em texto, e é um código JavaScript válido. Para evitar a redundância e manter a sobrecarga o mais baixo possível, a saída não é formatada como uma lista de objetos (com pares de chave / valor), mas como uma lista de listas (arrays em JSON). Este é o formato recomendado em geral, pois facilita a manipulação de dados estruturados, e os analisadores JSON estão disponíveis basicamente em todas as linguagens de programação.
7.3. Saída de Python.
O formato Python é muito semelhante ao formato JSON, mas não 100% compatível. Há uma pequena diferença em prefixos de string e como os personagens são escapados, e isso é mesmo diferente em Python 2 e Python 3. Portanto, dois formatos Pythonic são oferecidos: python para Python 2 e python3 para, bem, Python 3. Você pode diretamente eval () a saída do Python, mas esteja ciente dos potenciais problemas de segurança. Em caso de dúvida, use JSON e json. loads do módulo json padrão.
7.4. Codificação de caracteres.
A saída do Livestatus na maioria dos casos é originária de arquivos de configuração do Nagios (a configuração do objeto). O Nagios não impõe quaisquer restrições sobre como esses arquivos devem ser codificados (UTF-8, Latin-1, etc.). Se você selecionar a saída CSV, Livestatus simplesmente retorna os dados, pois está contido nos arquivos de configuração - com a mesma codificação.
Ao usar JSON ou Python - no entanto - caracteres não-ASCII precisam ser escapados e codificados corretamente. Até a versão 1.1.11i1, o Livestatus detecta automaticamente as seqüências UTF-8 de 2 bytes e assume que todos os outros caracteres não-ASCII são codificados em Latin-1. Embora isso funcione bem para as línguas ocidentais e, até certo ponto, "detecta automaticamente" a codificação, não suporta idiomas que usem outros caracteres, em seguida, aqueles usados ​​no latim-1. Mesmo o & euro; - Symbol não está funcionando.
A partir da versão 1.1.11i2, o comportamento do Livestatus é configurável com a opção data_encoding e padrões agora para a codificação UTF-8. Três configurações diferentes são válidas:
7.5. Cabeçalhos de coluna.
Por padrão, se não houver cabeçalho de colunas na sua consulta, o MK Livestatus exibe os nomes de todas as colunas como uma primeira linha da saída. Com o cabeçalho OutputColumns, você pode ativar ou desativar cabeçalhos de coluna explicitamente. A saída para a seguinte consulta incluirá cabeçalhos de coluna:
7.6. Limitando o número de conjuntos de dados.
O cabeçalho Limits permite limitar o número de conjuntos de dados a serem exibidos. Uma vez que o MK Livestatus atualmente não suporta a classificação, você terá que viver com a classificação natural de objetos Nagios-interna. Os hosts, por exemplo, são classificados de acordo com seus nomes de host - assim como nos CGIs padrão. O exemplo a seguir exibirá apenas os 10 primeiros hosts:
Por favor, note que o cabeçalho Limit também é aplicado quando faz Stats. Não tenho certeza se há algum uso para isso, mas essa é a maneira como o MK Livestatus se comporta. O exemplo a seguir irá contar quantos dos 10 primeiros hosts estão em funcionamento:
Se estiver usando filtros, o Limit - header limita o número de conjuntos de dados que estão realmente sendo exibidos. A consulta a seguir exibe os primeiros 10 hosts que estão desativados:
8. Autorização.
Desde a versão 1.1.3, o Livestatus oferece suporte a desenvolvedores addon, ajudando a implementar a autorização. Você pode deixar Livestatus decidir se um certo contato pode ver dados ou não. Isso é muito simples de usar. Tudo o que você precisa fazer é adicionar um cabeçalho AuthUser à sua consulta com o nome de um contato Nagios como único argumento. Se você fizer isso, a Livestatus só exibirá os dados para os quais o nome é um contato - diretamente ou por meio de um grupo de contato. Exemplo:
Em certos casos, seria possível substituir AuthUser por um cabeçalho de filtro. Mas isso não funciona (precisamente) em todas as situações.
8.1. Configuração.
Se o seu addon usa o AuthUser, o administrador tem uma maneira de configurar os detalhes de autenticação via nagios. cfg - e assim pode fazê-lo uniformemente em todos os addons usando o Livestatus. Atualmente estão disponíveis duas opções de configuração. Ambos podem ser definidos como rígidos ou soltos:
Observe que o Nagios faz todos os serviços que não possuem nenhum contato herdar todos os contatos do host - independentemente de esta opção estar definida como rígida ou solta.
8.2. Tabelas que suportam AuthUser.
As tabelas a seguir suportam o cabeçalho AuthUser (outros simplesmente ignoram): hosts, serviços, grupos de hosts, grupos de serviços e log. O log - table aplica o AuthUser apenas às entradas das classes de registro 1 (alertas de host e de serviço), 3 (notificações) e 4 (cheques passivos). Todas as outras classes não são afetadas.
8.3. Limitações.
Atualmente, o AuthUser - header apenas controla quais linhas de dados são exibidas e não tem impacto nas colunas da lista, como a coluna de grupos nos serviços da tabela. Isso significa que esta coluna também lista grupos de serviços para o qual o contato pode não ser um contato. Isso pode ser alterado em uma versão futura do Livestatus.
Começando com a versão 1.1.3 Livestatus possui uma característica nova e ainda experimental: Waiting. Waiting permite aos desenvolvedores de addons atrasar a execução de uma consulta até uma certa condição se tornar verdadeira ou um evento Nagios acontecer. Isso permite a implementação de uma nova classe de recursos em addons, por exemplo:
Uma atualização imediata de uma exibição de status assim que o status de qualquer um ou um objeto Nagios específico muda. Um ticker de arquivo de log que mostra novas mensagens de log imediatamente. Um botão de ação para reprogramar a próxima verificação de um serviço que exibe o serviço mais cedo do que depois de ter sido verificado.
Tudo o que pode ser implementado sem polling - e de uma maneira muito simples. Tudo o que você precisa fazer é criar novos cabeçalhos de consulta:
É permitido especificar cabeçalhos de condição múltipla: todas as condições são combinadas com um booleano e (assim como com o cabeçalho do filtro).
Os seguintes gatilhos estão disponíveis para o WaitTrigger - Header: verificação - um serviço ou verificação de host foi executado estado - o estado de um host ou serviço mudou log - uma nova mensagem foi registrada no tempo de inatividade nagios. log - um tempo de inatividade foi definir ou remover comentário - um comando foi definido ou removido - um comando externo foi executado programa - uma alteração em uma configuração de programa global, como enable_notifications tudo - qualquer um dos eventos superiores aconteceu (este é o padrão)
9.1. Exemplos.
Recupere mensagens de log desde um determinado carimbo de data / hora, mas espere até que apareça uma nova mensagem de registro:
O mesmo, mas não espere mais de 2 segundos:
Recupere os dados completos sobre o host xabc123, mas aguarde até que seu estado seja crítico:
Obtenha dados sobre o serviço Memória usada no host xabc123 logo que tenha sido verificada algum tempo após 1265062900:
10. Compensar as diferenças de fuso horário.
Ao fazer uma monitoração distribuída multinacional com Livestatus, você pode ter que lidar com situações em que seus servidores de monitoramento estão sendo executados em diferentes fusos horários. Em uma configuração comum, todos os servidores terão o mesmo horário do sistema, mas diferentes fuso horários configurados. Você pode verificar isso ligando para cada servidor de monitoramento:
Este comando deve produzir o mesmo valor em todos os servidores. Caso contrário, você provavelmente configurou seu sistema em um fuso horário incorreto. MK Livestatus pode ajudar a compensar a diferença horária em tais situações. Se você adicionar o cabeçalho.
Para sua consulta com seu tempo local atual (a saída da data +% s) como argumento, o Livestatus comparará seu tempo local com o do chamador e converterá todas as marcas de data / hora em conformidade.
Por favor, note que Livestatus assume que uma diferença no tempo não é devido à imprecisão do relógio, mas devido a diferenças de fuso horário. O tempo delta calculado para compensação será arredondado para a meia hora mais próxima.
11. Cabeçalho da resposta.
Se o seu pedido não for válido ou algum outro erro aparecer, uma mensagem será impressa no arquivo de log do Nagios. Se você quiser escrever uma API que exiba mensagem de erro para o usuário, você precisa de informações sobre erros como parte da resposta.
Você pode obter esse comportamento usando o cabeçalho ResponseHeader. Pode ser configurado para desligado (padrão) ou para fixo16:
Outros tipos de cabeçalhos de resposta podem ser implementados em futuras versões. O cabeçalho fixo16 tem a vantagem de ter exatamente 16 bytes de comprimento. Isso facilita a programação de uma API. Você pode simplesmente ler em 16 bytes e não precisa procurar uma nova linha ou coisas assim. Aqui está uma sessão de exemplo completa com os cabeçalhos de resposta sendo ativados:
O cabeçalho da resposta fixa16 tem o seguinte formato: Bytes 1-3: código de status Byte 4: um único espaço Byte 5-15: o comprimento da resposta como um número inteiro codificado ASCII, preenchido com espaços Byte 16: um caractere de alimentação de linha (ASCII 10)
Estes são os valores possíveis do código de status:
A resposta contém os dados consultados apenas se o código de status for 200. Em todos os outros casos, a resposta contém a mensagem de erro. Nesse caso, o campo de comprimento fornece o comprimento da mensagem de erro, incluindo a alimentação de linha de saída. Não é codificado em JSON, mesmo que você estabeleça isso no cabeçalho OutputFormat.
12. Mantenha-se vivo (conexões persistentes)
O MK Livestatus permite que você mantenha aberta uma conexão e reutilize-a para vários pedidos. Eu garanto que você precisa adicionar o seguinte cabeçalho:
A Livestatus manterá a conexão aberta depois de enviar sua resposta e aguardará uma nova consulta nesse caso. Você provavelmente também ativará um cabeçalho de resposta nesse caso, uma vez que somente isso permite que você determine exatamente o comprimento da resposta (sem KeepAlive você pode simplesmente ler até o final do arquivo).
Observe que manter uma conexão permanentemente ocupa recursos dentro do processo Nagios. Na versão atual, o Livestatus é limitado a dez conexões persistentes paralelas. Isso é diferente da maneira como as conexões de banco de dados persistentes são tratadas.
A maneira proposta de usar conexões persistentes em aplicativos da Web é manter a conexão aberta somente durante a solicitação atual e fechá-la após a página de resultado completa ter sido processada. The reason is that bringing up a database connection is a much more costly operation than connecting to MK Livestatus.
13. Access to Logfiles.
Since version 1.1.1 Livestatus provides transparent access to your Nagios logfiles, i. e. nagios. log and the rotated files in archives (you might have defined an alternative directory in nagios. cfg). Livestatus keeps an index over all log files and remembers which period of time is kept in which log file. Please note that Livestatus does not depend on the name of the log files (while Nagios does). This way Livestatus has no problem if the log file rotation interval is changed.
The Livestatus table log is your access to the logfiles. Every log message is represented by one row in that table.
13.1. Performance issues.
If your monitoring system is running for a couple of years, the number of log files and entries can get very large. Each Livestatus query to the table log has the potential of scanning all historic files (although an in-memory cache tries to avoid reading files again and again). It is thus crucial that you use Filter: in order to restrict:
The time interval The log classes in question.
If you set no filter on the column time , then all logfiles will be loaded - regardless of other filters you might have set.
Setting a filter on the column class restricts the types of messages loaded from disk. The following classes are available:
0 - All messages not in any other class 1 - host and service alerts 2 - important program events (program start, etc.) 3 - notifications 4 - passive checks 5 - external commands 6 - initial or current state entries 7 - program state change.
14. RRD Files of PNP4Nagios.
New in 1.1.9i3 : In order to improve the integration between Multisite and PNP4Nagios, Livestatus introduces the new column pnpgraph_present in the tables hosts and services (and all other tables containing host_ or service_ columns). That column can have three possible values:
Livestatus cannot detect the base directory to your RRD files automatically, so you need to configure it with the module option pnp_path :
In order to determine Livestatus the availability of the PNP graph it checks for the existance of PNPs. xml file.
A note for OMD users: OMD automatically configures this option correctly in etc/mk-livestatus/nagios. cfg . You need at least a daily snapshot of 2018-12-17 or later for using the new feature.
15. Expansion of macros.
Nagios allows you to embed macros within your configuration. For example it is usual to embed $HOSTNAME$ and $SERVICEDESC$ into your action_url or notes_url when configuring links to a graphing tool.
As of version 1.1.1 Livestatus supports expansion of macros in several columns of the table hosts and services . Those columns - for example notes_url_expanded - bear the same name as the unexpanded columns but with _expanded suffixed.
Since macro expansion is very complex in Nagios. And unfortunately the Nagios code for that is not thread safe, so Livestatus has its own implementation of macros, which does not support all features of Nagios, but (nearly) all that are needed for visualization addons. Livestatus supports the following macros:
for hosts and services: HOSTNAME , HOSTDISPLAYNAME , HOSTALIAS , HOSTADDRESS , HOSTOUTPUT , LONGHOSTOUTPUT , HOSTPERFDATA , HOSTCHECKCOMMAND for services: SERVICEDESC , SERVICEDISPLAYNAME , SERVICEOUTPUT , LONGSERVICEOUTPUT , SERVICEPERFDATA , SERVICECHECKCOMMAND all custom macros on hosts and services (beginning with _HOST or _SERVICE ) all $USER. $ macros.
16. Remote access to Livestatus via SSH or xinetd.
16.1. Livestatus via SSH.
Livestatus current does not provide a TCP socket. Another (and more secure) way for remote accessing the unix socket is using SSH. The following example sends a query via SSH. The only priviledge the remote user needs, is write access to the unix socket:
16.2. Livestatus via xinetd.
Using xinetd and unixcat you can bind the socket of Livestatus to a TCP socket. Here is an example configuration for xinetd:
You can access your socket for example with netcat :
17. Timeouts.
In version 1.1.7i3 the handling of timeouts has changed. There are now two configurable timeouts which protect Livestatus from broken clients hanging on the line for ever (remember that the maximum number of parallel connections is configurable but limited):
idle_timeout - Limits the time Livestatus waits for a (the next) query query_timeout - Limits the time a query needs to be read.
A Livestatus connection has two states: either Livestatus is waiting for a query. This is the case just after the client has connected, but also in KeepAlive - mode after the response has been sent. The client has now at most idle_timeout ms for starting the next query. The default is set to 300000 (300 seconds, i. e. 5 minutes). If a client is idle for more then that, Livestatus simply closes the connection.
As soon as the first byte of a query has been read, Livestatus enters the state "reading query" and uses a much shorter timeout: the query_timeout . Its default value is 10000 (10 secs). If the client does not complete the query within this time, the client is regarded dead and the connection is closed.
Both timeout values can be configured by Nagios module options in nagios. cfg . A timeout can be disable by setting its value to 0 . But be warned: Broken clients can hang connections for ever and thus block Livestatus threads.
18. Sending commands via Livestatus.
MK Livestatus supports sending Nagios commands. This is very similar to the Nagios command pipe, but very useful for accessing a Nagios instance via a remote connection.
You send commands via the basic request COMMAND followed by a space and the command line in exactly the same syntax as needed for the Nagios pipe. No further header fields are required nor allowed.
Livestatus keeps the connection open after a command and waits for further commands or GET - requests. It behaves like GET with KeepAlive: set to yes . That way you can send a bunch of commands in one connection - just as with the pipe. Here is an example of sending a command from the shell via unicat :
Just as with GET , a query is terminated either by closing the connection or by sending a newline. COMMAND automatically implies keep alive and behave like GET when KeepAlive is set to on . That way you can mix GET and COMMAND quries in one connection.
19. Stability and Performance.
19.1. Estabilidade.
While early versions of MK Livestatus experienced some stability issues - not unusual for evolving software - nowadays it can be considered rock solid. There are no known problems with performance, crashes or a hanging Nagios, as long as two important requirements are fullfilled: Environment macros have to be disabled in nagios. cfg . This is done with:
19.2. Performance.
Livestatus behaves with respect to your CPU and disk ressources. It doesn't do any disk IO at all, in fact - as long as the table log is not accessed, which needs read access to the Nagios' log files. CPU is only consumed during actual and queries and even for large queries we rather speek of micro seconds then of milli seconds of CPU usage. Furthermore, Livestatus does not block Nagios during the execution of a query but is running totally in parallel - and scales to all available CPU cores if neccessary. 1.1.9i3 Timeperiod transitions">
20. 1.1.9i3 Timeperiod transitions.
Version 1.1.9i3 introduces a new little feature, that does not really have something to do with status queries but is very helpful for creating availability reports and was easy to implement in Livestatus (due to its timeperiod cache).
Each time a timeperiod changes from active to not active or vice versa, an entry in the Nagios logfile is being created. At start of Nagios the initial states of all timeperiods are also logged. This looks like this:
When a transition occurs one line is logged (here the state changed from 1 (in) to 0 (out).
With that information, it is later possible to determine, which timeperiods were active when an alert happened. That way you can make availability reports reflect only certain time periods.
21. Host and Service Availability.
21.1. Introdução.
Version 1.2.1i2 introduces the new table statehist which supports availability queries - providing statistical information for hosts and service. Beside the state information, this table returns duration information regarding the length of the state. In addition the duration percentage in respect to the query timeframe can be returned.
Each change creates an output line with the respective duration. Additional columns show the part (percentage) of this duration in comparison to the queried timeframe. To get the overall percentage of a specific state you can use the Stats: header to accumulate the percentage fields of multiple lines.
21.2. Absence of host and services.
To identify the absence of host and services within the queried timeperiod correctly it is necessary to set the following parameter.
Setting this parameter to 1 results that the initial state of each host and service is logged during the programs startup. By evaluating each startup it is possible to detect if a host or service is no longer monitored by the system. It is even possible to detect if this host or service was temporarily removed from monitoring for a specific time. The absence of a host or service is reflected in the output line within the state column as -1 (UNMONITORED)
The setting log_initial_states=1 is the default parameter as of version 1.2.1i2.
Disabling this parameter lead to less logfile entries on the programs startup, but limits the correct detection of the UNMONITORED state.
21.3. Table statehist.
Querying the table statehist results in an output which shows the a hosts/services states as mentioned above and in addition how long this host/service resided in this state.
A query always requires a filter for the start time. Otherwise livestatus would parse all available logfiles from the beginning, which might add up to several hundred megabytes.
Outputs a list where the state of this service has changed joined with the duration information.
By using the Stats: header these lines can be accumulated and allows the output of distinct stats duration and their duration_part in respect to the queried timeframe.
Using the columns duration_part_ok, duration_part_warning, duration_part_critical allows to output the entire state information within a single line.
Converting the part values into percentages the SLA information for this service is 70.1% OK 3.8% WARNING 26.1% CRITICAL.

Event_broker_options nagios

by ffrcaraballo » Mon Dec 05, 2018 12:57 pm.
# EVENT BROKER OPTIONS.
# Controls what (if any) data gets sent to the event broker.
# Values: 0 = Broker nothing.
# -1 = Broker everything.
# EVENT BROKER MODULE(S)
# This directive is used to specify an event broker module that should.
#broker_module=/somewhere/module2.o arg1 arg2=3 debug=0.
# 64 = Event broker.
# EVENT BROKER OPTIONS.
# Controls what (if any) data gets sent to the event broker.
# Values: 0 = Broker nothing.
# -1 = Broker everything.
# EVENT BROKER MODULE(S)
# This directive is used to specify an event broker module that should.
#broker_module=/somewhere/module2.o arg1 arg2=3 debug=0.
# 64 = Event broker.
#NDOUtils Broker Module.
Re: Nagios with NDOUtils.
by tgriep » Mon Dec 05, 2018 3:29 pm.
Edit that file and add this line to it.
Code: Select all broker_module=/usr/local/nagios/bin/ndomod. o config_file=/usr/local/nagios/etc/ndomod. cfg.
Then restart the nagios daemon by running.
Code: Select all service nagios restart.
Try that and see if the MYSQL database starts to populate with data.
Re: Nagios with NDOUtils.
Re: Nagios with NDOUtils.
by tgriep » Tue Dec 06, 2018 12:55 pm.
Who is online.
Users browsing this forum: Bing [Bot] and 24 guests.

Event_broker_options nagios

Pull requests 1.
Join GitHub today.
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Clone com HTTPS.
Use o Git ou o check-out com o SVN usando o URL da web.
The Prometheus Nagios exporter reads status and performance data from nagios plugins via the MK Livestatus Nagios plugin and publishes this in a form that can be scrapped by Prometheus.
Setup is as simple as installing the livestatus module and then running the nagios_exporter. py service.
Restart Nagios, and start the exporter:
It should then be possible to visit:
Every metric is prefixed with nagios_ , following the metric naming best practices. The prefix is followed by the name of the Nagios check command, such as nagios_check_load_ . The metric name suffix comes from various Nagios status names. For example, a load service check for localhost would include the following metrics:
Every metric is also labeled with the hostname and service description.
Performance data is plugin-specific. Though there is a common format that most plugins follow. Performance data follows plugin output starting with | . Typically, the format is a set of key=value1[;value2]+ strings. Por exemplo:
By default, nagios-exporter only parses the first value of performance data for every key. The default field name is 'value'. And, the key is always added as a metric label. So, for example, the default metric output for the above performance data would be:
More specific names can be assigned to each value position of particular check plugins using the --data_names flag. Por exemplo:
So, instead of only parsing the first value and using the default name, now the metric output for the original example will include three values each named and corresponding to the respective value in the raw perf data:
&cópia de; 2018 GitHub, Inc. Termos Privacidade Segurança Status Ajuda.
You can't perform that action at this time.
Você fez login com outra guia ou janela. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Main Configuration File Options.
When creating and/or editing configuration files, keep the following in mind:
Lines that start with a '#' character are taken to be comments and are not processed Variables names must begin at the start of the line - no white space is allowed before the name Variable names are case-sensitive.
Tip: A sample main configuration file ( /usr/local/nagios/etc/nagios. cfg ) is installed for you when you follow the quickstart installation guide.
The main configuration file is usually named nagios. cfg and located in the /usr/local/nagios/etc/ directory.
Below you will find descriptions of each main Nagios configuration file option.
This variable specifies where Nagios should create its main log file. This should be the first variable that you define in your configuration file, as Nagios will try to write errors that it finds in the rest of your configuration data to this file. If you have log rotation enabled, this file will automatically be rotated every hour, day, week, or month.
This directive is used to specify an object configuration file containing object definitions that Nagios should use for monitoring. Object configuration files contain definitions for hosts, host groups, contacts, contact groups, services, commands, etc. You can seperate your configuration information into several files and specify multiple cfg_file= statements to have each of them processed.
This directive is used to specify a directory which contains object configuration files that Nagios should use for monitoring. All files in the directory with a. cfg extension are processed as object config files. Additionally, Nagios will recursively process all config files in subdirectories of the directory you specify here. You can seperate your configuration files into different directories and specify multiple cfg_dir= statements to have all config files in each directory processed.
This directive is used to specify a file in which a cached copy of object definitions should be stored. The cache file is (re)created every time Nagios is (re)started and is used by the CGIs. It is intended to speed up config file caching in the CGIs and allow you to edit the source object config files while Nagios is running without affecting the output displayed in the CGIs.
This directive is used to specify a file in which a pre-processed, pre-cached copy of object definitions should be stored. This file can be used to drastically improve startup times in large/complex Nagios installations. Read more information on how to speed up start times here.
This is used to specify an optional resource file that can contain $USERn$ macro definitions. $USERn$ macros are useful for storing usernames, passwords, and items commonly used in command definitions (like directory paths). The CGIs will not attempt to read resource files, so you can set restrictive permissions (600 or 660) on them to protect sensitive information. You can include multiple resource files by adding multiple resource_file statements to the main config file - Nagios will process them all. See the sample resource. cfg file in the sample-config/ subdirectory of the Nagios distribution for an example of how to define $USERn$ macros.
This is a temporary file that Nagios periodically creates to use when updating comment data, status data, etc. The file is deleted when it is no longer needed.
This is a directory that Nagios can use as scratch space for creating temporary files used during the monitoring process. You should run tmpwatch , or a similiar utility, on this directory occassionally to delete files older than 24 hours.
This is the file that Nagios uses to store the current status, comment, and downtime information. This file is used by the CGIs so that current monitoring status can be reported via a web interface. The CGIs must have read access to this file in order to function properly. This file is deleted every time Nagios stops and recreated when it starts.
This setting determines how often (in seconds) that Nagios will update status data in the status file. The minimum update interval is 1 second.
This is used to set the effective user that the Nagios process should run as. After initial program startup and before starting to monitor anything, Nagios will drop its effective privileges and run as this user. You may specify either a username or a UID.
This is used to set the effective group that the Nagios process should run as. After initial program startup and before starting to monitor anything, Nagios will drop its effective privileges and run as this group. You may specify either a groupname or a GID.
This option determines whether or not Nagios will send out notifications when it initially (re)starts. If this option is disabled, Nagios will not send out notifications for any host or service. Note: If you have state retention enabled, Nagios will ignore this setting when it (re)starts and use the last known setting for this option (as stored in the state retention file), unless you disable the use_retained_program_state option. If you want to change this option when state retention is active (and the use_retained_program_state is enabled), you'll have to use the appropriate external command or change it via the web interface. Values are as follows:
0 = Disable notifications 1 = Enable notifications (default)
This option determines whether or not Nagios will execute service checks when it initially (re)starts. If this option is disabled, Nagios will not actively execute any service checks and will remain in a sort of "sleep" mode (it can still accept passive checks unless you've disabled them). This option is most often used when configuring backup monitoring servers, as described in the documentation on redundancy, or when setting up a distributed monitoring environment. Note: If you have state retention enabled, Nagios will ignore this setting when it (re)starts and use the last known setting for this option (as stored in the state retention file), unless you disable the use_retained_program_state option. If you want to change this option when state retention is active (and the use_retained_program_state is enabled), you'll have to use the appropriate external command or change it via the web interface. Values are as follows:
0 = Don't execute service checks 1 = Execute service checks (default)
This option determines whether or not Nagios will accept passive service checks when it initially (re)starts. If this option is disabled, Nagios will not accept any passive service checks. Note: If you have state retention enabled, Nagios will ignore this setting when it (re)starts and use the last known setting for this option (as stored in the state retention file), unless you disable the use_retained_program_state option. If you want to change this option when state retention is active (and the use_retained_program_state is enabled), you'll have to use the appropriate external command or change it via the web interface. Values are as follows:
0 = Don't accept passive service checks 1 = Accept passive service checks (default)
This option determines whether or not Nagios will execute on-demand and regularly scheduled host checks when it initially (re)starts. If this option is disabled, Nagios will not actively execute any host checks, although it can still accept passive host checks unless you've disabled them). This option is most often used when configuring backup monitoring servers, as described in the documentation on redundancy, or when setting up a distributed monitoring environment. Note: If you have state retention enabled, Nagios will ignore this setting when it (re)starts and use the last known setting for this option (as stored in the state retention file), unless you disable the use_retained_program_state option. If you want to change this option when state retention is active (and the use_retained_program_state is enabled), you'll have to use the appropriate external command or change it via the web interface. Values are as follows:
0 = Don't execute host checks 1 = Execute host checks (default)
This option determines whether or not Nagios will accept passive host checks when it initially (re)starts. If this option is disabled, Nagios will not accept any passive host checks. Note: If you have state retention enabled, Nagios will ignore this setting when it (re)starts and use the last known setting for this option (as stored in the state retention file), unless you disable the use_retained_program_state option. If you want to change this option when state retention is active (and the use_retained_program_state is enabled), you'll have to use the appropriate external command or change it via the web interface. Values are as follows:
0 = Don't accept passive host checks 1 = Accept passive host checks (default)
This option determines whether or not Nagios will run event handlers when it initially (re)starts. If this option is disabled, Nagios will not run any host or service event handlers. Note: If you have state retention enabled, Nagios will ignore this setting when it (re)starts and use the last known setting for this option (as stored in the state retention file), unless you disable the use_retained_program_state option. If you want to change this option when state retention is active (and the use_retained_program_state is enabled), you'll have to use the appropriate external command or change it via the web interface. Values are as follows:
0 = Disable event handlers 1 = Enable event handlers (default)
This is the rotation method that you would like Nagios to use for your log file. Values are as follows:
n = None (don't rotate the log - this is the default) h = Hourly (rotate the log at the top of each hour) d = Daily (rotate the log at midnight each day) w = Weekly (rotate the log at midnight on Saturday) m = Monthly (rotate the log at midnight on the last day of the month)
This is the directory where Nagios should place log files that have been rotated. This option is ignored if you choose to not use the log rotation functionality.
This option determines whether or not Nagios will check the command file for commands that should be executed. This option must be enabled if you plan on using the command CGI to issue commands via the web interface. More information on external commands can be found here.
0 = Don't check external commands 1 = Check external commands (default)
If you specify a number with an "s" appended to it (i. e. 30s), this is the number of seconds to wait between external command checks. If you leave off the "s", this is the number of "time units" to wait between external command checks. Unless you've changed the interval_length value (as defined below) from the default value of 60, this number will mean minutes.
Note: By setting this value to -1 , Nagios will check for external commands as often as possible. Each time Nagios checks for external commands it will read and process all commands present in the command file before continuing on with its other duties. More information on external commands can be found here.
This is the file that Nagios will check for external commands to process. The command CGI writes commands to this file. The external command file is implemented as a named pipe (FIFO), which is created when Nagios starts and removed when it shuts down. If the file exists when Nagios starts, the Nagios process will terminate with an error message. More information on external commands can be found here.
Note: This is an advanced feature. This option determines how many buffer slots Nagios will reserve for caching external commands that have been read from the external command file by a worker thread, but have not yet been processed by the main thread of the Nagios deamon. Each slot can hold one external command, so this option essentially determines how many commands can be buffered. For installations where you process a large number of passive checks (e. g. distributed setups), you may need to increase this number. You should consider using MRTG to graph Nagios' usage of external command buffers. You can read more on how to configure graphing here.
This option determines whether Nagios will automatically check to see if new updates (releases) are available. It is recommend that you enable this option to ensure that you stay on top of the latest critical patches to Nagios. Nagios is critical to you - make sure you keep it in good shape. Nagios will check once a day for new updates. Data collected by Nagios Enterprises from the update check is processed in accordance with our privacy policy - see api. nagios for details.
This option deterines what data Nagios will send to api. nagios when it checks for updates. By default, Nagios will send information on the current version of Nagios you have installed, as well as an indicator as to whether this was a new installation or not. Nagios Enterprises uses this data to determine the number of users running specific version of Nagios. Enable this option if you do not wish for this information to be sent.
This option specifies the location of the lock file that Nagios should create when it runs as a daemon (when started with the - d command line argument). This file contains the process id (PID) number of the running Nagios process.
This option determines whether or not Nagios will retain state information for hosts and services between program restarts. If you enable this option, you should supply a value for the state_retention_file variable. When enabled, Nagios will save all state information for hosts and service before it shuts down (or restarts) and will read in previously saved state information when it starts up again.
0 = Don't retain state information 1 = Retain state information (default)
This is the file that Nagios will use for storing status, downtime, and comment information before it shuts down. When Nagios is restarted it will use the information stored in this file for setting the initial states of services and hosts before it starts monitoring anything. In order to make Nagios retain state information between program restarts, you must enable the retain_state_information option.
This setting determines how often (in minutes) that Nagios will automatically save retention data during normal operation. If you set this value to 0, Nagios will not save retention data at regular intervals, but it will still save retention data before shutting down or restarting. If you have disabled state retention (with the retain_state_information option), this option has no effect.
This setting determines whether or not Nagios will set various program-wide state variables based on the values saved in the retention file. Some of these program-wide state variables that are normally saved across program restarts if state retention is enabled include the enable_notifications, enable_flap_detection, enable_event_handlers, execute_service_checks, and accept_passive_service_checks options. If you do not have state retention enabled, this option has no effect.
0 = Don't use retained program state 1 = Use retained program state (default)
This setting determines whether or not Nagios will retain scheduling info (next check times) for hosts and services when it restarts. If you are adding a large number (or percentage) of hosts and services, I would recommend disabling this option when you first restart Nagios, as it can adversely skew the spread of initial checks. Otherwise you will probably want to leave it enabled.
0 = Don't use retained scheduling info 1 = Use retained scheduling info (default)
WARNING: This is an advanced feature. You'll need to read the Nagios source code to use this option effectively.
These options determine which host or service attributes are NOT retained across program restarts. The values for these options are a bitwise AND of values specified by the "MODATTR_" definitions in the include/common. h source code file. By default, all host and service attributes are retained.
WARNING: This is an advanced feature. You'll need to read the Nagios source code to use this option effectively.
These options determine which process attributes are NOT retained across program restarts. There are two masks because there are often separate host and service process attributes that can be changed. For example, host checks can be disabled at the program level, while service checks are still enabled. The values for these options are a bitwise AND of values specified by the "MODATTR_" definitions in the include/common. h source code file. By default, all process attributes are retained.
WARNING: This is an advanced feature. You'll need to read the Nagios source code to use this option effectively.
These options determine which contact attributes are NOT retained across program restarts. There are two masks because there are often separate host and service contact attributes that can be changed. The values for these options are a bitwise AND of values specified by the "MODATTR_" definitions in the include/common. h source code file. By default, all process attributes are retained.
This variable determines whether messages are logged to the syslog facility on your local host. Values are as follows:
0 = Don't use syslog facility 1 = Use syslog facility.
This variable determines whether or not notification messages are logged. If you have a lot of contacts or regular service failures your log file will grow relatively quickly. Use this option to keep contact notifications from being logged.
0 = Don't log notifications 1 = Log notifications.
This variable determines whether or not service check retries are logged. Service check retries occur when a service check results in a non-OK state, but you have configured Nagios to retry the service more than once before responding to the error. Services in this situation are considered to be in "soft" states. Logging service check retries is mostly useful when attempting to debug Nagios or test out service event handlers.
0 = Don't log service check retries 1 = Log service check retries.
This variable determines whether or not host check retries are logged. Logging host check retries is mostly useful when attempting to debug Nagios or test out host event handlers.
0 = Don't log host check retries 1 = Log host check retries.
This variable determines whether or not service and host event handlers are logged. Event handlers are optional commands that can be run whenever a service or hosts changes state. Logging event handlers is most useful when debugging Nagios or first trying out your event handler scripts.
0 = Don't log event handlers 1 = Log event handlers.
This variable determines whether or not Nagios will force all initial host and service states to be logged, even if they result in an OK state. Initial service and host states are normally only logged when there is a problem on the first check. Enabling this option is useful if you are using an application that scans the log file to determine long-term state statistics for services and hosts.
0 = Don't log initial states (default) 1 = Log initial states.
This variable determines whether or not Nagios will log external commands that it receives from the external command file. Note: This option does not control whether or not passive service checks (which are a type of external command) get logged. To enable or disable logging of passive checks, use the log_passive_checks option.
0 = Don't log external commands 1 = Log external commands (default)
This variable determines whether or not Nagios will log passive host and service checks that it receives from the external command file. If you are setting up a distributed monitoring environment or plan on handling a large number of passive checks on a regular basis, you may wish to disable this option so your log file doesn't get too large.
0 = Don't log passive checks 1 = Log passive checks (default)
This option allows you to specify a host event handler command that is to be run for every host state change. The global event handler is executed immediately prior to the event handler that you have optionally specified in each host definition. The command argument is the short name of a command that you define in your object configuration file. The maximum amount of time that this command can run is controlled by the event_handler_timeout option. More information on event handlers can be found here.
This option allows you to specify a service event handler command that is to be run for every service state change. The global event handler is executed immediately prior to the event handler that you have optionally specified in each service definition. The command argument is the short name of a command that you define in your object configuration file. The maximum amount of time that this command can run is controlled by the event_handler_timeout option. More information on event handlers can be found here.
This is the number of seconds that Nagios will sleep before checking to see if the next service or host check in the scheduling queue should be executed. Note that Nagios will only sleep after it "catches up" with queued service checks that have fallen behind.
This option allows you to control how service checks are initially "spread out" in the event queue. Using a "smart" delay calculation (the default) will cause Nagios to calculate an average check interval and spread initial checks of all services out over that interval, thereby helping to eliminate CPU load spikes. Using no delay is generally not recommended, as it will cause all service checks to be scheduled for execution at the same time. This means that you will generally have large CPU spikes when the services are all executed in parallel. More information on how to estimate how the inter-check delay affects service check scheduling can be found here. Values are as follows:
n = Don't use any delay - schedule all service checks to run immediately (i. e. at the same time!) d = Use a "dumb" delay of 1 second between service checks s = Use a "smart" delay calculation to spread service checks out evenly (default) x. xx = Use a user-supplied inter-check delay of x. xx seconds.
This option determines the maximum number of minutes from when Nagios starts that all services (that are scheduled to be regularly checked) are checked. This option will automatically adjust the service inter-check delay method (if necessary) to ensure that the initial checks of all services occur within the timeframe you specify. In general, this option will not have an affect on service check scheduling if scheduling information is being retained using the use_retained_scheduling_info option. Default value is 30 (minutes).
This variable determines how service checks are interleaved. Interleaving allows for a more even distribution of service checks, reduced load on remote hosts, and faster overall detection of host problems. Setting this value to 1 is equivalent to not interleaving the service checks (this is how versions of Nagios previous to 0.0.5 worked). Set this value to s (smart) for automatic calculation of the interleave factor unless you have a specific reason to change it. The best way to understand how interleaving works is to watch the status CGI (detailed view) when Nagios is just starting. You should see that the service check results are spread out as they begin to appear. More information on how interleaving works can be found here. x = A number greater than or equal to 1 that specifies the interleave factor to use. An interleave factor of 1 is equivalent to not interleaving the service checks. s = Use a "smart" interleave factor calculation (default)
This option allows you to specify the maximum number of service checks that can be run in parallel at any given time. Specifying a value of 1 for this variable essentially prevents any service checks from being run in parallel. Specifying a value of 0 (the default) does not place any restrictions on the number of concurrent checks. You'll have to modify this value based on the system resources you have available on the machine that runs Nagios, as it directly affects the maximum load that will be imposed on the system (processor utilization, memory, etc.). More information on how to estimate how many concurrent checks you should allow can be found here.
This option allows you to control the frequency in seconds of check result "reaper" events. "Reaper" events process the results from host and service checks that have finished executing. These events consitute the core of the monitoring logic in Nagios.
This option allows you to control the maximum amount of time in seconds that host and service check result "reaper" events are allowed to run. "Reaper" events process the results from host and service checks that have finished executing. If there are a lot of results to process, reaper events may take a long time to finish, which might delay timely execution of new host and service checks. This variable allows you to limit the amount of time that an individual reaper event will run before it hands control back over to Nagios for other portions of the monitoring logic.
This options determines which directory Nagios will use to temporarily store host and service check results before they are processed. This directory should not be used to store any other files, as Nagios will periodically clean this directory of old file (see the max_check_result_file_age option for more information).
Note: Make sure that only a single instance of Nagios has access to the check result path. If multiple instances of Nagios have their check result path set to the same directory, you will run into problems with check results being processed (incorrectly) by the wrong instance of Nagios!
This options determines the maximum age in seconds that Nagios will consider check result files found in the check_result_path directory to be valid. Check result files that are older that this threshold will be deleted by Nagios and the check results they contain will not be processed. By using a value of zero (0) with this option, Nagios will process all check result files - even if they're older than your hardware :-).
This option allows you to control how host checks that are scheduled to be checked on a regular basis are initially "spread out" in the event queue. Using a "smart" delay calculation (the default) will cause Nagios to calculate an average check interval and spread initial checks of all hosts out over that interval, thereby helping to eliminate CPU load spikes. Using no delay is generally not recommended. Using no delay will cause all host checks to be scheduled for execution at the same time. More information on how to estimate how the inter-check delay affects host check scheduling can be found here. Values are as follows:
n = Don't use any delay - schedule all host checks to run immediately (i. e. at the same time!) d = Use a "dumb" delay of 1 second between host checks s = Use a "smart" delay calculation to spread host checks out evenly (default) x. xx = Use a user-supplied inter-check delay of x. xx seconds.
This option determines the maximum number of minutes from when Nagios starts that all hosts (that are scheduled to be regularly checked) are checked. This option will automatically adjust the host inter-check delay method (if necessary) to ensure that the initial checks of all hosts occur within the timeframe you specify. In general, this option will not have an affect on host check scheduling if scheduling information is being retained using the use_retained_scheduling_info option. Default value is 30 (minutes).
This is the number of seconds per "unit interval" used for timing in the scheduling queue, re-notifications, etc. "Units intervals" are used in the object configuration file to determine how often to run a service check, how often to re-notify a contact, etc.
Important: The default value for this is set to 60, which means that a "unit value" of 1 in the object configuration file will mean 60 seconds (1 minute). I have not really tested other values for this variable, so proceed at your own risk if you decide to do so!
This option determines whether or not Nagios will attempt to automatically reschedule active host and service checks to "smooth" them out over time. This can help to balance the load on the monitoring server, as it will attempt to keep the time between consecutive checks consistent, at the expense of executing checks on a more rigid schedule.
WARNING: THIS IS AN EXPERIMENTAL FEATURE AND MAY BE REMOVED IN FUTURE VERSIONS. ENABLING THIS OPTION CAN DEGRADE PERFORMANCE - RATHER THAN INCREASE IT - IF USED IMPROPERLY!
This option determines how often (in seconds) Nagios will attempt to automatically reschedule checks. This option only has an effect if the auto_reschedule_checks option is enabled. Default is 30 seconds.
WARNING: THIS IS AN EXPERIMENTAL FEATURE AND MAY BE REMOVED IN FUTURE VERSIONS. ENABLING THE AUTO-RESCHEDULING OPTION CAN DEGRADE PERFORMANCE - RATHER THAN INCREASE IT - IF USED IMPROPERLY!
This option determines the "window" of time (in seconds) that Nagios will look at when automatically rescheduling checks. Only host and service checks that occur in the next X seconds (determined by this variable) will be rescheduled. This option only has an effect if the auto_reschedule_checks option is enabled. Default is 180 seconds (3 minutes).
WARNING: THIS IS AN EXPERIMENTAL FEATURE AND MAY BE REMOVED IN FUTURE VERSIONS. ENABLING THE AUTO-RESCHEDULING OPTION CAN DEGRADE PERFORMANCE - RATHER THAN INCREASE IT - IF USED IMPROPERLY!
Nagios tries to be smart about how and when it checks the status of hosts. In general, disabling this option will allow Nagios to make some smarter decisions and check hosts a bit faster. Enabling this option will increase the amount of time required to check hosts, but may improve reliability a bit. Unless you have problems with Nagios not recognizing that a host recovered, I would suggest not enabling this option.
0 = Don't use aggressive host checking (default) 1 = Use aggressive host checking.
This option determines whether or not Nagios will translate DOWN/UNREACHABLE passive host check results to their "correct" state from the viewpoint of the local Nagios instance. This can be very useful in distributed and failover monitoring installations. More information on passive check state translation can be found here.
0 = Disable check translation (default) 1 = Enable check translation.
This option determines whether or not Nagios will treat passive host checks as HARD states or SOFT states. By default, a passive host check result will put a host into a HARD state type. You can change this behavior by enabling this option.
0 = Passive host checks are HARD (default) 1 = Passive host checks are SOFT.
This option determines whether or not Nagios will execute predictive checks of hosts that are being depended upon (as defined in host dependencies) for a particular host when it changes state. Predictive checks help ensure that the dependency logic is as accurate as possible. More information on how predictive checks work can be found here.
0 = Disable predictive checks 1 = Enable predictive checks (default)
This option determines whether or not Nagios will execute predictive checks of services that are being depended upon (as defined in service dependencies) for a particular service when it changes state. Predictive checks help ensure that the dependency logic is as accurate as possible. More information on how predictive checks work can be found here.
0 = Disable predictive checks 1 = Enable predictive checks (default)
This option determines the maximum amount of time (in seconds) that the state of a previous host check is considered current. Cached host states (from host checks that were performed more recently than the time specified by this value) can improve host check performance immensely. Too high of a value for this option may result in (temporarily) inaccurate host states, while a low value may result in a performance hit for host checks. Use a value of 0 if you want to disable host check caching. More information on cached checks can be found here.
This option determines the maximum amount of time (in seconds) that the state of a previous service check is considered current. Cached service states (from service checks that were performed more recently than the time specified by this value) can improve service check performance when a lot of service dependencies are used. Too high of a value for this option may result in inaccuracies in the service dependency logic. Use a value of 0 if you want to disable service check caching. More information on cached checks can be found here.
This option determines whether or not the Nagios daemon will take several shortcuts to improve performance. These shortcuts result in the loss of a few features, but larger installations will likely see a lot of benefit from doing so. More information on what optimizations are taken when you enable this option can be found here.
This option determines whether or not Nagios will free memory in child processes when they are fork()ed off from the main process. By default, Nagios frees memory. However, if the use_large_installation_tweaks option is enabled, it will not. By defining this option in your configuration file, you are able to override things to get the behavior you want.
This option determines whether or not Nagios will fork() child processes twice when it executes host and service checks. By default, Nagios fork()s twice. However, if the use_large_installation_tweaks option is enabled, it will only fork() once. By defining this option in your configuration file, you are able to override things to get the behavior you want.
This option determines whether or not the Nagios daemon will make all standard macros available as environment variables to your check, notification, event hander, etc. commands. In large Nagios installations this can be problematic because it takes additional memory and (more importantly) CPU to compute the values of all macros and make them available to the environment.
0 = Don't make macros available as environment variables 1 = Make macros available as environment variables (default)
This option determines whether or not Nagios will try and detect hosts and services that are "flapping". Flapping occurs when a host or service changes between states too frequently, resulting in a barrage of notifications being sent out. When Nagios detects that a host or service is flapping, it will temporarily suppress notifications for that host/service until it stops flapping. Flap detection is very experimental at this point, so use this feature with caution! More information on how flap detection and handling works can be found here. Note: If you have state retention enabled, Nagios will ignore this setting when it (re)starts and use the last known setting for this option (as stored in the state retention file), unless you disable the use_retained_program_state option. If you want to change this option when state retention is active (and the use_retained_program_state is enabled), you'll have to use the appropriate external command or change it via the web interface.
0 = Don't enable flap detection (default) 1 = Enable flap detection.
This option is used to set the low threshold for detection of service flapping. For more information on how flap detection and handling works (and how this option affects things) read this.
This option is used to set the high threshold for detection of service flapping. For more information on how flap detection and handling works (and how this option affects things) read this.
This option is used to set the low threshold for detection of host flapping. For more information on how flap detection and handling works (and how this option affects things) read this.
This option is used to set the high threshold for detection of host flapping. For more information on how flap detection and handling works (and how this option affects things) read this.
This option determines whether or not Nagios will use soft state information when checking host and service dependencies. Normally Nagios will only use the latest hard host or service state when checking dependencies. If you want it to use the latest state (regardless of whether its a soft or hard state type), enable this option.
0 = Don't use soft state dependencies (default) 1 = Use soft state dependencies.
This is the maximum number of seconds that Nagios will allow service checks to run. If checks exceed this limit, they are killed and a CRITICAL state is returned. A timeout error will also be logged.
There is often widespread confusion as to what this option really does. It is meant to be used as a last ditch mechanism to kill off plugins which are misbehaving and not exiting in a timely manner. It should be set to something high (like 60 seconds or more), so that each service check normally finishes executing within this time limit. If a service check runs longer than this limit, Nagios will kill it off thinking it is a runaway processes.
This setting determines the state Nagios will report when a service check times out - that is does not respond within service_check_timeout seconds. This can be useful if a machine is running at too high a load and you do not want to consider a failed service check to be critical (the default).
Valid settings are:
This is the maximum number of seconds that Nagios will allow host checks to run. If checks exceed this limit, they are killed and a CRITICAL state is returned and the host will be assumed to be DOWN. A timeout error will also be logged.
There is often widespread confusion as to what this option really does. It is meant to be used as a last ditch mechanism to kill off plugins which are misbehaving and not exiting in a timely manner. It should be set to something high (like 60 seconds or more), so that each host check normally finishes executing within this time limit. If a host check runs longer than this limit, Nagios will kill it off thinking it is a runaway processes.
This is the maximum number of seconds that Nagios will allow event handlers to be run. If an event handler exceeds this time limit it will be killed and a warning will be logged.
There is often widespread confusion as to what this option really does. It is meant to be used as a last ditch mechanism to kill off commands which are misbehaving and not exiting in a timely manner. It should be set to something high (like 60 seconds or more), so that each event handler command normally finishes executing within this time limit. If an event handler runs longer than this limit, Nagios will kill it off thinking it is a runaway processes.
This is the maximum number of seconds that Nagios will allow notification commands to be run. If a notification command exceeds this time limit it will be killed and a warning will be logged.
There is often widespread confusion as to what this option really does. It is meant to be used as a last ditch mechanism to kill off commands which are misbehaving and not exiting in a timely manner. It should be set to something high (like 60 seconds or more), so that each notification command finishes executing within this time limit. If a notification command runs longer than this limit, Nagios will kill it off thinking it is a runaway processes.
This is the maximum number of seconds that Nagios will allow an obsessive compulsive service processor command to be run. If a command exceeds this time limit it will be killed and a warning will be logged.
This is the maximum number of seconds that Nagios will allow an obsessive compulsive host processor command to be run. If a command exceeds this time limit it will be killed and a warning will be logged.
This is the maximum number of seconds that Nagios will allow a host performance data processor command or service performance data processor command to be run. If a command exceeds this time limit it will be killed and a warning will be logged.
This value determines whether or not Nagios will "obsess" over service checks results and run the obsessive compulsive service processor command you define. I know - funny name, but it was all I could think of. This option is useful for performing distributed monitoring. If you're not doing distributed monitoring, don't enable this option.
0 = Don't obsess over services (default) 1 = Obsess over services.
This option allows you to specify a command to be run after every service check, which can be useful in distributed monitoring. This command is executed after any event handler or notification commands. The command argument is the short name of a command definition that you define in your object configuration file. The maximum amount of time that this command can run is controlled by the ocsp_timeout option. More information on distributed monitoring can be found here. This command is only executed if the obsess_over_services option is enabled globally and if the obsess_over_service directive in the service definition is enabled.
This value determines whether or not Nagios will "obsess" over host checks results and run the obsessive compulsive host processor command you define. I know - funny name, but it was all I could think of. This option is useful for performing distributed monitoring. If you're not doing distributed monitoring, don't enable this option.
0 = Don't obsess over hosts (default) 1 = Obsess over hosts.
This option allows you to specify a command to be run after every host check, which can be useful in distributed monitoring. This command is executed after any event handler or notification commands. The command argument is the short name of a command definition that you define in your object configuration file. The maximum amount of time that this command can run is controlled by the ochp_timeout option. More information on distributed monitoring can be found here. This command is only executed if the obsess_over_hosts option is enabled globally and if the obsess_over_host directive in the host definition is enabled.
This value determines whether or not Nagios will process host and service check performance data.
0 = Don't process performance data (default) 1 = Process performance data.
This option allows you to specify a command to be run after every host check to process host performance data that may be returned from the check. The command argument is the short name of a command definition that you define in your object configuration file. This command is only executed if the process_performance_data option is enabled globally and if the process_perf_data directive in the host definition is enabled.
This option allows you to specify a command to be run after every service check to process service performance data that may be returned from the check. The command argument is the short name of a command definition that you define in your object configuration file. This command is only executed if the process_performance_data option is enabled globally and if the process_perf_data directive in the service definition is enabled.
This option allows you to specify a file to which host performance data will be written after every host check. Data will be written to the performance file as specified by the host_perfdata_file_template option. Performance data is only written to this file if the process_performance_data option is enabled globally and if the process_perf_data directive in the host definition is enabled.
This option allows you to specify a file to which service performance data will be written after every service check. Data will be written to the performance file as specified by the service_perfdata_file_template option. Performance data is only written to this file if the process_performance_data option is enabled globally and if the process_perf_data directive in the service definition is enabled.
This option determines what (and how) data is written to the host performance data file. The template may contain macros, special characters (\t for tab, \r for carriage return, \n for newline) and plain text. A newline is automatically added after each write to the performance data file.
This option determines what (and how) data is written to the service performance data file. The template may contain macros, special characters (\t for tab, \r for carriage return, \n for newline) and plain text. A newline is automatically added after each write to the performance data file.
This option determines how the host performance data file is opened. Unless the file is a named pipe you'll probably want to use the default mode of append.
a = Open file in append mode (default) w = Open file in write mode p = Open in non-blocking read/write mode (useful when writing to pipes)
This option determines how the service performance data file is opened. Unless the file is a named pipe you'll probably want to use the default mode of append.
a = Open file in append mode (default) w = Open file in write mode p = Open in non-blocking read/write mode (useful when writing to pipes)
This option allows you to specify the interval (in seconds) at which the host performance data file is processed using the host performance data file processing command. A value of 0 indicates that the performance data file should not be processed at regular intervals.
This option allows you to specify the interval (in seconds) at which the service performance data file is processed using the service performance data file processing command. A value of 0 indicates that the performance data file should not be processed at regular intervals.
This option allows you to specify the command that should be executed to process the host performance data file. The command argument is the short name of a command definition that you define in your object configuration file. The interval at which this command is executed is determined by the host_perfdata_file_processing_interval directive.
This option allows you to specify the command that should be executed to process the service performance data file. The command argument is the short name of a command definition that you define in your object configuration file. The interval at which this command is executed is determined by the service_perfdata_file_processing_interval directive.
This option allows you to enable or disable checks for orphaned service checks. Orphaned service checks are checks which have been executed and have been removed from the event queue, but have not had any results reported in a long time. Since no results have come back in for the service, it is not rescheduled in the event queue. This can cause service checks to stop being executed. Normally it is very rare for this to happen - it might happen if an external user or process killed off the process that was being used to execute a service check. If this option is enabled and Nagios finds that results for a particular service check have not come back, it will log an error message and reschedule the service check. If you start seeing service checks that never seem to get rescheduled, enable this option and see if you notice any log messages about orphaned services.
0 = Don't check for orphaned service checks 1 = Check for orphaned service checks (default)
This option allows you to enable or disable checks for orphaned hoste checks. Orphaned host checks are checks which have been executed and have been removed from the event queue, but have not had any results reported in a long time. Since no results have come back in for the host, it is not rescheduled in the event queue. This can cause host checks to stop being executed. Normally it is very rare for this to happen - it might happen if an external user or process killed off the process that was being used to execute a host check. If this option is enabled and Nagios finds that results for a particular host check have not come back, it will log an error message and reschedule the host check. If you start seeing host checks that never seem to get rescheduled, enable this option and see if you notice any log messages about orphaned hosts.
0 = Don't check for orphaned host checks 1 = Check for orphaned host checks (default)
This option determines whether or not Nagios will periodically check the "freshness" of service checks. Enabling this option is useful for helping to ensure that passive service checks are received in a timely manner. More information on freshness checking can be found here.
0 = Don't check service freshness 1 = Check service freshness (default)
This setting determines how often (in seconds) Nagios will periodically check the "freshness" of service check results. If you have disabled service freshness checking (with the check_service_freshness option), this option has no effect. More information on freshness checking can be found here.
This option determines whether or not Nagios will periodically check the "freshness" of host checks. Enabling this option is useful for helping to ensure that passive host checks are received in a timely manner. More information on freshness checking can be found here.
0 = Don't check host freshness 1 = Check host freshness (default)
This setting determines how often (in seconds) Nagios will periodically check the "freshness" of host check results. If you have disabled host freshness checking (with the check_host_freshness option), this option has no effect. More information on freshness checking can be found here.
This option determines the number of seconds Nagios will add to any host or services freshness threshold it automatically calculates (e. g. those not specified explicity by the user). More information on freshness checking can be found here.
This setting determines whether or not the embedded Perl interpreter is enabled on a program-wide basis. Nagios must be compiled with support for embedded Perl for this option to have an effect. More information on the embedded Perl interpreter can be found here.
This setting determines whether or not the embedded Perl interpreter should be used for Perl plugins/scripts that do not explicitly enable/disable it. Nagios must be compiled with support for embedded Perl for this option to have an effect. More information on the embedded Perl interpreter and the effect of this setting can be found here.
This option allows you to specify what kind of date/time format Nagios should use in the web interface and date/time macros. Possible options (along with example output) include:
This option allows you to override the default timezone that this instance of Nagios runs in. Useful if you have multiple instances of Nagios that need to run from the same server, but have different local times associated with them. If not specified, Nagios will use the system configured timezone.
Note: If you use this option to specify a custom timezone, you will also need to alter the Apache configuration directives for the CGIs to specify the timezone you want. Exemplo:
SetEnv TZ "US/Mountain"
This option allows you to specify illegal characters that cannot be used in host names, service descriptions, or names of other object types. Nagios will allow you to use most characters in object definitions, but I recommend not using the characters shown in the example above. Doing may give you problems in the web interface, notification commands, etc.
This option allows you to specify illegal characters that should be stripped from macros before being used in notifications, event handlers, and other commands. This DOES NOT affect macros used in service or host check commands. You can choose to not strip out the characters shown in the example above, but I recommend you do not do this. Some of these characters are interpreted by the shell (i. e. the backtick) and can lead to security problems. The following macros are stripped of the characters you specify:
$HOSTOUTPUT$ , $HOSTPERFDATA$ , $HOSTACKAUTHOR$ , $HOSTACKCOMMENT$ , $SERVICEOUTPUT$ , $SERVICEPERFDATA$ , $SERVICEACKAUTHOR$ , and $SERVICEACKCOMMENT$
This option determines whether or not various directives in your object definitions will be processed as regular expressions. More information on how this works can be found here.
0 = Don't use regular expression matching (default) 1 = Use regular expression matching.
If you've enabled regular expression matching of various object directives using the use_regexp_matching option, this option will determine when object directives are treated as regular expressions. If this option is disabled (the default), directives will only be treated as regular expressions if they contain * , ? , + , or \. . If this option is enabled, all appropriate directives will be treated as regular expression - be careful when enabling this! More information on how this works can be found here.
0 = Don't use true regular expression matching (default) 1 = Use true regular expression matching.
This is the email address for the administrator of the local machine (i. e. the one that Nagios is running on). This value can be used in notification commands by using the $ADMINEMAIL$ macro.
This is the pager number (or pager email gateway) for the administrator of the local machine (i. e. the one that Nagios is running on). The pager number/address can be used in notification commands by using the $ADMINPAGER$ macro.
This option controls what (if any) data gets sent to the event broker and, in turn, to any loaded event broker modules. This is an advanced option. When in doubt, either broker nothing (if not using event broker modules) or broker everything (if using event broker modules). Possible values are shown below.
0 = Broker nothing -1 = Broker everything # = See BROKER_* definitions in source code (include/broker. h) for other values that can be OR'ed together.
This directive is used to specify an event broker module that should by loaded by Nagios at startup. Use multiple directives if you want to load more than one module. Arguments that should be passed to the module at startup are seperated from the module path by a space.
Do NOT overwrite modules while they are being used by Nagios or Nagios will crash in a fiery display of SEGFAULT glory. This is a bug/limitation either in dlopen(), the kernel, and/or the filesystem. And maybe Nagios.
The correct/safe way of updating a module is by using one of these methods:
Shutdown Nagios, replace the module file, restart Nagios While Nagios is running. delete the original module file, move the new module file into place, restart Nagios.
This option determines where Nagios should write debugging information. What (if any) information is written is determined by the debug_level and debug_verbosity options. You can have Nagios automaticaly rotate the debug file when it reaches a certain size by using the max_debug_file_size option.
This option determines what type of information Nagios should write to the debug_file. This value is a logical OR of the values below.
-1 = Log everything 0 = Log nothing (default) 1 = Function enter/exit information 2 = Config information 4 = Process information 8 = Scheduled event information 16 = Host/service check information 32 = Notification information 64 = Event broker information.
This option determines how much debugging information Nagios should write to the debug_file.
0 = Basic information 1 = More detailed information (default) 2 = Highly detailed information.
This option determines the maximum size (in bytes) of the debug file. If the file grows larger than this size, it will be renamed with a. old extension. If a file already exists with a. old extension it will automatically be deleted. This helps ensure your disk space usage doesn't get out of control when debugging Nagios.
This boolean option determines whether services, service dependencies, or host dependencies assigned to empty host groups (host groups with no host members) will cause Nagios to exit with error on start up (or during a configuration check) or not. The default behavior if the option is not present in the main configuration file is for Nagios to exit with error if any of these objects are associated with host groups that have no hosts associated with them. Enabling this option can be useful when:

Event_broker_options Nagios.
NagiosPi - Server Monitoring With The Power of Pi .
For anyone interested in the details of my build, I’ve documented my entire process step-by-step… [learn_more caption=”Getting Ready…”] 1.)
pnp-0.6: verify [PNP4Nagios Docs]
Calling make install-config during installation will create a sample config file etc/process_perfdata. cfg-sample. The values in the sample file will correspond to the .
MK Livestatus - Mathias Kettner.
broker_module=/usr/local/lib/mk - livestatus / livestatus. o /var/lib/ nagios /rw/live event_broker_options =-1 The only mandatory argument …