Ad Widget

Collapse

Custom intervals not working as expected

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • akemper
    Junior Member
    • Mar 2016
    • 10

    #1

    Custom intervals not working as expected

    Hi,

    I'm running Zabbix 3.0.3 @ Ubuntu 14.04. Recently I started using custom intervals with predefined scheduling for two newly added items. These items should check infrequent modifications of logfiles, precisely every Monday, Wednesday and Friday at 21:00.

    In the item definition I've selected Type=Scheduling with Interval="wd1,3,5h21". When looking at the eventlist of the corresponding item it is executed at the mentioned times, but also approx. 1.5h later, which I haven't defined at all and thereby ending up in an incorrect trigger state.

    Why does this subsequent execution take place and / or how can I fix this or might it even be a bug?

    Thx,
    Andreas
    Attached Files
  • mortuletti
    Member
    • May 2016
    • 76

    #2
    Hi Andreas!
    Look like item collecting data correctly and on time.
    Events is generated by Trigger. Please, attach problem definition expression here, and we will check.
    Thank you!
    Br, Alexander

    Comment

    • akemper
      Junior Member
      • Mar 2016
      • 10

      #3
      Hi,

      I've attached the trigger expression plus the event history.

      When looking at the events I noticed that the problem status always occurs 2h (7200s) after the respective file has changed.
      The file change is actually intended. But it should not be checked again at 22:xx, only at 21:00 to see if it has changed between 19:00 and 21:00.

      Obviously my trigger is wrong there, but what would be the correct one for this purpose??

      Thx,
      Andreas
      Attached Files

      Comment

      • mortuletti
        Member
        • May 2016
        • 76

        #4
        So,
        3 times a week Zabbix check file modification time stamp;
        We need to compare it with local server time once per check only. (now Zabbix compare received value all the time, so we get problem conditions in 2h after modification time received by item)
        Correct?

        I'll think how to define problem conditions.

        Br, Alexander

        Comment

        • akemper
          Junior Member
          • Mar 2016
          • 10

          #5
          No, because the file is typically modified three times a week between 19:00 and 21:00 the timestamp for comparison to my understanding also needs to be updated accordingly.

          What I did now is using *.fuzzytime(7200)=0 instead. Let's see what happens later on...

          Comment

          • mortuletti
            Member
            • May 2016
            • 76

            #6
            Yes, file modification time received correctly and saved in to database.
            problem is, what we need to compare it with zabbix time just 3 times a week (after new value is received)
            I think about fuzzitime as well, but in this case most probably result will be exactly the same as it was before (let's see tomorrow)
            Br, Alexander

            Comment

            • akemper
              Junior Member
              • Mar 2016
              • 10

              #7
              Using fuzzytime(x) instead of now()-last(0) finally works well.

              Obviously the result of now() is continuously updated, even when the event is not explicitly scheduled. Not sure if this is a bug, but at least not the expected behavior.

              Comment

              • mortuletti
                Member
                • May 2016
                • 76

                #8
                Perfect!
                This is not bug. Previous solution was normal for situation when Item updated continuously. But as we checked data only sometimes we need to compare it only once per check.
                Hope I helped you a bit.
                Regards,
                Alexander

                Comment

                • akemper
                  Junior Member
                  • Mar 2016
                  • 10

                  #9
                  Yes, thanks for the support. The discussion was actually quite helpful!

                  BR,
                  Andreas

                  Comment

                  Working...