Ad Widget

Collapse

Одно оповещение в 15 минут с текстом из строки лога.

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • andrey_arj
    Junior Member
    • Apr 2021
    • 7

    #1

    Одно оповещение в 15 минут с текстом из строки лога.

    Добрый день! Прошу помочь.

    Возникла потребность делать не более 1 оповещения раз в 15 минут исходя из данных в текстовом логе (+в тексте оповещения нужен сам текст строчки из лога). Если за 15 минут хотя бы один раз появляется сообщение в логах с уровнем Fatal – высылать только одно оповещение с текстом из лога в эти 15 минут (самое первое, самое последнее, из середины - без разницы, любое сообщение в этот временной промежуток). Если не было ни одного сообщения с уровнем Fatal за 15 минут – ничего не делать.

    Почему именно так: если высылать все сообщения подряд, то можно заспамить (был случай 10 тыс. фатальных ошибок в логе за один день). Если высылать только в первый раз, когда событие случилось (trigger event generation mode = Single), то можно пропустить повтор проблемы через несколько часов\дней, не всегда есть возможность вручную изменить статус триггера, да и желания вручную менять статус триггера тоже нет (при этом сообщения Fatal - Info могут чередоваться между собой в логе через каждую секунду в течение суток, и делать Recovery в Trigger по уровню ошибки в логе бесполезно).

    Более конкретно:
    Сервер zabbix 5.0.9, активный агент zabbix, читает логи из файла. Пример лога:
    {"time":"2021-04-19T13:49:03.610Z","level":"INFO","host":"host1","m sg":"Соединение: попытка 3 из 3"}
    {"time":"2021-04-19T13:49:03.610Z","level":"INFO","host":"host1","m sg":"Соединение: попытка 2 из 3"}

    {"time":"2021-04-19T13:49:06.890Z","level":"FATAL","host":"host2"," msg":"Таймаут: таймаут получения данных"}


    Как сейчас реализовано - через log.count:
    Создан item с update interval = 15m, key:
    log.count["D:\Logs\log_json.log","Fatal|FATAL"]
    На основании него создан триггер с event generation mode = multiple.

    Данное решение не устраивает, потому что в тексте оповещения нет самого сообщения из лога, а только количество посчитанных строк с фатальным условием (за 15 минут). Пример оповещения:
    Problem: _Log Fatal Count Trigger
    Problem started at 17:10:03 on 2021.04.18
    Problem name: _Log Fatal Count Trigger
    Host: host1
    Severity: Information
    Operational data: 2
    Original problem ID: 74918

    Пытался сделать с помощью настроек Steps в Action ; с помощью nodata(); recovery expression в триггер – сделать single триггер и выключить его через 15 минут; через custom intervals в item. Ни один способ не привел к успешному результату, хотя вроде простой запрос.
  • Kos
    Senior Member
    Zabbix Certified SpecialistZabbix Certified Professional
    • Aug 2015
    • 3404

    #2
    • Сделать элемент данных, который будет собирать только строки, содержащие подстроку "FATAL", например:
    Code:
    log["D:\Logs\log_json.log","\"FATAL\""]
    • На этот элемент данных навесить триггер, который будет гасить его через 15 минут по таймеру:
    Code:
    {Host:log["D:\Logs\log_json.log","\"FATAL\""].nodata(15m)}=0
    • Recovery expression и Multiple event generation в триггере НЕ включать.
    Вроде, так.

    Comment

    • andrey_arj
      Junior Member
      • Apr 2021
      • 7

      #3
      Kos, спасибо . Уже безуспешно пробовал такой вариант ранее (если верно понял). Создавал триггер (см. картинку).

      В триггере указан для тестирования уровень Fatal+Info, чтобы как раз проверить тот случай, когда фатальные ошибки валятся кучей. Данный триггер конкретно в моей реализации плодит по одной ошибки на каждую строку (100 сообщений лога = 100 problems = 100 оповещений в итоге)
      Т.е. в этом варианте 15 минут вообще нигде не используются, такое ощущение что этот параметр вообще игнорируется. Возможно, конечно, не туда вписал условие

      Click image for larger version

