[ZBXNEXT-4209] Java Gateway should allow discovery of MBean properties with non ASCII characters Created: 2017 Nov 03 Updated: 2020 Apr 08 Resolved: 2019 Oct 02 |
|
Status: | Closed |
Project: | ZABBIX FEATURE REQUESTS |
Component/s: | Java gateway (J) |
Affects Version/s: | 4.0.0alpha1 |
Fix Version/s: | 4.4.0beta1, 4.4 (plan) |
Type: | Change Request | Priority: | Trivial |
Reporter: | Vjaceslavs Bogdanovs | Assignee: | Andrejs Tumilovics |
Resolution: | Fixed | Votes: | 6 |
Labels: | javagateway, lld, macro, unicode | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Attachments: | JmxGet.xml Screenshot from 2019-09-10 14-00-55.png | ||||||||||||||||
Issue Links: |
|
||||||||||||||||
Team: | Team C | ||||||||||||||||
Sprint: | Sprint 56 (Sep 2019) | ||||||||||||||||
Story Points: | 1 |
Description |
Currently, Java Gateway MBean discovery returns only MBean properties that do not contain characters that are not supported in macros ([^A-Z0-9_\\.]). So there is no option to retrieve properties like data-source (because of the "-") or ???? (because of the cyrillic characters). |
Comments |
Comment by Tomas Hermanek [ 2018 Jul 10 ] |
For quick fix you can change this file*: JMXItemChecker.java* 274 // This is changed for replace special characters |
Comment by Tomas Hermanek [ 2018 Jul 10 ] |
I make fixed package and template: https://share.zabbix.com/official-templates/wildfly-eap-jboss-discovery |
Comment by Glebs Ivanovskis [ 2019 Jan 31 ] |
With |
Comment by Tomas Hermanek [ 2019 Sep 10 ] |
Problem example with default GW, normaly zabbix try create macros with original name: data-source TO "{#JMXDATA-SOURCE}" but "-" is not allowed in macros. (Wildfly example) Now working default version: root@hosting1:~# ./jmx_fix_test "{#JMXDOMAIN}": "jboss.as", Fixed version with using replace method: [ This key i use in discovery: Tom |
Comment by Aleksandrs Larionovs (Inactive) [ 2019 Sep 11 ] |
Dear Community, This is proposed solution to the ticket. Would like to hear your feedback. Summary
The jmx.get[] *is similar to *jmx.discovery, but it does not turn Java object properties into macro names. Example: [ { "object": "com.example:type=Atomic", "domain": "com.example", "properties": { "type": "Atomic" } }, { "object": "com.zabbix:type=yes,domain=zabbix.com,data-source=/dev/rand,ключ=значение,obj=true", "domain": "com.zabbix", "properties": { "type": "Hello", "domain": "com.example", "data-source": "/dev/rand", "ключ": "значение", "obj": true } } ]
|
Comment by Glebs Ivanovskis [ 2019 Sep 11 ] |
<offtopic>I can add "(Zabbix Team)" to my name as well. What's the point?</offtopic> Now back to JMX.
There is no point of wrapping data in an object with a single key, you can return an array straight away: [ { "domain":"com.example", "type":"Atomic" }, { "domain":"com.example", "type":"Hello", "data-source":"/dev/rand", "ключ":"значение" } ] On the other hand there seems to be a good reason no introduce a more complex structure inside each object in the array. Current documentation says that {#JMXDOMAIN} and {#JMXOBJ} are "Zabbix reserved names" making it impossible to discover MBean properties named "domain" and "obj". New format allows you to separate reserved Zabbx keys and MBean properties into different "namespaces", e.g.: [ { "domain":"<Zabbix stuff>", "obj":"<more Zabbix stuff>", "properties":{ "domain":"<MBean stuff>", "obj":"<also MBean stuff>", ... } }, ... ] Also old name jmx.discovery is 100% to the point, would be a mistake to deprecate it in favor of jmx.get which (no offence) says nothing. |
Comment by Tomas Hermanek [ 2019 Sep 11 ] |
In documentation: https://www.zabbix.com/documentation/4.4/manual/discovery/low_level_discovery/jmx {#JMX<key property>}MBean properties (like {#JMXTYPE}, {#JMXNAME}). Some important notes to pay attention to when defining MBean attribute name that is created from MBean property name by the following algorithm:
|
Comment by Vjaceslavs Bogdanovs [ 2019 Sep 12 ] |
alarionovs copied the wrong example of responce. I edited his comment to reflect the decisions made. cyclone, thanks for your feedback! |
Comment by Andrejs Tumilovics [ 2019 Sep 20 ] |
Available in 4.4.0beta1 351df0216f2. |
Comment by Alexander Vladishev [ 2019 Oct 02 ] |
Updated documentation:
|