Eu escrevi um plug-in de verificação do Nagios usando dados históricos do sar que você pode estar interessado. Mesmo que não seja útil para você de imediato, você pode facilmente usá-lo como ponto de partida para verificações mais sofisticadas.
Nagios em seus monitores de uso padrão com verificações pontuais: qualquer coisa é - ou não é - verdadeira.
Outras ferramentas, como o PCP da SGI, o MeasureWare da HP e o SEC, fornecem monitoramento ao longo do tempo - monitorando coisas como o tempo médio de acesso ao disco nos últimos cinco minutos ou outros itens semelhantes. Existe algo assim para o Nagios? Eu já estou executando o NDOUtils, que parece uma fonte natural para esses dados.
Eu gostaria de ter algo que monitore e disparasse alarmes com base em uma verificação baseada em tempo usando dados históricos. Existe algo assim para o Nagios?
Eu escrevi um plug-in de verificação do Nagios usando dados históricos do sar que você pode estar interessado. Mesmo que não seja útil para você de imediato, você pode facilmente usá-lo como ponto de partida para verificações mais sofisticadas.
Você diz
Usage example: Generate Alarm if CPU Load is over 95% for 10 minutes.
mas NAGIOS já faz isso. Se, por exemplo, você não quiser saber sobre um problema até que esteja assim por trinta minutos, tente (na definição de serviço)
max_check_attempts 6
retry_interval 5
Isso fará com que o serviço seja verificado em intervalos de cinco minutos, mesmo depois de passar por SOFT ERROR, mas não seja difícil - e notifique - até o sexto erro progressivo (6 * 5mins = 30 mins).
Se não é isso que você queria, você pode explicar como fica aquém?
Editar : você percebe que isso funciona para você, mas não consegue lidar com questões de julgamento mais complexas (por exemplo, foo está acima de 80% em mais de 60% dos 30 anteriores minutos).
Isso é verdade, mas na minha experiência de implantar o NAGIOS, e eu fiz bastante disso, existem muito poucas circunstâncias em que as pessoas realmente precisam para saber algo parecido. Eles podem querer saber, mas quando pressionados, eles geralmente não têm uma necessidade de engenharia. Nesses casos, "não" é a resposta correta; a ferramenta de monitoramento é crítica para os negócios, e sobrecarregá-la com um monte de testes idiotas de que eu quero um pônei para fazer com que alguns vice-presidentes da lavanderia executiva fiquem felizes com a coisa errada.
Nas ocasiões estranhas em que eles realmente precisam de algo barroco, é muito melhor colocá-lo no plug-in. Por exemplo, eu fiz algum trabalho para um cliente para que eles soubessem a idade dos snapshots em qualquer volume NetApp, e estava tudo bem. Em seguida, surgiu um requisito de engenharia legítimo para verificar se o membro mais antigo do conjunto de instantâneos mais jovens em um determinado conjunto de volumes era mais jovem que um determinado limite (talvez você queira ler isso algumas vezes!). Eu provavelmente poderia ter torturado o NAGIOS para avaliar critérios baseados nos resultados dos múltiplos plugins "snapshot age", mas era muito mais sensato a longo prazo escrever um plugin que rastreasse e avaliasse este critério complexo por si só.
Então, eu diria a você: cuidado para que haja uma boa necessidade de engenharia para avaliar critérios estranhos. Nos poucos casos em que houver, escreva seu próprio plugin para rastreá-lo.
Você já pensou em usar opsview ou groundworks ?
Sim. A coisa é chamada de link
Ele permite que você colete os "dados de desempenho", como é chamado no Nagios, para representar graficamente esses dados com o RRD.
Com o Nagios, Icinga pode ser interessante (é um fork do Nagios).
Outra coisa interessante é que o link não está relacionado ao nagios, mas você pode definir tresholds e verificar essa condição no Nagios.
UPDATE
Para a CPU está acima de 95%, você pode fazer uma verificação que verifica a carga da cpu e fazer uma verificação a cada minuto por dez vezes.
Faz anos desde que eu olhei para ele, mas o Cacti tem um plugin para alertar sobre limites chamados "thold" ou algo assim.
Tags nagios