Name:	1234.PNG
Views:	219
Size:	23.2 KB
ID:	423108




      Comment

      • andrey_arj
        Junior Member
        • Apr 2021
        • 7

        #4
        А, поторопился - надо поменять на Single (вместо Multiple), сейчас тестирую...

        Comment

        • andrey_arj
          Junior Member
          • Apr 2021
          • 7

          #5
          Kos, выставил Single, в этом случае (когда фатальные ошибки валятся подряд без остановки), триггер отрабатывает ровно один раз (в самый первый раз) и висит в этом состоянии всегда. Т.е. если на основании него настроить оповещение, то ни через 15 минут, ни через час, ни через день второго оповещения не придет. Второе оповещение придет только если вручную закрыть проблему (close problem). Либо я что-то не так делаю, конечно, но пока безрезультатно.

          Comment

          • Kos
            Senior Member
            Zabbix Certified SpecialistZabbix Certified Professional
            • Aug 2015
            • 3404

            #6
            Originally posted by andrey_arj
            Kos, выставил Single, в этом случае (когда фатальные ошибки валятся подряд без остановки), триггер отрабатывает ровно один раз (в самый первый раз) и висит в этом состоянии всегда. Т.е. если на основании него настроить оповещение, то ни через 15 минут, ни через час, ни через день второго оповещения не придет. Второе оповещение придет только если вручную закрыть проблему (close problem). Либо я что-то не так делаю, конечно, но пока безрезультатно.
            Да, именно так. Насколько я понял из поставленной задачи, именно это и требовалось: посылать следующее письмо только при _следующей_ проблеме:
            Если высылать только в первый раз, когда событие случилось (trigger event generation mode = Single), то можно пропустить повтор проблемы через несколько часов\дней
            А так - да, при таких настройках будет высылаться одно уведомление до окончания проблемы. Признак окончания проблемы - отсутствие новых записей в логе в течение N минут (в данном случае N=15). Пока проблема не решена, она будет висеть на экране проблем в веб-консоли Zabbix-а.
            Если нужны повторные оповещения, то можно что-то "наворачивать" на эту тему дополнительно. Самое простое - на уровне Action-а поставить дополнительные шаги через нужный интервал времени.

            Comment

            • andrey_arj
              Junior Member
              • Apr 2021
              • 7

              #7
              На данный момент в принципе функцию nodata() никак не могу использовать в триггерах на основании логов. Хотел поставить ее в recovery - не отрабатывает. Пока еще не потерял надежду, но вероятно, что это открытый баг zabbix (и заявленный функционал nodata не отрабатывает на логах):




              https://stackoverflow.com/questions/...detect-no-data

              Буду дальше конечно копать.

              Comment

              • andrey_arj
                Junior Member
                • Apr 2021
                • 7

                #8
                Итак, нашел решение.
                https://blog.zabbix.com/close-proble...bix-api/12461/

                Не совсем тривиально, но это именно то, что надо.

                Выводы следующие: функция nodata() с чтением логов не работает. Вообще не работает ни в каком виде.


                Пытался реализовать костыльный nodata() через log.count. Т.е. считать раз в период кол-во записей, если 0, то закрывать триггер. Но log.count в recovery триггера тоже не отрабатывает, проблема не закрывается.

                Найденное решение по ссылке подходит идеально:
                https://blog.zabbix.com/close-proble...bix-api/12461/

                Не надо городить никакой огород из nodata(), recovery и т.д. Триггер в итоге закрывается через API в Action (вторым шагом через 15 минут после отправки сообщения).
                Делается обычный триггер Single, без Recovery. На него настраивается Action (самый обычный). Просто второй операцией в Action выставляется действие скрипта (step duration = 15m, см. ссылку).
                Zabbix высылает сообщение по обычному триггеру, ждет 15 минут, выполняет 2 шаг, в котором проблема закрывается.

                Click image for larger version

Name:	zabbix command.PNG
Views:	209
Size:	113.4 KB
ID:	423153










                Comment

                • Kos
                  Senior Member
                  Zabbix Certified SpecialistZabbix Certified Professional
                  • Aug 2015
                  • 3404

                  #9
                  Originally posted by andrey_arj
                  На данный момент в принципе функцию nodata() никак не могу использовать в триггерах на основании логов. Хотел поставить ее в recovery - не отрабатывает.
                  Условие в recovery проверяется только тогда, когда перестаёт выполняться основное условие. Поэтому жалоба по ZBX-16594 была совершенно правильно закрыта: это не баг, это так и работает.


                  Originally posted by andrey_arj
                  На данный момент в принципе функцию nodata() никак не могу использовать в триггерах на основании логов.
                  В чём проблема? Я же привёл пример, когда это используется. Единственное "но": она не совместима с режимом "Multiple event generation". На эту тему есть открытый много лет назад тикет (ещё с версии 2.0), которому всё никак не хватает голосов, чтобы быть реализованным. Но, вроде, для описанной вами задачи этот режим и не требуется.
                  Last edited by Kos; 20-04-2021, 11:23.

                  Comment

                  • andrey_arj
                    Junior Member
                    • Apr 2021
                    • 7

                    #10
                    Kos , спасибо еще раз. Решение в целом было найдено. Вы натолкнули меня на новые мысли. Nodata() и другие варианты - это все-таки некоторый костыльный обход решения, да, и я в меру своего знания плохо пониманию некоторые детали. На мой взгляд, данные функционал должен быть реализован именно в actions, т.к. связан непосредственно с рассылкой оповещений (когда оповещений становится слишком много). В итоге так и получилось, было найдено решение в actions, которое отвязано от триггеров и элементов данных. Решение вполне устраивает. Жаль, конечно, что оно не входит в базовые функции (опция "закрыть проблему после оповещения"), но это уже мелочи.

                    Comment

                    Working...