Назад | Перейти на главную страницу

Как администратор обобщает предупреждения, когда события не происходит?

Часто мои пользователи требуют, чтобы я также несли ответственность за то, чтобы знать, не произошло ли событие.

Мне всегда приходилось создавать нестандартные и нестабильные решения с использованием сценариев оболочки cron'ed и большого количества тестов для крайних случаев.

Централизованное ведение журнала должно позволить найти лучший, более удобный в обслуживании способ получить контроль над тем, что не сделал произошло за последние N часов. Что-то вроде уведомления logstash и предупреждений nagios.

Обновить

Ответ toppledwagon был невероятно полезным. o O (Лампочка), что теперь у меня проверяется на свежесть дюжины пакетных заданий. Я хотел отдать должное его обстоятельному ответу и рассказать, как я реализовал его идеи.

Я настроил jenkins для выдачи системных журналов, logstash их ловит и отправляет обновления статуса в nagios через nsca. Я также использую check_mk, чтобы все было СУХИМ и организовано в nagios.

Фильтр 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" ] }
  }
}

Магия заключается в этой двойной паре шаблонов в параметре соответствия grok вместе с break_on_match => true. Logstash будет пробовать каждый шаблон по очереди, пока один из них не совпадет.

Вывод Logstash

Мы используем плагин вывода logstash nagios_nsca, чтобы icinga знала, что мы видели задание jenkins в 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) через nsca. Теперь нам потребуются пассивные проверки службы, определенные для каждой работы, которую мы хотим заметить, не выполненной вовремя. Это может быть много работы, поэтому давайте использовать check_mk для преобразования списков заданий Python в определения объектов nagios.

check_mk это круто.

/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 "]) ]

Я настраиваю пассивные проверки в nagios для различных событий. Затем в конце события пассивная проверка отправляется в nagios (либо через сценарий-оболочку, либо встроена в само событие). Если пассивная проверка не была получена в течение секунд freshness_threshold, она запускает check_command локально. check_command настраивается как простой сценарий оболочки, который возвращает критическую информацию и информацию из описания службы.

У меня нет под рукой примеров кода, но если бы мог, если бы проявили интерес.

ИЗМЕНИТЬ ОДИН добавленный пример кода:

Это предполагает, что вы выполнили базовую настройку для NSCA и send_nsca (убедитесь, что пароль и encryption_method совпадают в send_nsca.cfg на клиенте и nsca.cfg на сервере nagios. Затем запустите демон nsca на сервере nagios.)

Сначала мы определяем шаблон, который могут использовать другие пассивные проверки. Это входит в 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
}

Это говорит о том, что если уведомление не пришло, запустите check_failed с $ SERVICEDESC $ в качестве аргумента. Определим команду check_failed в commands.cfg.

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

Здесь /usr/lib/nagios/plugins/check_failed сценарий.

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

Выход 2 делает эту службу критичной согласно nagios (см. Ниже все состояния службы nagios). /usr/lib/nagios/plugins/utils.sh другой способ, тогда вы могли бы exit $STATE_CRITICAL. Но вышеперечисленное работает, даже если у вас этого нет.

Это дает дополнительное уведомление «Работает ли NSCA», потому что это может быть случай, когда служба не прошла регистрацию должным образом, ИЛИ это может быть случай, когда NSCA не работает. Это чаще, чем можно было бы подумать. Если одновременно поступает несколько пассивных проверок, проверьте наличие проблемы с помощью NSCA.

Теперь нам нужна пассивная проверка, чтобы принять результаты. В этом примере у меня есть специально созданное задание cron, которое знает обо всех различных типах контроллеров рейда в нашей среде. При запуске он отправляет уведомление об этой пассивной проверке. В этом примере я не хочу, чтобы меня разбудили посреди ночи (при необходимости отредактируйте notification_period).

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
}

Теперь есть задание cron, которое отправляет информацию обратно на сервер nagios. Вот строка в /etc/cron.d/raidcheck

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

Видеть man send_nsca для опций, но важными частями являются «nagios» - это имя моего сервера nagios и строка, которая печатается в конце этого скрипта. send_nsca ожидает строку на стандартном вводе в форме (здесь Perl)

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

$ hostname очевидно, $ check в этом случае - raidcheck, $ state - это состояние службы nagios (0 = ОК, 1 = предупреждение, 2 = критическое, 3 = неизвестно, 4 = зависимое.) и $ status_info является необязательным сообщение для отправки в качестве информации о статусе.

Теперь мы можем протестировать проверку в командной строке клиента:

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

Это дает нам пассивную проверку nagios, которая ожидает обновления каждые freshness_threshold секунд. Если проверка не обновляется, запускается check_command (в данном случае check_failed). Приведенный выше пример относится к установке nagios 2.X, но, вероятно, будет работать (возможно, с небольшими изменениями) для nagios 3.X.

Не уверен, какой тип вы называете «событие не происходит», может принимать разные формы, оно может быть условным или безусловным. Примеры:

  • сбой аутентификации пользователя, за которым не следует успешный вход в систему, указывает на то, что пользователь забыл свой пароль (или попытка грубой силы)
  • нет аутентификации пользователя в течение дня - пользователь не явился на работу

Если вам нужен первый случай и вам нужен инструмент с открытым исходным кодом, есть Пара с окном правило в SEC и Отсутствие правило в nxlog (обратите внимание, что я связан с последним).

Второй тип проще, и оба инструмента могут справиться с этим слишком быстро.