Como um administrador generaliza alertas quando um evento não acontece?

Question

Muitas vezes, meus usuários exigem que eu seja apenas responsável por saber se um evento não aconteceu.

Sempre tive que criar soluções personalizadas e frágeis com scripts de shell cron e muitos testes de caso de borda de data.

O registro centralizado deve permitir uma maneira melhor e mais fácil de controlar o que não aconteceu nas últimas N horas. Algo como o logstash percebendo e nagios alertando.

Atualizar

A resposta de toppledwagon foi incrivelmente útil. o O (Light. Bulb.) que agora tenho uma dúzia de trabalhos em lote sendo atualizados. Eu queria fazer sua resposta completa e seguir com a maneira como implementei suas ideias.

Eu configurei o jenkins para emitir syslogs, o logstash os captura e envia atualizações de status para o nagios via nsca. Eu também uso check_mk para manter tudo seco e organizado em nagios.

Filtro Logstash

:::ruby
filter {
  if [type] == "syslog" {
    grok {
      match => [ "message", '%{SYSLOGBASE} job="%{DATA:job}"(?: repo="%{DATA:repo}")?$',
                 "message", "%{SYSLOGLINE}" ]
      break_on_match => true
    }
    date { match => [ "timestamp", "MMM  d HH:mm:ss", "MMM dd HH:mm:ss" ] }
  }
}

A mágica está nesse duplo par de padrões no parâmetro de correspondência de grok ao longo com break_on_match = > verdade. O Logstash tentará cada padrão por sua vez até um deles corresponde.

Saída do Logstash

Nós usamos o plugin de saída logstash nagios_nsca para deixar o icinga saber que vimos o trabalho de Jenkins no syslog.

:::ruby
output {
  if [type] == "syslog"
    and [program] == "jenkins"
    and [job] == "Install on Cluster"
    and "_grokparsefailure" not in [tags] {
      nagios_nsca {
        host => "icinga.example.com"
        port => 5667
        send_nsca_config => "/etc/send_nsca.cfg"
        message_format => "%{job} %{repo}"
        nagios_host => "jenkins"
        nagios_service => "deployed %{repo}"
        nagios_status => "2"
      }
   } # if type=syslog, program=jenkins, job="Install on Cluster"
} # output

icinga (nagios)

Finalmente, chegamos ao icinga (nagios) por meio de nsca. Agora vamos precisar verificações de serviço passivo definidas para cada trabalho que queremos notar não aconteça a tempo. Isso pode ser um monte de tarefas, então vamos usar check_mk para transformar listas python de empregos em definições de objetos nagios.

check_mk é legal assim.

/etc/check_mk/conf.d/freshness.mk

# check_mk requires local variables be prefixed with '_'

_dailies = [ 'newyork' ]
_day_stale = 86400 * 1.5

_weeklies = [ 'atlanta', 'denver', ]
_week_stale = 86400 * 8

_monthlies = [ 'stlouis' ]
_month_stale = 86400 * 32

_service_opts = [
    ("active_checks_enabled", "0"),
    ("passive_checks_enabled", "1"),
    ("check_freshness", "1"),
    ("notification_period", "workhours"),
    ("contacts", "root"),
    ("check_period", "workhours"),
]

# Define a new command 'check-periodically' that sets the service to UKNOWN.
# This is called after _week_stale seconds have passed since the service last checked in.

extra_nagios_conf += """
  define command {
    command_name check-periodicaly
    command_line $USER1$/check_dummy 3 $ARG1$
  }

  """
# Loop through all passive checks and assign the new check-period command to them.

for _repo in _dailies + _weeklies + _monthlies:
    _service_name = 'deployed %s' % _repo
    legacy_checks += [(('check-periodicaly', _service_name, False), ['lead'])]


# Look before you leap - python needs the list defined before appending to it.
# We can't assume it already exists because it may be defined earlier.

if "freshness_threshold" not in extra_service_conf:
    extra_service_conf["freshness_threshold"] = []

# Some check_mk wizardry to set when the check has passed its expiration date.
# Results in (659200, ALL_HOSTS, [ 'atlanta', 'denver' ]) for weeklies, etc.

extra_service_conf["freshness_threshold"] += [
    (_day_stale,   ALL_HOSTS, ["deployed %s"   % _x for _x in _dailies]  ),
    (_week_stale,  ALL_HOSTS, ["deployed %s"  % _x for _x in _weeklies] ),
    (_month_stale, ALL_HOSTS, ["deployed %s" % _x for _x in _monthlies] ),
]

# Now we assign all the other nagios directives listed in _service_opts

for _k,_v in _service_opts:
    if _k not in extra_service_conf:
        extra_service_conf[_k] =  []

    extra_service_conf[_k] += [(_v, ALL_HOSTS, ["deployed "]) ]

    

Answer 1

