every

A variable that equals the value of an item would be useful for this kind of scenario.

For example if you have set a description for an interface on a switch, this can be available through the ifAlias or the ifDescr for the given interface. So being able to reference the value of ifAlias.1 in the title for interface 1's graph or alerts for interface 1 would be a definite improvement, and reduce the amount of manual tuning required.

similar to ZBXNEXT-242

This feature is REALLY needed for a large network environment, there is a functional patch for 1.8.2 according to the forum. Please implement this into stock release as soon as possible. It's a shame it isn't there already.

Most wanted/voted feature, this must be worth something?

There is no Patch for this problem. I found one in the Forum but it dosen´t work on Zabbix 1.8.2. I hope a fix comming soon.

I want this functional.

the same -> I want this functional.

flooding the issue with comments isn't helpful - to express support for it, there's the voting functionality

Please also consider enabling the

macro too.

richlv - Are you implying that voting is helpful? That's funny, because it doesn't appear that it's helping this issue at all. It's unfortunate that this doesn't even appear to be on the roadmap. I'm not sure how to view it, but I think you'd be hard-pressed to find another ZBXNEXT with more votes and watchers. At least change this to "won't fix" or "won't implement" if that's the case, so we can all stop waiting for it.

I voted for this feature quite a long time ago and I have been really eager to see this implemented in the upcoming releases.

I strongly think that this would make quite a difference in my daily job as it would allow my team and I to be much more productive in getting hundredth of graphs related to switch ports inoming/outgoing traffic items to update dynamically based on their items switch port descriptions.

This is really just one of the many applications you can achieve by implementing this feature, and it should not be underestimated IMHO.

At the moment I have to give generic names to all graphs in my switch templates, this leads to some difficulties in tracking down which host is represented in a specific graph. This is becoming increasingly annoying as it happens quite often that before we find the graph we first have to check the switch configuration to actually know what is connected to a specific switch port.

@Matteo Cerutti: I couldn't agree more. This would make creating templates much simpler and reduce the ambiguity of how items and triggers are managed.

I have to agree. The inability to, essentially, correlate items between graphs, etc., has been a major problem. To be able to, for instance, have graphs, etc., created and referenced by the description on an interface, is a critical need. I've managed to introduce zabbix into several environments. If its server heavy, its loved. If its network infrastructure heavy, its rejected because of this reason alone.

Right now i'm trying to introduce zabbix at a multinational company, and this can be a showstopper here too. Without this feature maintaining the correlation between the monitoring system and the actual monitored system becomes a lot more expansive in human resources, because every change in the network won't propagate automaticaly to the monitoring system and dual-maintanance has to be done for every change.

This is such a place that likes to get the highest support pack available for their solutions being used, and if the introduction of the system fails because of such a minor, but critical feature, then the zabbix team is doing nothing but losing funds.

For some previous versions a patch was lingering around on the internet for this issue, but at some point the development of zabbix broke that patch and never got fixed. So right now, everyone who would like to get a monitoring system that follows the configuration changes of the monitored system is depending on the central zabbix development, waiting for such a feature to be done.

Thanks for all your comments especially those giving real use cases for this functionality. Let me discuss it with devs, come up with a draft of high level specification and implement it once and forever. The specification will be available here for your comments.

heh, my piece

Oleksiy:

Alexei: This is most excellent news! I remember applying the patch and being rather disappointed with it, so I'm even happier that you are going to develop a long-term, encompassing solution to this major problem. You deserve a hug.

Have you guys seen this? http://www.zabbix.com/documentation/2.0/manual/discovery/low_level_discovery#discovery_of_snmp_oid_s

...it looks like SNMP OID discovery is making it into Zabbix 2.0, and is in the 1.9.2 builds! I've gotta test this...

Eric, related to LLD, don't forget to take a look to the attachment in this ZBXNEXT

In russian:

http://www.zabbix.com/forum/showthread.php?t=21926

Any progress on this ?

I'm guessing, no...

