A sua duvida eh interessante.
De fato o freshness nao conta o timeperiods. Ele foi feito para ver se o
servico esta mesmo sendo checado ou nao e se vc coloca em um vlr menor q
o check_periods vc deve ter problemas de fato.
Eu nao vejo pq usar o freshness para o servico de backup. Acho q faz
mais sentido fazer o freshness em um plugin q verifica o proprio Nagios
24 hs e dai vc faz o cruzamento das infos em caso de um unknown state do
servico backup.
sd,
Edgar
Rejaine Monteiro escreveu:
Ola lista,
Desculpem-me por reportar esse problema novamente, mas como ainda não
encontrei solução vou tentar pedir ajuda para vocês novamente ..
Como funciona o relacionamento entre os periodos de tempos definidos em
timeperiods e as opcoes freshness_threshold das checagens passivas?
Vou tentar explicar o meu problema.
Temos varios serviços de backup noturnos para serem checados. Esses
backups sao executados somente de segunda a sexta (de 05:00 as 24:00) e
no sabado (de 00: as 05) Nao ha backup compreendido fora desse perido
(aos domingos, por exemplo, nao ha backup)
Entao, defino o seguinte periodo de tempo no arquivo timeperiods.cfg
define timeperiod{
timeperiod_name backup_hours
alias Backup hours
monday 05:00-24:00
tuesday 00:00-24:00
wednesday 00:00-24:00
thursday 00:00-24:00
friday 00:00-24:00
saturday 00:00-05:00
}
Depois, defino os servicos (utilizando checagens passivas) para cada um
dos hosts que possuo, como exemplo:
define service{
service_description BACKUP1
host_name host1
active_checks_enabled 0
passive_checks_enabled 1
parallelize_check 1
obsess_over_service 1
check_freshness 1
freshness_threshold 93600
notifications_enabled 1
event_handler_enabled 1
flap_detection_enabled 1
is_volatile 0
max_check_attempts 1
check_period backup_hours
normal_check_interval 1
retry_check_interval 1
notification_interval 120
notification_period 24x7
notification_options w,c,r
contact_groups backup_operators
process_perf_data 1
retain_status_information 1
retain_nonstatus_information 1
check_command no_backup_report!26!hours
}
Observem que a opcao freshness_threshold foi definida como 93600, ou
seja, 26 horas. O que significa que, seu eu nao receber nenhuma
informação sobre esse serviço (de sucesso ou erro) o Nagios deverá me
enviar um alerta (no_backup_report) informando que nenhuma informaçao
para esse serviço foi enviadas nas ultimas 26 horas..
Tudo funciona perfeitamente durante toda a semana, perfeitamente.
Tenho meus backups programados normalmente para as madrugadas (ex.
02:00, 03:00 horas da manha) e os backups para fita normalmente sao
executados durante o dia (08 as 12:00)
Tudo funciona bem, mas quando chega o domingo o Nagios envia um alerta
(no_backup_report) avisando que os serviços estão atrasados a mais de 26
horas. So que ele nao deveria contabilizar as horas de domingo, pois
domingo nao faz parte da definicao timeperiods (domingo nao há backup)
Um exemplo:
O ultimo backup foi feito com sucesso foi no sábado, as 03:00 da manha
O Nagios recebeu o status OK para o serviço
O Nagios começa a contabilizar a taxa de atualização de serviço
Isso deveria ser feito somente até as 05:00 da manha de sábado, de
acordo com a escala backup_hours (timeperiods) para esse serviço
Temos apenas 2 horas decorridas entao de taxa de desatualizacao
Domingo não há backup (nao tem domingo no escala backup_hours)
Chega segunda, começa novamente a contabilizar , mas somente a partir de
05:00 da manha (de 05:00 as 08:00 + 3 horas..
Temos entao, um total de 5 horas decorridas de taxa de desatualizacao
Só que eu chego na segunda as 08:00 e já está lá o alerta..
Isso me leva a crer que o timeperiods nao esta sendo levando em conta
quando o freshness_threshold é utilizado (as 24 de domingo parecem
estar sendo contabilizadas...)
Existe então alguma forma de fazer com que o nagios respeite o
timeperiods definido para esses serviço e ainda utilizar
freshness_threshold?
Rejaine
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Nagios-users-br mailing list
Nagios-users-br@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users-br
Archives: http://www.mail-archive.com/nagios-users-br@lists.sourceforge.net/
http://news.gmane.org/gmane.network.nagios.user.brazil
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Nagios-users-br mailing list
Nagios-users-br@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users-br
Archives: http://www.mail-archive.com/nagios-users-br@lists.sourceforge.net/
http://news.gmane.org/gmane.network.nagios.user.brazil
