[telemetry] More user options

[GabrielXia]

Contains

Now the user can choose which field he wants to send in the metrics menu.

• He can enable/disable a single field, e.g. the "language" field.
• He can enable/disable a whole metric e.g. "System Context", then all fields in that metric will be enabled/disabled.
• Click the check box "Send metrics to server" will enable/disable all fields.
• If all fields in the metric is disabled, that metric will be disabled automatically. If one field is enabled, that metric will be enabled automatically.
  

Make all the string default to no_analysed in ELK, we can finally do some pie graphs :) The utility.terasology.org:5601 is updated. Here is an example proposed in #3024

Outstanding before merging

For the headless server, we need to edit in terasology-server/config.cfg:

• "telemetryEnabled": true to enable telemetry
• "errorReportingEnabled": true to enable error reporting
• copy bindingMap in /config.cfg to terasology-server/config.cfg to have more options :)

The telemetry in the headless server is too manual, if you have some more ideas, please let me know! Thanks :)

Thanks @rzats @oniatus @Cervator @skaldarnar @msteiger @qwc for review and comments!

[GooeyHub]

Hooray Jenkins reported success with all tests good!

[Cervator]

Only spotted a couple tiny bits of code to comment about, but the game crashed with an NPE on testing it and returning to the main menu:

java.lang.NullPointerException: null
	at org.terasology.telemetry.TelemetryUtils.trackMetric(TelemetryUtils.java:67)
	at org.terasology.telemetry.TelemetrySystem.shutdown(TelemetrySystem.java:154)
	at org.terasology.engine.ComponentSystemManager.shutdown(ComponentSystemManager.java:188)

Seems to be from not resetting config.cfg - after deleting it and retrying everything was fine. Maybe you can harden the code to gracefully handle that situation?

Also a side suggestion: Have a button/checkbox for enabling or disabling all :-)

Finally: I had a somewhat random thought recently, do we have any sort of rate limiting for submitting data to the server? Not likely to be an issue for some time but could a user maliciously flood the metrics collector and break the server?

[Cervator]

Keep an eye out for these silly little empty javadoc blocks. They remain here and there and sometimes get copy pasted around. Just delete them or better yet write some javadoc! ;-)

[Cervator]

Should be up at the top of the class (Checkstyle violation)

[GooeyHub]

Hooray Jenkins reported success with all tests good!

[GabrielXia]

Thanks @Cervator @rzats so much for the test!

@Cervator thanks for the bug that you find. The nlp happens the first time you enable the telemetry, not open the metrics screen in the game and return to the main menu or quit. In this pr, I simply do the nlp check to fix the nlp. Ideally I should add all the telemetry field at the beginning. Because I'll do several changes in the next pr, could I solve this issue totally in the next pr? I could also update all the code in this pr :) That will make this pr more complicated

I think at the bottom of the metrics menu, if you click send metrics to server, it'll enable/diable all the fields. I like also the idea of limiting metrics, do you think it should be done in the client side? e.g. the same user isn't able to send 100 metrics to the server? But that might cause a problem when some devs are debugging the telemetry code

[Cervator]

Retested - seems good, thanks :-) Merged! Always good to harden further but yeah that can be whenever.

Enabling all on actually selecting the metrics seems handy.

On throttling - it would have to be a server side setting and I wouldn't be surprised if logstash / snowplow / something already has related options. It would be something like throttling individual sources that are sending unrealistically high amounts of data (likely malicious or a bug)