Ad Widget

Collapse

Мониторинг Windows Event Log

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • titov
    Member
    • Dec 2009
    • 50

    #1

    Мониторинг Windows Event Log

    Всем привет!
    Хочу мониторить System лог на сервере Windows 2003.
    почитал тут http://www.zabbix.com/wiki/howto/mon...ndows_eventlog

    Только мне нужно мониторить конкретное событие:

    Event Type: Warning
    Event Source: DhcpServer
    Event Category: None
    Event ID: 1020
    Date: 26.04.2010
    Time: 18:29:42
    User: N/A
    Computer: MPA-FS
    Description:
    Scope, 192.168.85.0, is 82 percent full with only 9 IP addresses remaining.

    For more information, see Help and Support

    Center at http://go.microsoft.com/fwlink/events.asp.

    Я создал шаблон и Item:
    Host: Own_DHCP
    Description: DHCP server scope
    Type: Zabbix agent (active)
    Key: eventlog[system,,,DhcpServer,1020]


    Потом создал триггер:
    Expression: {Own_DHCP:eventlog[system,,,DhcpServer,1020].logseverity(2)}=2

    По идеи уже все что будет приходить в Item должно срабатывать в триггере, ибо у меня уже настроен фильтр и по ID и по source.

    Или я в Item должен написать Key: eventlog[system]
    тогда как настроить триггер чтобы срабатывал только если ID = 1020 и source DhcpServer?

    Сейчас по этому айтему просто не приходят никакие данные, хотя в логах есть событие:

    Event Type: Warning
    Event Source: DhcpServer
    Event Category: None
    Event ID: 1020
    Date: 27.04.2010
    Time: 13:30:22
    User: N/A
    Computer: MPA-FS
    Description:
    Scope, 192.168.85.0, is 86 percent full with only 7 IP addresses remaining.

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

    Может быть нужно zabbix agent перезагрузить на сервере??
    Last edited by titov; 27-04-2010, 12:29.
  • titov
    Member
    • Dec 2009
    • 50

    #2
    пробовал, просто выставить в Item
    ключ eventlog[System]
    Все равно никаких данных нет...

    Comment

    • titov
      Member
      • Dec 2009
      • 50

      #3
      Разобрался с логами, нужно было в агент добавить
      Hostname=<host name>

      Вот из доки:

      NOTE: In the CLIENT config file “Hostname=<host name>” MUST exist (and match the “Hostname” field on the Server) before eventlog will work. Also, ensure there is no “DisableActive=1” line.

      Только фильтр по ID не работает. Если выставить в Item:
      eventlog[System] то все логи появляются в zabbix.
      А если eventlog[System,,,DhcpServer,1020], то событие не регистрируется.

      Comment

      • zalex_ua
        Senior Member
        Zabbix Certified Trainer
        Zabbix Certified SpecialistZabbix Certified Professional
        • Oct 2009
        • 1286

        #4
        Originally posted by titov
        Только фильтр по ID не работает. Если выставить в Item:
        eventlog[System] то все логи появляются в zabbix.
        А если eventlog[System,,,DhcpServer,1020], то событие не регистрируется.
        Ключ eventlog[System,,,DhcpServer,1020] у тебя настроен правильно, но я не уверен есть ли такое событие (DhcpServer,1020) вообще и не могу проверить. Но тут есть один подвох, о котором узнаеш не сразу.
        Я наблюдал как работает Заббикс агент (дебаглевел 4) при фильтрации eventlog на стороне агента. В итоге допустим у тебя в журнале событий System 10 тыс. записей, а твоя запись DhcpServer,1020 нахотися в конце журнала (свежая). Агент при первой обработке твоего Итема (после его создания) начинает парсить журнал с самого начала и довольно медленно со скоростью приблизительно 30-70 событий в секунду.
        В итоге он доберется доотметки 10 тыс. через значительное врямя. Только после того как будет найдено DhcpServer,1020 он отметит в базе данных внутренний № последнего найденого события. Вот эта пауза меня и вводила в свое время в непонинимание, особенно когда речь идет о журналах Безопасности, где кол-во событий - сотни тысяч и поток событий огромнейший, а ищешь редкосную комбинацию параметров.
        Может быть это и есть твой случай.

        В следующий раз при запуске Агент будет искать Итем "DhcpServer,1020" начиная не с последнего события в журнале вообще, а с последнего найленого DhcpServer,1020. Тоесть опять будет пауза.
        В придачу, если Итемов с фильрацией несколько (что вполне реально), так они КАЖЕТСЯ (уже не помню) последовально перебираются, то есть пауза появления редкосного события после перезапуска агента может быть еще более значительна.

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

        p.s. в будущей версии 2.0 добавлен еще один параметр - режим - один из all (по умолчанию), skip (пропуск обработки старых данных)
        Параметр mode будет поддерживаться начиная с версии 2.0.
        Это некоторое решение описаной мной проблемы, но есть и минус - будут пропущени события, возникшие при "не работающем" агенте. Например при перезагрузке машины. Я еще размышляю как к этому относится.
        Last edited by zalex_ua; 30-04-2010, 14:18.

        Comment

        • Anth0ny
          Member
          • Nov 2009
          • 85

          #5
          С тем как принимать логи и вешать на них триггер я разобрался сравнительно быстро...

          Но вот что ставит меня в тупик: если все остальные источники данных (например: сервисы, процессы, состояния дисков) имеют как минимум 2 (0\1) свойства (соответственно: включён\выключен, запущен\не запущен, диск заполнен на N%), то ... То как же быть с логами? У записи, сгенерированной приложением в лог вполне может не быть второй записи, отловив которую триггер, связанный с источником (получение данных из лога, фильтрация по полю Source) определяет, что проблема исчерпана... Как же закрывать проблему?

          Задача: нужно принимать определённые записи об ошибках из Windows-логов (например, данные о всех событиях, связанных с Source: SceCli), при условии, что поле "Type" полученных записей НИКОГДА не будет Success\Information (что вполне нормально для любого сервиса, который сообщает только об ошибках).

          Вопрос:

          Как можно реализовать простейшую схему, при которой при получении записи, подпадающей под триггер, Zabbix бы выполнял предписанный ему Action (мылил) и на этом процессинг бы сразу прекращался? Можно конечно пытаться использовать фильтрацию в Actions по "Action operations" (Ack\Not Ack), но это помогает только предотвратить отсылку новых извещений.

          И не помогает избежать основной проблемы: в дашборде всё равно будет висеть сообщение о проблеме (ведь триггер перевёл состояние айтема в PROBLEM (например с severity Warning).

          Как избежать этого "зависания"?

          Идеальный вариант: если бы можно было делать Ack на айтем, находящийся в состоянии PROBLEM и это бы переводило его в состояние OK.

          Как вы думаете, что в данном случае лучше всего использовать\предпринять?

          Comment

          • zalex_ua
            Senior Member
            Zabbix Certified Trainer
            Zabbix Certified SpecialistZabbix Certified Professional
            • Oct 2009
            • 1286

            #6
            Anth0ny, Поддерживаю тебя. Сам еще не вкурил как сделать то о чем ты спрашиваешь хотя именно это и мне нужно также (я как погрузился в процесс помощи разработчикам так не могу оттуда "вынырнуть" и занятся реальной настройкой).
            Точно знаю если ты будешь опрашивать журнал без фильтрации на стороне клиента то любое событие с типом например Уведомление (тоесть отличительное от Ошибки), переведет триггер в состояние FALSE если перед этим он установился в TRUE в результате события Ошибки. Это конечно не решение, поэтому нужно копать.
            Где то я уже видел, читал по поводу как "вручную" переводить триггер в FALSE но помню это были мучения.
            Вот почитай http://www.zabbix.com/forum/showthre...light=Eventlog
            Не мешало бы разработчикам написать какой нибудь How To по реальной работе с Евентлогом.

            Comment

            • Anth0ny
              Member
              • Nov 2009
              • 85

              #7
              Согласен, в плане мониторинга логов нововведений - достаточное количество а вот документации по ним- кот наплакал...

              Приходится почти всё выяснять экспериментальным путём. И это оченно жаль. Много времени уходит.

              Мысль вот какая: возможно есть макрос, который определяет текущее состояние эвента. Т.е., может быть можно реализовать что то вроде:

              1) поступили данные от item (eventlog) в которых есть то что нам нужно ловить, например это ЛЮБАЯ запись типа Error из лога System.

              2) триггер увидив что severity=error создаёт эвент типа high, отсылает мыло (если настроено) и помещает запись о проблеме в дашборд (последние 20, или лучше для таких целей создать отдельный вью).

              дальше всё как с обычным эвентом, спамим через указанные в эскалации промежутки.

              3) а вот дальше... админ, увидев мыло и заглянув в дашборд ПОМЕЧАЕТ issue как Acknowledged и решает проблему на сервере, с которого пришло...

              И вот тут то и должна проходить наша обработка: нужно использовать что-то типа "nodata", чтобы через указанный промежуток времени процессинг мониторинга переопрашивал состояние сработавшего триггера. И как только им обнаруживается, что issue=acknowledged, то
              процессинг должен прекращаться (триггер помечается как OK'ейный).

              Надо искать аналог .nodata. для состояния триггера типа "Acknowledged".

              Comment

              • Anth0ny
                Member
                • Nov 2009
                • 85

                #8
                сейчас я пользуюсь выражением...

                {Template_Windows_EventLogs:eventlog[Application,,Error,,,100].logseverity(4)}=4&{Template_Windows_EventLogs:eve ntlog[Application,,Error,,,100].nodata(30)}=0

                ... которое позволяет обрабатывать поступающие записи из эвентлогов.

                единственный его недостаток в том, что оно автоматом помечает триггер сборщика эвентов как "ОК", а значит сработавший триггер не висит в Issues: Zabbix просто выполняет сопоставленный severity "High" экшен (послать мылом).

                можно ли в триггере (а точнее КАК) использовать: {TRIGGERS.UNACK} , {TRIGGER.EVENTS.UNACK}?
                Last edited by Anth0ny; 28-05-2010, 13:56.

                Comment

                • zalex_ua
                  Senior Member
                  Zabbix Certified Trainer
                  Zabbix Certified SpecialistZabbix Certified Professional
                  • Oct 2009
                  • 1286

                  #9
                  может быть это как то поможет https://support.zabbix.com/browse/ZBX-2385 ? это появится в 1.8.3 вот-вот
                  Я еще не очень разбираюсь в построении тригеров поэтому не могу сказать помет ли оно хоть как-то.

                  Comment

                  • Anth0ny
                    Member
                    • Nov 2009
                    • 85

                    #10
                    Originally posted by zalex_ua
                    может быть это как то поможет https://support.zabbix.com/browse/zbx-2385 ? это появится в 1.8.3 вот-вот
                    Я еще не очень разбираюсь в построении тригеров поэтому не могу сказать помет ли оно хоть как-то.
                    я ещё очень надеюсь что это будет доступно из выражений триггеров...

                    Comment

                    Working...