Simon - there is progress on this. Basically Zabbix 2.0 looks like it will have this functionality. Low level discovery means that interfaces names can be queried inside of Zabbix dynamically, and can be used in triggers, graphs and alerts.

See http://www.zabbix.com/documentation/2.0/manual/discovery/low_level_discovery#discovery_of_snmp_oid_s for screenshots of this new functionality.

Stuff like this will push Zabbix past other monitoring projects such as Cacti in terms of features and functionality

If this is moved into 2.0, will we also have the concept if instances? Such that we have 5 process we want to monitor, but each have something that differentiate them. In my circumstance they listen on differing ports. But I want to report the metrics as key.instance. Then I have problems in that data for a key is stored in three formats. As Is, Delta, and Delta per sec.
This makes exporting the metrics for additional analysis useless in general if the data is anything but "As Is". So every metric should be stored in the 'As Is" format, but displayed in the other formats, or even as more complicated formulas. And carry this to the triggers, graphs and alerts.

2.0 is coming, but no progress for this request even in trunk. Sadly...

As a workaround I use script that updates graph names using zabbix API.

Today I got a lot of graphs with names like "interface #<snmpindex>", so I need to look at the interface description to see for example that snmpindex 432 equals interface trk5 on my switch. This makes the low level discovery more or less useless in my opinion and it would add alot to the product if this got implemented with haste. We have been waiting for this functionality for over two years now please please please with sugar on the top, implement this feature!

Johnny - take a look at this... this is a reply to a forum thread (http://www.zabbix.com/forum/showthread.php?p=101435#post101435) that sort of addresses this problem:

I've kind of "hacked around" this problem by building discovery rules that are based on 'ifName' as the base discovery item (which gets snmpwalk'ed), and using

variable in graph titles.

Unfortunately this gives me an "either/or" situation with graph titles... I can have the interface name in the graph title, or I can have the interface description. What I really need would be the possibility of having both the interface name and description in the graph, but that's a feature request that's currently open (see ZBXNEXT-1: https://support.zabbix.com/browse/ZBXNEXT-1 ). Really if I could make the graph title the interface description, and then add a text item to the graph that uses ifName, where it would show the interface name in the graph 'legend' on the bottom that would be awesome - that would be the best of all worlds.

Right now, as yet another hacky thing I have a LLD item that uses "

-

" in the graphs that get generated from that rule, and another LLD rule using ifName as its "base" item.

After doing this, the items in Zabbix in my 'Graphs' tab show up like this:

1 - Gig1/1
1 - Sample Interface Description #1
2 - Gig1/2
2 - Sample Interface Description #2
3 - Gig1/3
3 - Sample Interface Description #3

This at least lets me figure out what interface has "ID #2," what its description is, and what the interface name is that correlated to that snmp index #.

Hope that helps! Vote for ZBXNEXT-1 and hopefully the devs can architect a final solution to having graph names have interface descriptions and interface names all in one shot

Heh, graph prototypes based on SNMP LLD are barely usable without this.

It's really strange that this feature is not mentioned on http://www.zabbix.com/development_services.php page (see "List of Recent Active Projects" table at the bottom). It means that
a) Nobody wants to pay for it (which, I believe, is unlikely)
b) Nobody knows that it can be sponsored in such a transparent way (required amount is known, % funded is visible)

So, if anyone can spend at least 500€/600$ on it — please fill `ZBXNEXT Sponsor Application Form` ("Suggest another ZBXNEXT into this table" button on the above mentioned page). I've already done that and hopefully ZBXNEXT-1 will appear there soon.
If 500€/600$ is too much, please wait for ZBXNEXT-1 appearance on Development Services page, minimum pledge likely will be 250€/300$ (based on current active projects).

I hope that with the community support (guys, there is 100+ votes and unknown amount of too-lazy-to-register people) this issue will be resolved shortly.

