Rename the project

[simartn]

The project name is misleading. The program is intended to run as a netdata plugin.
netdata will run the process. This has nothing to do with a daemon process.

Also I am not sure if I should keep this project open for other java collectors (currently there is only an JMX collector).

If yes the new name will be netdata-jmx-plugin
If not the new name would netdata-java-plugin

@ktsaou: Do you want me to help making this decision? I am asking because I wanted to ask you would accept moving this project to the netdata organization. I am asking you know because the naming, and with it the decision closing this project to other java collectors/plugins might affect your decision.
If you do not want to have anything to do with this please just ignore my question.

[ktsaou]

This is nice!

Ideally we should provide one java plugin that should be capable of running multiple modules, and each module running multiple jobs. Much like the python and node plugins do.

Integrating this into netdata would also be nice. I guess this would require some more work to build it using the netdata automake system and install it with the rest.

Also a wiki page should be needed to get people started.

A few comments:

1. I understand jmx provides a pretty standard set of metrics and each application can provide its own additional metrics. It would prevent a lot of configuration duplication to have the standard set pre-configured somehow, so that people will just point to a jmx host:port and they will get a standard set of charts for their application and individually configure the additional metrics they need. Something like this is also needed for snmp (actually snmp should support auto-discovery of metrics).

2. I thought the standard practice for java apps config files is xml, not json. Generally json is problematic. It does not support comments so extensive documentation is needed in separate files. For node.js plugins I would definitely use yaml if there was a javascript-only implementation yaml library.

3. Use exec java ... to run java to prevent a bash process in the netdata process tree

[simartn]

Ideally we should provide one java plugin that should be capable of running multiple modules, and each module running multiple jobs.

Then I will rename this plugin this project to netdata-java-plugin.

Integrating this into netdata would also be nice. I guess this would require some more work to build it using the netdata automake system and install it with the rest.

What do you mean with integrating?
Let's continue discussing this here (#41)

Also a wiki page should be needed to get people started.

I am currently working on more documentation. (#13, #33)

I understand jmx provides a pretty standard set of metrics and each application can provide its own additional metrics. It would prevent a lot of configuration duplication to have the standard set pre-configured somehow, so that people will just point to a jmx host:port and they will get a standard set of charts for their application and individually configure the additional metrics they need.

This is already there. The JMX plugin will autodetect and monitor all local running JVMs with a standard set of metrics. There are some issues left but generally this works. I also plan to add chart configuration for common java libraries and frameworks. Extending the configuration is no problem.

Also pointing out a host:port works (over the JMX Service URL). Documentation will be there as soon as possible.

I thought the standard practice for java apps config files is xml, not json.

This is true. But xml is much harder to read than json. We should discuss this.

Generally json is problematic. It does not support comments so extensive documentation is needed in separate files.

This is true if you stick to the JSON spec. Anyways I have seen json with java/c-like comments (// and /* ... */) in more projects. I am using jackson to parse the json files which also supports comments.

If you think it is still problematic I can make a pull request to switch to xml. There is not much work needed. But I think JSON wins because of readability.

For node.js plugins I would definitely use yaml if there was a javascript-only implementation yaml library.

Jackson also has a yaml extension. I never used it but we could try.

Let's continue the configuration language discussion here (#42)

Use exec java ... to run java to prevent a bash process in the netdata process tree

You are right (#40)

[simartn]

I am currently integrating this into netdata. I am closing this during issue migration to netdata. If you want to comment here, please comment there instead.

[simartn]

I am currently starting to cancel the integration into netdata. Read netdata/netdata#2663 (comment) for the reason.

Because of this the renaming is needed again. netdata now uses the term orchestrator for plugins with multiple modules.

https://docs.netdata.cloud/collectors/

To minimize the number of processes spawn for data collection, netdata also supports plugin orchestrators.

plugin orchestrators are external plugins that do not collect any data by themeselves.
Instead they support data collection modules written in the language of the orchestrator.
Usually the orchestrator provides a higher level abstraction, making it ideal for writing new
data collection modules with the minimum of code.
Currently netdata provides plugin orchestrators
BASH v4+ charts.d.plugin,
node.js node.d.plugin and
python v2+ (including v3) python.d.plugin.

The new name will be netdata-java-orchestrator.