[ZBXNEXT-2278] Creation of a graph from an LLD graph prototype fails if using a simple macro in the graph title Created: 2014 Apr 24 Updated: 2017 Jun 28 |
|
Status: | Open |
Project: | ZABBIX FEATURE REQUESTS |
Component/s: | Server (S) |
Affects Version/s: | 2.2.3 |
Fix Version/s: | None |
Type: | Change Request | Priority: | Minor |
Reporter: | Raymond Kuiper | Assignee: | Unassigned |
Resolution: | Unresolved | Votes: | 8 |
Labels: | database, graphs, lld | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Description |
Since Zabbix 2.2 the use of simple macros in graph titles is supported. I'm now running into an issue with it. Int. Usg: {#SNMPVALUE} ({{HOST.HOST}:ifAlias["{#SNMPVALUE}"].last(0)}) This works perfectly fine for the case where the following values are returned: {#SNMPVALUE}: FastEthernet0/1 However, it does not work in these cases: {#SNMPVALUE}: Adaptive Security Appliance 'HA' interface {#SNMPVALUE}: Adaptive Security Appliance 'Management0/0' interface What does seem to work in these problem cases is changing the graph title to just this: Int. Usg: {#SNMPVALUE} I suspect the LLD graph creation fails on the qoutation marks within {#SNMPVALUE} in the simple macro, but I've not found any logging or proof that confirms this. |
Comments |
Comment by Alexander Vladishev [ 2014 Apr 25 ] |
Server can't create these graphs because length of graph titles is too long (> 128 chars). It can be fixed only in the next major releases since requires changes in a database structure. I move the issue into a ZBXNEXT project. |
Comment by Raymond Kuiper [ 2014 Apr 25 ] |
Thanks Alexander, at least now I know what the problem is! |
Comment by brendon [ 2016 Oct 14 ] |
Is there a workaround for this. I'm running into this exact problem as well on the exact same hardware as Raymond. I'm on v3.2.1 |
Comment by Mike Yurlov [ 2016 Nov 03 ] |
This small feature must be fixed in new release. IF-MIB::ifDescr.1 = STRING: D-Link DGS-3120-24SC R3.00.B02 Port 1 on Unit 1 and "Traf {#SNMPVALUE} : {ifAlias{#SNMPVALUE}.last(0)}" expand to 137 chars length: In this case "simple macro in graph titles" supported, but not usable with ifDescr. Another VERY bad thing - Zabbix do not show any warnings. Graphs not created silently. Only debug log have error messave about "very long name" |
Comment by Mike Yurlov [ 2016 Nov 08 ] |
In Apr 2014 and 2.2.3 Alexander Vladishev promised fix this in new release, but It's still not fixed. 2017 is coming and 3.2 released, but graphs.name still varchar(128) |
Comment by Aleksandrs Saveljevs [ 2016 Nov 08 ] |
Not sure about a promise. If you mean the first comment above, then Alexander mentioned that it can only be fixed in major releases, no promise was made. |
Comment by Mike Yurlov [ 2016 Nov 08 ] |
Ok, maybe not promised. I think the following: Alter Table + some fix in code is an hours work, but add important usability in Zabbix product. As You understand, using ifAlias/ifDescr/HOST.NAME in all events/triggers/graph/names is very useful. Because any Zabbix user can get human-readeable message from interface like "4floor switch port 23 (office417) goes down", fast graph search in drop-down graph list, etc. In production Support engeneer (with Zabbix on desk) does not need connect to switch and check "what is port 23"? Support engeneer does not need go to switch and search "where is office417 port? It's port 23. Goto Zabbix graphs and search "Traffic for port 23". It should be available in one click. That's why Zabbix team should make an effort to do human-readeable descriptions/info interface. It's very power thing. This is my vision and I see some posts in Google about all visible names in Zabbix. Probably is not the ticket information, maybe Alexander Vladishev will read this. Thanks. |
Comment by Andrey Melnikov [ 2016 Nov 09 ] |
DLink switches is crap. Use other method to generate keys - in item prototypes use ifAdminStatus[Port{#SNMPINDEX}], ifAlias[Port{#SNMPINDEX}], ... etc in graphs - "Traf Port{#SNMPINDEX}: {ifAlias[Port{#SNMPINDEX}].last(0)}." And, if you not changing descriptions on interfaces frequently - better fetch ifAlias discovery[{#SNMPVALUE},IF-MIB::ifDescr,{#SNMPIFALIAS},IF-MIB::ifAlias] while interfaces discovered and use it later directly: "Traf Port{#SNMPINDEX}: {#SNMPIFALIAS}.". This save numbers of sql lookups when graphs is displayed. |
Comment by Mike Yurlov [ 2016 Nov 09 ] |
Andrew, thanks. IF-MIB based template is good multivendor template/solution. Even Cisco and Extreme may have long ifDescr. Extreme have |
Comment by Andrey Melnikov [ 2016 Nov 09 ] |
Use filter, Luke. When you discovery by {#SNMPVALUE},IF-MIB::ifDescr - use regexp "Port \d+" and vlan entries can't pass in. |
Comment by richlv [ 2016 Nov 09 ] |
please note that zabbix daemons support posix extended, thus \d might not work |
Comment by Mike Yurlov [ 2016 Nov 09 ] |
Andrey, I know. We need monitor ip interfaces with long ifAlias/ifDescr too |
Comment by romale [ 2017 Jun 07 ] |
I've this issue too with cisco asa upd. graph name in discovery: "{#SNMPVALUE} Traffic {{HOSTNAME}:ifAlias[ {#SNMPVALUE}].last(0)}" and no issue with "Cannot create graph: value "Adaptive Security Appliance 'GigabitEthernet0/0' interface Traffic {{HOSTNAME}:ifAlias[Adaptive Security Appliance 'GigabitEthernet0/0' interface].last(0)}" is too long", it's worked. snmpwalk -c public -v 2c 172.25.130.63 IF-MIB::ifAlias.1 snmpwalk -c public -v 2c 172.25.130.63 IF-MIB::ifDescr.1 Is it possible? |
Comment by romale [ 2017 Jun 28 ] |
May be, is to use discovery[ {#SNMPVALUE},IF-MIB::ifName] and not discovery[{#SNMPVALUE},IF-MIB::ifDescr] in LLD rule of the default "Template SNMP Interfaces" template? snmpwalk -On -v 2c -c public cisco_asa IF-MIB::ifName snmpwalk -On -v 2c -c public cisco_asa IF-MIB::ifDescr snmpwalk -On -v 2c -c public cisco_asr1000 IF-MIB::ifName snmpwalk -On -v 2c -c public cisco_asr1000 IF-MIB::ifDescr |