[ZBX-5386] Strange "return value" when item:db.odbc.select return NULL Created: 2012 Jul 31 Updated: 2017 May 30 Resolved: 2012 Aug 20 |
|
Status: | Closed |
Project: | ZABBIX BUGS AND ISSUES |
Component/s: | Server (S) |
Affects Version/s: | 2.0.1 |
Fix Version/s: | 2.0.3rc1, 2.1.0 |
Type: | Incident report | Priority: | Trivial |
Reporter: | Grzegorz Grabowski | Assignee: | Unassigned |
Resolution: | Fixed | Votes: | 0 |
Labels: | items, logging, mysql, odbc | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified | ||
Environment: |
VMWare server, 24GB RAM, 8 core CPU, Linux zabbix_vm 2.6.32-220.el6.x86_64 #1 SMP Wed Nov 9 08:03:13 EST 2011 x86_64 x86_64 x86_64 GNU/Linux, mysql Ver 14.14 Distrib 5.1.52, for redhat-linux-gnu (x86_64) using readline 5.1 |
Attachments: | 2.0.3rc1-29617-screen-1.png 2.0.3rc1-29617-screen-2.png 2.0.3rc1-29617-screen-3.png 2.0.3rc1-29617-screen-4.png 2.0.3rc1-29617-screen-5.png 2.0.3rc1-29617-screen-6.png 2.0.3rc1-29617-screen-7.png odbc-item.png zabbix_server.log.png |
Description |
When there is no rows in select statement And query return "null" value in zabbix_server.log, there are very suspicious logs. 16315:20120731:122403.447 item [GGSN40990B:db.odbc.select[EMSPort-22-1-RX]] became not supported: Received value [@?] is not suitable for value type [Numeric (unsigned)] and data type [Decimal] ' w In the same time: mysql> select * from events where device='GGSN40990B'; My odbc item for example: — Best Regards, |
Comments |
Comment by Grzegorz Grabowski [ 2012 Jul 31 ] |
Maybe its not trivial |
Comment by dimir [ 2012 Aug 10 ] |
Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBX-5386. Before this fix SQL queries of "Database monitor" items where not properly checked for:
In both cases an item became UNSUPPORTED (except for the null value for "Character" value type, which isn't probably correct) but the error message was provided only in case NULL value was received for Integer value type. An error message was (as provided in issue description): item [db.odbc.select[...]] became not supported: Received value [@?] is not suitable for value type [Numeric (unsigned)] and data type [Decimal] In this case a "@?" is garbage resulting from receiving a NULL value from SQL query. The fix adds handling of such situations. In both cases an item becomes unsupported no matter what value type an item has. The error messages are respectively:
Also configure script was modified regarding building Zabbix server with unixODBC support. Some GNU/Linux distributions have unixODBC packages without odbc_config binary. Before the fix when building Zabbix server with unixODBC support if odbc_config binary was missing configure would result in an error. This was changed so that if odbc_config is missing we continue without additional CFLAGS and LDFLAGS with just additional -lodbc. At least on a Debian 6.0 this allowed successful compilation. |
Comment by Grzegorz Grabowski [ 2012 Aug 11 ] |
Hi, 6558:20120811:003243.919 item [d34:up.ldapstat[ {HOST.IP},acct-stop-current-rate]] became not supported: Received value [] is not suitable for value type [Numeric (unsigned)] and data type [Decimal]6558:20120811:003243.919 item [d34:up.ldapstat[{HOST.IP} ,auth-accept-current-rate]] became not supported: Received value [] is not suitable for value type [Numeric (unsigned)] and data type [Decimal] 6558:20120811:003243.920 item [d34:up.ldapstat[{HOST.IP} ,proxy-acct-request-current-rate]] became not supported: Received value [] is not suitable for value type [Numeric (unsigned)] and data type [Deci 6556:20120811:003248.984 item [mmsgtv2:localsnmp[1.3.6.1.4.1.11080.301.5.1.27.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became not supported: Received value [] is not suitable for value type [Numeric (unsign 6559:20120811:003324.479 item [mmsgtv1:localsnmp[1.3.6.1.4.1.11080.301.5.1.9.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became not supported: Received value [] is not suitable for value type [Numeric (unsigne 6557:20120811:003329.612 item [mmsgtv2:localsnmp[1.3.6.1.4.1.11080.301.5.1.37.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became not supported: Received value [] is not suitable for value type [Numeric (unsign 6557:20120811:003329.613 item [mmsgtv2:localsnmp[1.3.6.1.4.1.11080.301.5.1.4.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became not supported: Received value [] is not suitable for value type [Numeric (unsigne 6556:20120811:003334.551 item [mmsgtv2:localsnmp[1.3.6.1.4.1.11080.301.5.1.6.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became not supported: Received value [] is not suitable for value type [Numeric (unsigne 6559:20120811:003339.651 item [mmsgtv2:localsnmp[1.3.6.1.4.1.11080.301.5.1.7.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became not supported: Received value [] is not suitable for value type [Numeric (unsigne 6559:20120811:003339.651 item [mmsgtv3:localsnmp[1.3.6.1.4.1.11080.301.5.1.9.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became not supported: Received value [] is not suitable for value type [Numeric (unsigne 6556:20120811:003425.083 item [mmsgtv3:localsnmp[1.3.6.1.4.1.11080.301.5.1.12.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became not supported: Received value [] is not suitable for value type [Numeric (unsign 6559:20120811:003520.916 item [mmsgtv3:localsnmp[1.3.6.1.4.1.11080.301.5.1.2.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became not supported: Received value [] is not suitable for value type [Numeric (unsigne 6557:20120811:003532.236 item [mmsgtv2:localsnmp[1.3.6.1.4.1.11080.301.5.1.2.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became not supported: Received value [] is not suitable for value type [Numeric (unsigne 6556:20120811:003541.029 item [mmsgtv1:localsnmp[1.3.6.1.4.1.11080.301.5.1.2.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became not supported: Received value [] is not suitable for value type [Numeric (unsigne 6556:20120811:003541.030 item [mmsgtv1:localsnmp[1.3.6.1.4.1.11080.301.5.1.23.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became not supported: Received value [] is not suitable for value type [Numeric (unsign 6557:20120811:003547.433 item [mmsgtv3:localsnmp[1.3.6.1.4.1.11080.301.5.1.25.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became not supported: Received value [] is not suitable for value type [Numeric (unsign 6559:20120811:003552.286 item [mmsgtv3:localsnmp[1.3.6.1.4.1.11080.301.5.1.27.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became not supported: Received value [] is not suitable for value type [Numeric (unsign 6559:20120811:003552.287 item [mmsgtv3:localsnmp[1.3.6.1.4.1.11080.301.5.1.37.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became not supported: Received value [] is not suitable for value type [Numeric (unsign 6558:20120811:003556.740 item [mmsgtv3:localsnmp[1.3.6.1.4.1.11080.301.5.1.38.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became not supported: Received value [] is not suitable for value type [Numeric (unsign 6558:20120811:003601.888 item [mmsgtv3:localsnmp[1.3.6.1.4.1.11080.301.5.1.5.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became not supported: Received value [] is not suitable for value type [Numeric (unsigne ]] became not supported: Received value [] is not suitable for v This is for external check and odbc check. When I back to 2.0.2 everything back to normal. Its seems all value return null string .... |
Comment by dimir [ 2012 Aug 13 ] |
I have created a similar (I hope) external script: $ cat /etc/zabbix/externalscripts/snmp idx=$1 snmpget -c public -v 2c snmphost ifInOctets.$idx 2>/dev/null | awk ' {print $NF}' Added "External check" item with key "snmp[15]" and I get no "Not supported", the proper value is returned with development branch. Is that the way you have your external check? Could you also show the configured SQL query of "db.odbc.select[tx-in-text-files]"? |
Comment by Grzegorz Grabowski [ 2012 Aug 13 ] |
Hi, |
Comment by Grzegorz Grabowski [ 2012 Aug 18 ] |
I checked ones again for version 2.0.3rc1-29617 Except, item defined as on screen-1, (attached log as a screenshot and .txt) Item, you asked for is: but now there is no problem with this values. {$NAZWA} = "rmsc-h2" and this is a user macro of host. There still is problem with: 23988:20120818:142654.885 item [rmsc-h2:db.odbc.select[m-delivery-ind server-duration]] became not supported: Type of received value [6392613192574.000000] is not suitable for value type [Numeric (float)] (screen-1, screen-2, screen-3) The connected problem is that after your changes, the user parameter of one group of host stop working. This UP works in 2.0.2. This is Zabbix Agent (active) item. But I use a lot of user parameters in other host and it work properly. I checked this and you have screen-5 (log form zabbix_server.log), screen-4 (user parameter run as a key of zabbix_get run locally), screen-6 (user parameter run as a key of zabbix_get run remotely). Intresting thing is that this Items, after got "unsupported" never go supported again... Bests, |
Comment by dimir [ 2012 Aug 20 ] |
I'm sorry, but if you would have taken the dev branch you wouldn't be able to get 2.0.3rc1-29617. The dev branch is 2.0.3rc1-29542. Could you please get the development branch: svn://svn.zabbix.com/branches/dev/ZBX-5386 And build and test the server from there? Seems you are using trunk or 2.0, which do not contain the changes I made within this issue. |
Comment by Grzegorz Grabowski [ 2012 Aug 20 ] |
Hi I downloaded this: http://www.zabbix.com/downloads/nightly/pre-zabbix-2.0.3rc1-29632.tar.gz I don't use SVN. |
Comment by dimir [ 2012 Aug 20 ] |
Please note, that nightly builds never contain anything from development branches. The only way to test a development branch is to check it out from svn repository. Here, I have created the tarball for you from the development branch: http://www.2shared.com/file/lCO31S8m/zabbix-203rc1-ZBX-5386tar.html Please test that and report the results. |
Comment by Alexander Vladishev [ 2012 Aug 20 ] |
(1) the configure script shall give out an error if we set not the correct path to unix_odbc <dimir> RESOLVED in r29658 |
Comment by Grzegorz Grabowski [ 2012 Aug 20 ] |
OK, I checked. 11795:20120820:180348.355 item [dunczyk:up.ldapstat[ {HOST.IP},proxy-acct-request-current-rate]] became not supported: Received value [] is not suitable for value type [Numeric (unsigned)] and data type [Decimal]11795:20120820:180348.355 item [kwinto:up.ldapstat[{HOST.IP} ,acct-start-current-rate]] became not supported: Received value [] is not suitable for value type [Numeric (unsigned)] and data type [Decimal] 11795:20120820:180348.355 item [kwinto:up.ldapstat[{HOST.IP} ,auth-accept-current-rate]] became not supported: Received value [] is not suitable for value type [Numeric (unsigned)] and data type [Decimal] 11795:20120820:180348.355 item [kwinto:up.ldapstat[{HOST.IP} ,proxy-acct-request-current-rate]] became not supported: Received value [] is not suitable for value type [Numeric (unsigned)] and data type [Decimal] 11790:20120820:180417.847 housekeeper deleted: 186534 records from history and trends, 3000 records of deleted items, 0 events, 0 alerts, 0 sessions 11794:20120820:180434.604 item [mmsgtv2:localsnmp[1.3.6.1.4.1.11080.301.5.1.10.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became not supported: Received value [] is not suitable for value type [Numeric (unsigned)] and data type [Decimal] 11794:20120820:180505.126 item [mmsgtv2:localsnmp[1.3.6.1.4.1.11080.301.5.1.12.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became not supported: Received value [] is not suitable for value type [Numeric (unsigned)] and data type [Decimal] 11796:20120820:180535.372 item [mmsgtv3:localsnmp[1.3.6.1.4.1.11080.301.5.1.12.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became not supported: Received value [] is not suitable for value type [Numeric (unsigned)] and data type [Decimal] 11797:20120820:180550.433 item [GGSN20909C:db.odbc.select[EMSPort-27-2-TX]] became not supported: SQL query returned NULL value. 11796:20120820:180555.513 item [GGSN40990B:db.odbc.select[EMSPort-22-3-TX]] became not supported: SQL query returned NULL value. 11796:20120820:180555.513 item [GGSN20909C:db.odbc.select[EMSPort-22-3-RX]] became not supported: SQL query returned NULL value. 11796:20120820:180555.513 item [GGSN40990B:db.odbc.select[EMSPort-22-3-RX]] became not supported: SQL query returned NULL value. 11797:20120820:180600.513 item [GGSN20909C:db.odbc.select[EMSPort-27-3-TX]] became not supported: SQL query returned NULL value. snmp_build: unknown failure 11795:20120820:180605.539 item [GGSN40990B:db.odbc.select[EMSPort-22-1-RX]] became not supported: SQL query returned NULL value. 11795:20120820:180605.539 item [GGSN20909C:db.odbc.select[EMSPort-22-1-TX]] became not supported: SQL query returned NULL value. 11795:20120820:180625.948 item [mmsgtv2:localsnmp[1.3.6.1.4.1.11080.301.5.1.23.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became not supported: Received value [] is not suitable for value type [Numeric (unsigned)] and data type [Decimal] ]] became not supported: Received value [] is not suitable for value type [Numeric (unsigned)] and data type [Decimal] |
Comment by dimir [ 2012 Aug 20 ] |
The changes only affected odbc items. Your last logs show that all the mentioned odbc items are not supported because the queries return NULL values. I see nothing wrong here. As for userparameters and snmp items there were no changes made. |
Comment by Grzegorz Grabowski [ 2012 Aug 20 ] |
I understand what you say, BUT, 20762:20120820:182907.216 server #39 started poller #37 20817:20120820:182948.214 item [GGSN40990B:db.odbc.select[EMSPort-27-2-TX]] became supported 20820:20120820:182952.241 item [GGSN20909C:db.odbc.select[EMSPort-22-3-TX]] became supported 20820:20120820:182952.241 item [GGSN40990B:db.odbc.select[EMSPort-22-3-TX]] became supported 20820:20120820:182952.242 item [mmsgtv1:localsnmp[1.3.6.1.4.1.11080.301.5.1.2.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became supported 20820:20120820:182952.242 item [mmsgtv1:localsnmp[1.3.6.1.4.1.11080.301.5.1.6.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became supported 20820:20120820:182952.242 item [mmsgtv1:localsnmp[1.3.6.1.4.1.11080.301.5.1.8.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became supported 20820:20120820:182952.242 item [mmsgtv1:localsnmp[1.3.6.1.4.1.11080.301.5.1.12.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became supported 20820:20120820:182952.243 item [mmsgtv1:localsnmp[1.3.6.1.4.1.11080.301.5.1.23.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became supported 20820:20120820:182952.243 item [mmsgtv1:localsnmp[1.3.6.1.4.1.11080.301.5.1.26.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became supported 20820:20120820:182952.243 item [mmsgtv1:localsnmp[1.3.6.1.4.1.11080.301.5.1.38.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became supported 20820:20120820:182952.244 item [mmsgtv1:localsnmp[1.3.6.1.4.1.11080.300.3.2.0,{$SNMPP},{$SNMPC},{HOST.IP} ]] became supported 20820:20120820:182952.244 item [mmsgtv1:localsnmp[1.3.6.1.4.1.11080.300.3.3.0,{$SNMPP},{$SNMPC},{HOST.IP} ]] became supported 20820:20120820:182952.244 item [mmsgtv1:localsnmp[1.3.6.1.4.1.11080.300.3.8.0,{$SNMPP},{$SNMPC},{HOST.IP} ]] became supported 20820:20120820:182952.244 item [mmsgtv1:localsnmp[1.3.6.1.4.1.11080.300.4.7.0,{$SNMPP},{$SNMPC},{HOST.IP} ]] became supported 20820:20120820:183035.647 item [mmsgtv3:localsnmp[1.3.6.1.4.1.11080.301.5.1.2.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became supported 20820:20120820:183035.647 item [mmsgtv3:localsnmp[1.3.6.1.4.1.11080.301.5.1.25.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became supported 20820:20120820:183035.647 item [mmsgtv3:localsnmp[1.3.6.1.4.1.11080.301.5.1.27.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became supported 20820:20120820:183035.648 item [mmsgtv3:localsnmp[1.3.6.1.4.1.11080.301.5.1.37.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became supported 20820:20120820:183035.648 item [mmsgtv3:localsnmp[1.3.6.1.4.1.11080.301.5.1.4.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became supported 20820:20120820:183035.648 item [mmsgtv3:localsnmp[1.3.6.1.4.1.11080.301.5.1.6.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became supported 20820:20120820:183131.855 item [mmsgtv2:localsnmp[1.3.6.1.4.1.11080.301.5.1.12.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became supported 20817:20120820:183136.922 item [mmsgtv2:localsnmp[1.3.6.1.4.1.11080.301.5.1.23.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became supported 20817:20120820:183136.922 item [mmsgtv2:localsnmp[1.3.6.1.4.1.11080.301.5.1.26.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became supported 20817:20120820:183136.923 item [mmsgtv2:localsnmp[1.3.6.1.4.1.11080.301.5.1.3.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became supported 20817:20120820:183136.923 item [mmsgtv2:localsnmp[1.3.6.1.4.1.11080.301.5.1.38.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became supported 20817:20120820:183136.923 item [mmsgtv2:localsnmp[1.3.6.1.4.1.11080.301.5.1.5.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became supported 20817:20120820:183136.924 item [mmsgtv2:localsnmp[1.3.6.1.4.1.11080.301.5.1.7.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became supported 20817:20120820:183136.924 item [mmsgtv2:localsnmp[1.3.6.1.4.1.11080.301.5.1.9.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.IP} ]] became supported AND all userparameter, external scripts back to normal ... |
Comment by Grzegorz Grabowski [ 2012 Aug 20 ] |
When you will check this, made the external script or userparameter script with corect value, not null |
Comment by Alexander Vladishev [ 2012 Aug 20 ] |
Successfully tested. Please review my changes in r29638, r29659 and r29660. <dimir> Great, thanks! |
Comment by dimir [ 2012 Aug 21 ] |
Grzegorz, could you enable DebugLevel=4 and show lines related to one single item (non-odbc) in the logs that act differently in the development version and official 2.0.2? And attach the screenshot of that item configuration (or script contents). |
Comment by Grzegorz Grabowski [ 2012 Aug 23 ] |
Give me some time... this is production system, 20k items ... I don't know I can handle debug mode 4 |
Comment by dimir [ 2012 Aug 23 ] |
Fixed in pre-2.0.3 r29767, pre-2.0.1 r29768. Fix ODBC items to properly handle empty results and NULL values. Also allow unixODBC support without having odbc_config binary. Details: Before this fix SQL queries of "Database monitor" items where not
In both cases an item became UNSUPPORTED (except for the null value item [db.odbc.select[...]] became not supported: Received value [@?] The @? is garbage. This fix adds handling of such situations. In both cases an item
Also this fix improves configure check for unixODBC. Some GNU/Linux Before this fix when building Zabbix server with unixODBC support if |
Comment by dimir [ 2012 Aug 23 ] |
Ah, OK. I guess don't bother then if that's a production system. In any case, the issue is closed, feel free to re-open if you think this is not fixed properly. |
Comment by Grzegorz Grabowski [ 2012 Aug 26 ] |
Hi, so I checked ! And the winer is ... 12948:20120826:194322.001 cannot resolve macro ' {HOST.IP}'I try to use: HOST.CONN - the same result: cannot resolve macro '{HOST.CONN}' Maybe system macro doesn't work in Key field? This is the difference between 2.0.2 and 2.0.3rc1 12948:20120826:194322.001 send_list_of_active_checks_json() Item 'localsnmp[1.3.6.1.4.1.11080.300.3.19.0,{$SNMPP},{$SNMPC},{HOST.IP} ]' was successfully found in the server cache. Sending. 12948:20120826:194322.001 In substitute_simple_macros() data:'{$SNMPP}' 12948:20120826:194322.001 In DCget_user_macro() macro:'{$SNMPP}' 12948:20120826:194322.001 In DCget_host_macro() macro:'{$SNMPP}' 12948:20120826:194322.001 End of DCget_host_macro():SUCCEED 12948:20120826:194322.001 End of DCget_user_macro() 12948:20120826:194322.001 End substitute_simple_macros() data:'8086' 12948:20120826:194322.001 In substitute_simple_macros() data:'{$SNMPC}' 12948:20120826:194322.001 In DCget_user_macro() macro:'{$SNMPC}' 12948:20120826:194322.001 In DCget_host_macro() macro:'{$SNMPC}' 12948:20120826:194322.001 End of DCget_host_macro():SUCCEED 12948:20120826:194322.001 End of DCget_user_macro() 12948:20120826:194322.001 End substitute_simple_macros() data:'mmsgtv1' 12948:20120826:194322.001 In substitute_simple_macros() data:'{HOST.IP} ' ' 22729:20120826:195522.509 send_list_of_active_checks_json() Item 'localsnmp[1.3.6.1.4.1.11080.301.5.1.8.{$SNMPIDX},{$SNMPP},{$SNMPC}, {HOST.CONN}]' was successfully found in the server cache. Sending.22729:20120826:195522.509 In substitute_key_macros() data:'localsnmp[1.3.6.1.4.1.11080.301.5.1.8.{$SNMPIDX},{$SNMPP},{$SNMPC},{HOST.CONN} ]' 22729:20120826:195522.510 cannot resolve macro '{HOST.CONN} ' Bests, |
Comment by dimir [ 2012 Aug 29 ] |
The problem here is that item type "Zabbix agent (active)" does not have any interface attached, thus HOST.* macros will not be resolved. I have added a note in the documentation: http://www.zabbix.com/documentation/2.0/manual/appendix/macros/supported_by_location |
Comment by Grzegorz Grabowski [ 2012 Aug 29 ] |
Vladimir, Now, at version 2.0.2 ALL IS OK. System macros HOST.* work perfectly in KEY field for Zabbix agent (Active). |
Comment by Grzegorz Grabowski [ 2012 Aug 29 ] |
Ok, there is some data for you On my 2.0.1rc testing server: 22608:20120829:191947.414 send_list_of_active_checks_json() Item 'up.macro.test[ {HOST.CONN},{HOST.IP},{$USERMACRO}]' was successfully found in the server cache. Sending.22608:20120829:191947.414 In substitute_key_macros() data:'up.macro.test[{HOST.CONN} , {HOST.IP},{$USERMACRO}]'22608:20120829:191947.414 In substitute_simple_macros() data:'{HOST.CONN}' 22608:20120829:191947.414 End substitute_simple_macros() data:'127.0.0.1' 22608:20120829:191947.414 In substitute_simple_macros() data:'{HOST.IP} ' , {HOST.IP},{$USERMACRO}]", |
Comment by Grzegorz Grabowski [ 2012 Aug 29 ] |
I checked on 2.0.2 - the same log info - all is OK. And ones again, on my testing server I compile 2.0.3rc1 12535:20120829:193317.161 Starting Zabbix Server. Zabbix 2.0.3rc1 (revision 29840). Log: 12549:20120829:193340.532 send_list_of_active_checks_json() Item 'up.macro.test[ {HOST.CONN},{HOST.IP},{$USERMACRO}]' was successfully found in the server cache. Sending.12549:20120829:193340.532 In substitute_key_macros() data:'up.macro.test[{HOST.CONN} , {HOST.IP},{$USERMACRO}]'12549:20120829:193340.532 In substitute_simple_macros() data:'{HOST.CONN}' 12549:20120829:193340.532 cannot resolve macro '{HOST.CONN}' 12549:20120829:193340.532 End substitute_simple_macros() data:'UNKNOWN' 12549:20120829:193340.532 In substitute_simple_macros() data:'{HOST.IP} ' 12549:20120829:193340.532 End substitute_simple_macros() data:'UNKNOWN' 12549:20120829:193340.532 In substitute_simple_macros() data:'{$USERMACRO}' 12549:20120829:193340.532 In DCget_user_macro() macro:'{$USERMACRO}' 12549:20120829:193340.533 In DCget_host_macro() macro:'{$USERMACRO}' 12549:20120829:193340.533 In DCget_host_macro() macro:'{$USERMACRO}' 12549:20120829:193340.533 In DCget_host_macro() macro:'{$USERMACRO}' 12549:20120829:193340.533 End of DCget_host_macro():FAIL 12549:20120829:193340.533 End of DCget_host_macro():FAIL 12549:20120829:193340.533 End of DCget_host_macro():FAIL 12549:20120829:193340.533 In DCget_global_macro() macro:'{$USERMACRO}' 12549:20120829:193340.533 End of DCget_global_macro() 12549:20120829:193340.533 End of DCget_user_macro() 12549:20120829:193340.533 End substitute_simple_macros() data:'{$USERMACRO}' 12549:20120829:193340.533 End of substitute_key_macros():SUCCEED data:'up.macro.test[*UNKNOWN*,*UNKNOWN*,{$USERMACRO}]' 12549:20120829:193340.533 send_list_of_active_checks_json() sending [{ "response":"success", "data":[ { "key":"up.macro.test[*UNKNOWN*,*UNKNOWN*,{$USERMACRO}]", "key_orig":"up.macro.test[{HOST.CONN},{HOST.IP} ,{$USERMACRO}]", Bests, |
Comment by Grzegorz Grabowski [ 2012 Aug 29 ] |
I think we should move it to the new ZBX ticket... |
Comment by dimir [ 2012 Aug 30 ] |
That's right, this behavior was introduced in 2.0.3 . Since 2.0.3 these macros will not work for item types that do not have interfaces. Thanks for mentioning this, fixed in documentation: |
Comment by dimir [ 2012 Aug 30 ] |
The idea is that if an item is not related to the network interface these macros are kind of useless for it. |
Comment by dimir [ 2012 Aug 30 ] |
You know, we have just discussed this regression introduced in 2.0.3 and we decided that this should be fixed somehow before the 2.0.3 release. Please open new ZBX for HOST.* macros not working in "Zabbix agent (active)" anymore, and mention the ZBX number in comment here. Thanks for finding the issue. |
Comment by dimir [ 2014 Apr 22 ] |
mbsit, did you create a new issue? If yes, please put a link to it here, thanks. |
Comment by Grzegorz Grabowski [ 2014 Apr 22 ] |
Yes, some time ago |
Comment by dimir [ 2014 Apr 22 ] |
Ah, right, thanks. :-D |