Ad Widget

Collapse

Macro Behavior

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • Scott75
    Junior Member
    • Dec 2019
    • 6

    #1

    Macro Behavior

    Hi everyone...this is a follow-up to a post I made a few weeks ago regarding macros in media types...

    I was working on a webhook media type, but getting everything I want to accomplished in javascript is proving problematic. So I decided to switch to a script media type; however, the macros don't resolve the same way the do with the webhook media type.

    Specifically, none of my system or host macros resolve. I have confirmed (by creating Zabbix log entries) that everything worked as a webhook; however, sending the command line arguments to a file to review in the script shows the name of the macro, not the value.

    Is it normal for the different media types to behave this way?

    Thanks,

    Scott
  • gert.derouck
    Member
    • Jan 2020
    • 69

    #2
    Hi, if i'm not mistaking i think you can only use the 3 '{ALERT.*}' macro's in the script media type.

    Comment

    • Scott75
      Junior Member
      • Dec 2019
      • 6

      #3
      Originally posted by gert.derouck
      Hi, if i'm not mistaking i think you can only use the 3 '{ALERT.*}' macro's in the script media type.
      Hmm...I'm not really seeing how you can get much value with customizing the media types if you can't pass any information about a trigger to the media type.

      Section 8 of the appendix states that user defined macros should be available in "Trigger-based notifications and commands", which is the case in this scenario (trigger fires caught by an action who's single operation is to call the media type).

      And it works for the Webhook media type...so it seems either it shouldn't work for the webhook, or it should work for both, nonetheless, it's inconsistent...

      Comment

      • Hamardaban
        Senior Member
        Zabbix Certified SpecialistZabbix Certified Professional
        • May 2019
        • 2713

        #4
        As far as I understand, 3 macros are used in notifications as gert.derouck wrote, and the values of these macros are determined in the “Operations block” of “Actions” section where it is possible to use other macros

        Comment

        • Scott75
          Junior Member
          • Dec 2019
          • 6

          #5
          Originally posted by Hamardaban
          As far as I understand, 3 macros are used in notifications as gert.derouck wrote, and the values of these macros are determined in the “Operations block” of “Actions” section where it is possible to use other macros
          That's essentially what I wound up doing. I replaced the message in the action with a JSON formatted string including all my macros and pass that to the script and decode in the script. Seems to work fairly well (so far)...

          I'd really still like to know what's up with the differences in handling between script media types and webhook media types. Seems like a bug to me.

          Comment

          • tim.mooney
            Senior Member
            • Dec 2012
            • 1427

            #6
            Originally posted by Scott75
            I'd really still like to know what's up with the differences in handling between script media types and webhook media types. Seems like a bug to me.
            I don't know that I would call it a bug, more like a legacy design deficiency.

            Script types have been around for a long time, and when they were added to Zabbix, they were unfortunately designed so that not much information is sent to them. Webhooks are much, much more recent, and I think the Zabbix designers realized that to be useful, there needs to be a lot more information available to the hook.

            I said in another response on these forums this past week that I wish there were a new type added called something like "Script (data on stdin)" that is a script type that gets the contents of the trigger message (formatted however we want, with whatever trigger macros we add to the message) sent to the script on stdin. The script could parse it and make decisions based on that. This allows for a lot more flexibility than the current limits of the script type.

            Comment

            Working...