Similar to ZBXNEXT-581 (if I understand correctly, ZBXNEXT-581 (pt. 1) can be counted as subset of ZBXNEXT-1, in which I'm particularly interested in).

this issue is a bit of a mess right now, there are several possible ideas floating around. to make it a bit easier to follow, let's leave the most desired functionality here and split everything else in other issues. so what would that be ?
apparently it's referencing some item information in graph name (i assume trigger name is not relevant here). if so, how exactly should that be accomplished ?

I expect that we should be able to use item value either in a graph or trigger name, for example graph name would look like: "GigabitEthernet0/1

traffic"
Host linked to template Template_Cisco_3550-12G has item Template_Cisco_3550-12G:ifDescr-gi0-1 value = "customer A", then graph name for this host in web interface would look like "GigabitEthernet0/1 customer A traffic". When I change ifDescription on the cisco box, item ifDescr-gi0-1 gets new value containing new description and graph name always contains correct and updated value.
Same idea for trigger naming.

Actually I dream having a possibility to use trigger-expressions syntax in names of graphs and triggers.

I would preferable opt for something that works in combination with LLD from the get go. LLD is awesome, yet fairly useless in a network heavy environment. Nobody remembers what customer is on port #173 of aggr-sw-01. You need a decent name and description.

My one wish would be to use 'tigger like' expressions such as

or

in:

• graph names
• trigger names
• trigger comments

As trigger names are allready useable in actions, this should trickle down to actions aswell.

AFAICT that would solve both this issue and ZBXNEXT-581 (pt. 1) and allow foor incredibly dynamic use of LLD and completely automate all network monitoring to a point where adding the host and linking it to a LLD template would do all the rest for you. No need to edit graph names and keep them in sync with the actual real world situation.

I'll second that... This linking in properly with LLD would be really great. Whilst LLD is great, it needs further refinement to be of real use... Items need to update... I.e. if i change a port name on a switch then all the items created from that with SNMPVALUE in the description need to update too... Also an initial discovery straight after template is added followed by the normal discovery schedule.

Descriptions of switch port names, graphs and triggers is one use, but another we'd like to use this ( combined with LLD) is in backup monitoring... Iterate and pull out the job names and name the triggers with the job names to make it easy to identify failed jobs and adaptive to jobs and not require the naming to be strict to align with a set of existing triggers.

Yep, the main issue is inability to use ifDescr in the graph titles and similar cases. I agree with Michael that
> Actually I dream having a possibility to use trigger-expressions syntax in names of graphs and triggers.

ok, that didn't work too well

to make things at least somewhat manageable, i'll declare that this issue will be about :

supporting item referencing macros in graph titles. syntax :

as per http://www.zabbix.com/documentation/2.0/manual/appendix/macros/supported_by_location
only functions last, avg, max and min with seconds as arguments will be supported, same as for map labels.

anything else goes in other issues, many already linked to in other comments.

Took so many years. Thanks for all the supporters and partially the devs for trying to realize that this issue is very important for the users. We, who want to monitor things, this feature is top priority, and even version 0.1 should had it at the first place. As it seems, for developers, this is not so trivial. The reason for nobody wants to pay for this feature is that, this is such a basic one, that we just don't understand why it wasn't implemented at the startup of the project, we can't understand it. Such basic functionalities should be supported, and payed for. Once, this gone so far, that i've been payed instead of buying support for the product, because my template generator did the job right there at the time, without messing with devs and support not understanding the serious need for the feature.

Thanks everyone, who supports this idea.

Just to add, this is the Zabbix feature that my IT staff most missed when we migrate from Nagios/Cacti almost three years ago and the functionality isn't implemented yet! It's bad to think that such important and needed feature is available in tools less integrated/powerful than Zabbix.

That's true. Currently, Zabbix is not well-considered for network monitoring due to its poor snmp capabilities. 2.0 milestone meant a significant improvement but, unfortunately, network monitoring is still very far away from tools such as Nagios, Cacti, OpenNMS or Torrus...

Please add this feature. In OpenNMS it's very good implemented! Steal this!

OpenNMS, Graph section, Interfaces with ifDescr

The ability to open all Graphs for a particular interface

First draft of the specification is available at http://www.zabbix.org/wiki/Docs/specs/ZBXNEXT-1.

Frontend side ready for testing in r31249

(1) macros are not resolved in "Favorite graphs" widget

tomtom RESOLVED in r31319

sasha CLOSED

(2) macros like {{HOSTNAME}:item.func()} are not resolved

tomtom RESOLVED in r31324

sasha CLOSED

(3)

macro shouldn't be resolved in plain graph caption

tomtom RESOLVED in r31324

sasha CLOSED

(4) SQL statements are not properly formatted:

• too many whitespaces
• ASC directive should be removed
• select hostid ... should be select i.hostid
• zbx_dbstr($graphid): digital identifiers should not be escaped

tomtom RESOLVED in r31329

sasha CLOSED

(6) macros are not properly resolved

    we have two items:
      key                           | lastvalue
     -------------------------------+-----------
      trapl["{host:trapi.last(0)}"] | 1
      trapi                         | 5
    the {host:trapl["{host:trapi.last(0)}"].last(0)} macro resolves to {host:trapl["1"].last(0)}

tomtom unable to reproduce

Problem was with two macros in one name: ABC

{host:trapl["

"].last(0)}

tomtom RESOLVED in r31329

sasha REOPENED if the macro resolves in other macro that this macro too will be resolved. Macro should be opened only once

    we have two items:
      key                           | lastvalue
     -------------------------------+-----------
      trapc                         | {host:trapi.last(0)}
      trapi                         | 1
    "{host:trapc.last(0)} {host:trapi.last(0)}" resolves to "1 1"

tomtom RESOLVED in r31420

sasha REOPENED
Reproducible with graph name "

"

tomtom RESOLVED in r31517

sasha CLOSED

(7) whenever possible all SQL requests shall be bulk

tomtom RESOLVED in r31438

sasha CLOSED

(8) Incorrect regular expression "

". Should be "

".

tomtom RESOLVED in r31421

sasha CLOSED

(9) API::Template()->get(...) call is useless

tomtom RESOLVED in r31421

sasha CLOSED

(10) Item keys like key[][] does not work. Support of these keys are left for compatibility with Zapcat.

tomtom RESOLVED in r31421. Changes in documentation (http://www.zabbix.com/documentation/2.0/manual/config/items/item/key) about item keys should be considered.

sasha REOPENED please try

tomtom RESOLVED in r31704

sasha CLOSED

Ported history retrieval to separate function in r31426.

for everybody interested, current code can be tested at svn://svn.zabbix.com/branches/dev/ZBXNEXT-1

This is in time for 2.0.4 release?

it is scheduled for 2.2. let's not make 2.0 branch unstable by showing features down there

Server side tested. Sasha, please review my changes in r31696.

sasha Thanks! CLOSED

Just question :
In tittle can read : Fix Version/s: 2.1.0
I have download and install the last Pre-2.1.0 (alpha) but i cant see this feature in changelog.
Also, this modification will you present it in a 2.1 stable version?
Tks

the development isn't finished yet, "fix version" is the scheduled version.
this feature can be tested in development branch, as noted here : https://support.zabbix.com/browse/ZBXNEXT-1?focusedCommentId=70637&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-70637

2.1 will not be stable release, it will be development release for 2.2, which will include this feature

Hello, I want to test this new feature and i install the svn version.
my scenario : monitor only switch with "ifOperStatus = up" and display in graph the ifAlias name.

• My discovery rule is ok
• I have 3 items prototype :
  1: traffic in (ifInOctets with key : ifInOctets[ {#SNMPINDEX}] )
  2: traffic out (ifOutOctets with key : ifoutOctets[{#SNMPINDEX}

  ] )
  3: Alias name (IfAlias with key : ifAlias[

  {#SNMPINDEX}] )
  
  
  My problem: what to put in the name of the graph ?
  I test :
  {host:ifAlias[{#SNMPINDEX}

  ].last(0)} but the name is not ok.

Tks for your help

(16) move graph label macro resolving functionality from CGraphMacroResolver class to CMacrosResolver class.

tomtom RESOLVED in r32958, r32962

jelisejev Please correct the following issues:
1. Rename CMacrosResolverHelper::resolveGraphLabel() to resolveGraphName();
2. Implement type support for CMacrosResolver::resolveGraph();
3. Format PHP-doc comments.

tomtom RESOLVED in r33168

jelisejev CLOSED.

(17) Method resolveGraph() as resolveTexts() and resolveTrigger() must support batch data processing.

tomtom RESOLVED in r33175
Eduards CLOSED

(18) Method resolveGraph() must be private

tomtom RESOLVED in r33168
Eduards CLOSED

(19) Variable $data['str'] can be renamed to $data['text'] to be consistence with CMacrosResolver variable name styles. Also variable $str is redundant in resolveGraph().

tomtom

• resolveTrigger() has no 'text' key in parameter $data, but has one of 'description', 'comments' or 'description', so there is no reason to change 'str' to 'text'
• $str is necessary in resolveGraph()

Nothing to resolve.
Eduards CLOSED

(20) Please try to use constance to define preg_match_all string.

tomtom RESOLVED in r33177. Did not replace 'last|max|min|avg' and '[0-9]+[smhdw]?' because these values are method specific and they describe supported graph name macros.
Eduards CLOSED

(21) Typo in line:
$posInItemList = ($position === '') ? 0 : $posInItemList = $position - 1;

tomtom RESOLVED in r33291
Eduards CLOSED

(22) Blank line should appear before block comments. (https://www.zabbix.org/wiki/Docs/specs/coding_style#Blank_lines)

tomtom
There are no block comments in my code, except PHPDoc.
For block comment reference see: http://en.wikipedia.org/wiki/Comment_(computer_programming).
And if there would, it would be highly appreciated to mention line numbers.

(29) Updated documentation:

• https://www.zabbix.com/documentation/2.2/manual/appendix/macros/supported_by_location

<richlv> to be updated : whatsnew

martins-v an entry added: https://www.zabbix.com/documentation/2.2/manual/introduction/whatsnew220#referencing_item_values_in_graph_names

<richlv> changed function formatting slightly, looks good to me otherwise
CLOSED

Available in version pre-2.1.0 (trunk) r35221.

(30) HTML entities are shown in resolved macros, i.e. spaces are shown as &nbsp; entity.

mysql> select i.lastvalue from items i, hosts h where i.hostid=h.hostid and i.key_ like 'system.uname' and h.host = 'New host';
+---------------------------------------------------------------------------------------------------------+
| lastvalue                                                                                               |
+---------------------------------------------------------------------------------------------------------+
| Linux martins-v 2.6.38-16-generic #67-Ubuntu SMP Thu Sep 6 18:00:43 UTC 2012 i686 athlon i386 GNU/Linux |
+---------------------------------------------------------------------------------------------------------+
1 row in set (0.01 sec)

Graph configuration:

Monitoring->Graphs:

tomtom RESOLVED in r35390

sasha CLOSED

(31) Configuration->Maps: "Map image update failed" caused when using simple macros like

in map labels

Monitoring->Maps: Broken map image

tomtom Unsuccessful merging. RESOLVED in r35400

sasha Thank you! It was a my merge. CLOSED

Fixed in 2.1.0 r35412

Seems like graph name created with LLD and macro is limited to 20 characters. Item type is text.

I don't have this issue if I create graph manually.

Matjaž, can you please re-test this with the latest version, and, if reproducible, file a new bugreport ?
thanks

I retested with revision 36810. It's the same.

please create a new bugreport then, thanks

done...

https://support.zabbix.com/browse/ZBX-6779

Halleluiah! Now we just need to get the tweaks described here: http://sysnet-adventures.blogspot.fr/2014/02/zabbix-display-network-interface.html in the default SNMP template.