Logging and client stats

[berryma4]

We should think about how to log client activities and stats to help better understand client needs and issues.
(Something like google analytics for cs-studio)

[kasemir]

What we already have:
All log messages can be sent to JMS.
If you put a JMS server in the cloud, you could configure all CSS products to log SEVERE messages there, then analyze that and contact people: "Seems you ran into NullPointerException …. To fix that, …"

[berryma4]

And I can put it in elasticsearch ...
https://github.com/qotho/elasticsearch-river-jms
And, most of us have a JMS server from the BEAST setup.

So, should JMS be the preferred way for clients to report? Kunal, your
thoughts?

On Tue, Mar 25, 2014 at 12:08 PM, kasemir notifications@github.com wrote:

What we already have:
All log messages can be sent to JMS.
If you put a JMS server in the cloud, you could configure all CSS products
to log SEVERE messages there, then analyze that and contact people: "Seems
you ran into NullPointerException .... To fix that, ..."

Reply to this email directly or view it on GitHubhttps://github.com//issues/439#issuecomment-38584286
.

[shroffk]

I prefer Kays suggestion of having the JMS server on the cloud.
How do we plan to record and report events (usage information) other than SEVERE messages.

Here is a link to the old Usage data collection project, it might be useful to log bundle life cycle, command execution, workbench parts.
http://wiki.eclipse.org/UDC/What_Gets_Captured

[berryma4]

Wait, ... you are suggesting we watch all clients, not just our labs? If
we did something like this, I would suggest a pop-up asking if it is okay
to submit the data to us (like android, Microsoft and others do).

I was just thinking of a pipeline for clients to shovel information
(errors, crashes, response times, operating system, versions, etc.).
Knowing that about 10% of the people complain/report issues, this could
help us monitor our product after deployment ... in our own lab. But, if
both of you would like to make this more interesting, and do this on a
collaboration scale, I'm up for it. But most of our clients are behind
firewalls, no?

On Tue, Mar 25, 2014 at 12:33 PM, Kunal Shroff notifications@github.comwrote:

I prefer Kays suggestion of having the JMS server on the cloud.
How do we plan to record and report events (usage information) other than
SEVERE messages.

Reply to this email directly or view it on GitHubhttps://github.com//issues/439#issuecomment-38587801
.

[kasemir]

Yes, there is also the Eclipse UDC project, and of course the DESY remote control approach based on XMPP.

Sending the log messages to JMS is simply something that you already have in every CSS Tool: NSLS2 product, archive engine, alarm server, scan server, … can all already do this with just 2 lines in the plugin customization file.
A log level of SEVERE would capture errors.
A log level of INFO would capture startup info that usually contains version numbers.
The JMS2RDB filter allows removing some very frequent messages.
If additional info is desired, adding a log message is much easier than first adding or even designing a new message capturing system.
For me, just finding time to look at that captured data would be difficult.