Eu configuro verificações passivas no nagios para vários eventos. Então, no final do evento, a verificação passiva é enviada para nagios (seja via script wrapper ou embutida no próprio evento). Se a verificação passiva não tiver sido recebida em renewal_threshold segundos, ela executará check_command localmente. check_command é configurado como um script de shell simples que retorna crítico e as informações da descrição do serviço.

Eu não tenho exemplos de código à mão, mas se eu pudesse, se o interesse é mostrado.

EDIT ONE exemplos de código adicionados:

Isso pressupõe que você tenha feito a configuração básica para NSCA e send_nsca (certifique-se de que password e encryption_method sejam os mesmos em send_nsca.cfg no cliente e nsca.cfg no servidor nagios. Em seguida, inicie o daemon nsca no servidor nagios. )

Primeiro, definimos um modelo que outras verificações passivas podem usar. Isso vai para services.cfg.

define service {
    name                    standard-passive-service-template
    active_checks_enabled   0
    passive_checks_enabled  1
    check_freshness         1
    max_check_attempts      1
    normal_check_interval   10
    retry_check_interval    5
    contact_groups          sysadmins
    notification_interval   0
    notification_options    w,u,c,r
    notification_period     24x7
    check_period            24x7
    check_command           check_failed!$SERVICEDESC$
    register                0
}

Isso diz que, se uma notificação não chegar, execute check_failed com $ SERVICEDESC $ como argumento. Vamos definir o comando check_failed em commands.cfg.

define command {
    command_name     check_failed
    command_line     /usr/lib/nagios/plugins/check_failed $ARG1$
}

Aqui está o script /usr/lib/nagios/plugins/check_failed .

#!/bin/bash
/bin/echo "No update from $*. Is NSCA running?"
exit 2

Ter uma saída de 2 torna esse serviço crítico de acordo com os nagios (veja abaixo todos os estados de serviço do nagios.) O fornecimento de /usr/lib/nagios/plugins/utils.sh é uma outra maneira e, em seguida, você poderia exit $STATE_CRITICAL . Mas o acima funciona mesmo que você não tenha isso.

Isso fornece o aviso adicional de "A NSCA está em execução" porque pode ser o caso de o serviço não ter feito o check-in corretamente OU pode ser o caso de a NSCA ter falhado. Isso é mais comum do que se imagina. Se várias verificações passivas vierem de uma só vez, verifique se há algum problema com a NSCA.

Agora precisamos de uma verificação passiva para aceitar os resultados. Neste exemplo, tenho uma tarefa cron especialmente criada que conhece todos os diferentes tipos de controladores RAID em nosso ambiente. Quando executado, envia uma notificação para esta verificação passiva. Neste exemplo, não quero ser acordado no meio da noite (edite notification_period conforme necessário).

define service {
    use                     standard-passive-service-template
    hostgroup_name          all
    service_description     raidcheck
    notification_period     daytime
    flap_detection_enabled  1
    freshness_threshold     7500 # 125 minutes
    notification_options    c
    is_volatile             0
    servicegroups           raidcheck
}

Agora, há o cronjob que envia informações de volta ao servidor nagios. Aqui está a linha em /etc/cron.d/raidcheck

0 * * * *  root  /usr/local/bin/raidcheck --cron | /usr/sbin/send_nsca -H nagios -to 1000 >> /dev/null 2>&1

Veja man send_nsca para opções, mas as partes importantes são 'nagios' é o nome do meu servidor nagios e a string que é impressa no final deste script. send_nsca espera uma linha no stdin do formulário (perl aqui)

print "$hostname\t$check\t$state\t$status_info\n";

$ hostname é óbvio, $ check neste caso é 'raidcheck', $ state é o estado do serviço nagios (0 = OK, 1 = aviso, 2 = crítico, 3 = desconhecido, 4 = dependente.) e $ status_info é uma mensagem opcional para enviar como informações de status.

Agora podemos testar a verificação na linha de comando do cliente:

echo -e "$HOSTNAME\traidcheck\t2\tUh oh, raid degraded (just kidding..)" | /usr/sbin/send_nsca -H nagios

Isso nos dá uma verificação passiva nagios que espera ser atualizada a cada frescura_o segundo período. Se a verificação não for atualizada, check_command (check_failed neste caso) será executado. O exemplo acima é para uma instalação do nagios 2.X, mas provavelmente funcionará (talvez com pequenas modificações) para o nagios 3.X.

    

Answer 2

Não tenho certeza de qual tipo você está se referindo, pois o "evento não acontece" pode assumir diferentes formas, pode ser condicional ou incondicional. Exemplos:

• falhas de autenticação do usuário não seguidas por login bem-sucedido indica que o usuário esqueceu sua senha (ou tentativa de força bruta)
• nenhuma autenticação de usuário durante o dia - o usuário não apareceu para o trabalho

Se você estiver após o primeiro caso e precisar de uma ferramenta de código aberto, há uma regra Paracom a janela na SEC e na regra Ausência no nxlog (observe que eu sou afiliado com o último).

O segundo tipo é mais simples e ambas as ferramentas podem lidar com isso também.