[ZBXNEXT-2272] Support {EVENT.ID} in frontend scripts Created: 2014 Apr 18 Updated: 2022 Sep 15 Resolved: 2022 Sep 15 |
|
Status: | Closed |
Project: | ZABBIX FEATURE REQUESTS |
Component/s: | Frontend (F) |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Change Request | Priority: | Minor |
Reporter: | Gustavo Michels | Assignee: | Zabbix Development Team |
Resolution: | Duplicate | Votes: | 2 |
Labels: | macros, scripts | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
|
Description |
I'd like to leverage the frontend scripts (https://www.zabbix.com/documentation/2.2/manual/web_interface/frontend_sections/administration/scripts) to perform more complex actions, which could be, for example, based on the triggerid/itemid. Currently just a handful of macros are exposed: {HOST.CONN}, {HOST.IP}, {HOST.DNS}, {HOST.HOST}, {HOST.NAME} By exposing the {EVENT.ID} macro, it would be possible to script something that would gather the triggerid/itemid and act upon those. |
Comments |
Comment by richlv [ 2014 Apr 19 ] |
these scripts operate on host level, and event id is quite different - it makes sense for an alert, as that is based on the event. |
Comment by Gustavo Michels [ 2014 Apr 21 ] |
I understand what you mean as it wouldn't make sense to add event data to a host-only interaction, however my idea was to extend the functionality for those scripts, so they could be more powerful. In my case, for example, I need to use history data for the specific event the alert is raised. I already have an regular action set for those events, but there are cases when I want to have an ad-hoc test run, pretty much like a ping test, to help troubleshooting. Surely I have other tools to perform the test, but it would be great to have a central location in Zabbix. Of course exposing a bigger set of macros like items, triggers and history might not seem plausible, but most likely there is an event associated to the availability of the little context menu where the scripts appear. By using the event id we can script something that will gather the information we need using the API and then process that the way we need. We just need something that would correlate with the trigger that was raised, so I thought the easiest and simplest one would be the event id. |
Comment by richlv [ 2014 Apr 21 ] |
but what if a host has 10 active triggers right now ? well, long term there could be a feature where clicking a host with problems opens a list of all active triggers right there, and then trigger urls would work on any of them with EVENT.ID etc... but that's a more serious redesign |
Comment by Gustavo Michels [ 2014 Apr 21 ] |
You could make the trigger name link a sub-menu for possible actions, one of them being opening whatever is in the URL field for the trigger, then the frontend scripts. Pretty much the same way it happens when clicking on the host, there would always be a menu. I understand it's probably a more serious redesign, but I think it could be a nice feature. And of course then more macros could be exposed like TRIGGER.ID, ITEM.ID and so on. |
Comment by richlv [ 2014 Apr 21 ] |
when you say "trigger name", what do you refer to ? i hope not the problem name that is displayed below host element if there's one problem only. |
Comment by Gustavo Michels [ 2014 Apr 21 ] |
I mean the trigger name as when it appears in Monitoring>Dashboard (under "Issues") or Monitoring>Events (under "Description"). Although we use maps (and the problem name feature) it's normally on a big screen and no one interacts with it, so I'm not thinking on using the new feature on maps. On the Events page, you already have a sub-menu available which contain trigger and history related actions, so it could have a scripts portion as well. |
Comment by richlv [ 2016 Mar 22 ] |
other macros have been asked to be supported in global scripts in these issues :
|
Comment by Ivo Kurzemnieks [ 2022 Sep 15 ] |
With Zabbix 6.4 (See |