[ZBXNEXT-4209] Java Gateway should allow discovery of MBean properties with non ASCII characters Created: 2017 Nov 03  Updated: 2024 Apr 10  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: XML File JmxGet.xml     PNG File Screenshot from 2019-09-10 14-00-55.png    
Issue Links:
Duplicate
is duplicated by ZBXNEXT-4583 Java Gateway not generates valid lld ... Closed
Sub-task
part of ZBX-12705 Java Gateway generates invalid lld ma... Closed
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
275 //String key = property.getKey().toUpperCase();
276 String key = property.getKey().toUpperCase().replace('-', '_’);

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 ZBXNEXT-4877 there is no need to generate LLD macro names for {#JMX<key property>} any more. This issue can be revisited.

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",
  "{#JMXSUBSYSTEM}": "datasources",
  "{#JMXSTATISTICS}": "jdbc",
  "{#JMXOBJ}": "jboss.as:subsystem=datasources,data-source=ExampleDS,statistics=jdbc"
 }
]

Fixed version with using replace method:

[
 {
  "{#JMXDOMAIN}": "jboss.as",
  "{#JMXDATA_SOURCE}": "ExampleDS",
  "{#JMXSUBSYSTEM}": "datasources",
  "{#JMXSTATISTICS}": "jdbc",
  "{#JMXOBJ}": "jboss.as:subsystem=datasources,data-source=ExampleDS,statistics=jdbc"
 }
]

This key i use in discovery:
jmx.discovery[beans,"jboss.as:subsystem=datasources,data-source=*,statistics=jdbc"]

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
A new JMX item key will be introduced.
Key name: jmx.get[<discovery mode>,<object name>]
Parameters:

  • discovery mode - one of the following: attributes:
    • attributes - retrieve JMX MBean attributes
    • beans - retrieve JMX MBeans
  • object name - object name pattern identifying the MBean names to be retrieved (empty by default, retrieving all registered beans).

The jmx.get[] *is similar to *jmx.discovery, but it does not turn Java object properties into macro names.

Example:
Request: jmx.get[beans,"com.example:type=*,*"]
Response:

[
	{
		"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.

Response:

{
  "data":[
    {
      "domain":"com.example",
      "type":"Atomic"
    },
    {
      "domain":"com.example",
      "type":"Hello",
      "data-source":"/dev/rand",
      "ключ":"значение"
    }
  ]
}

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:

  • attribute name case is changed to uppercase;
  • attribute name case is ignored (no LLD macro is generated) in case it consists of not supported characters. Supported characters can be described by the following regular expression: “A-Z0-9_\.”;
  • if an attribute name is called “obj” or “domain” it will be replaced with the values of Zabbix properties {#JMXOBJ}

    and

    {#JMXDOMAIN}

    (supported since Zabbix 3.4.3.).

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:

Generated at Thu Apr 25 18:36:40 EEST 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.