Feedback on toolkit:

[ddebrunner]

Some feedback from using the toolkit and sample: It was easy (with some modifications) to get the sample app running, but thinking about it's use for real monitoring I came up with these items:

• Should MetricsSource domain parameter be optional, defaulting to the domain the job is running in? For Bluemix it's not actually documented what the domain identifier is.
• Should MetricsSource filterDocument parameter be optional, defaulting to all metrics for all jobs in all instances in the specified domain identifier.
• I believe all existing apis use domainId or domainID (i.e. it's a domain identifier), but MetricsSource uses domain (operator parameter) and domainName in the filter document. Maybe the same issue for instance name vs. identifier.
• The sample app fails on the quick start vm since the domain is StreamsDomain which is not matched in the filter document.
• Filter document being a file would seem to be limiting, especially on Bluemix. Having it being able to accept a JSON serialized object as an rstring would allow the filtering to be stored in an application configuration.
• I assume it won't currently work on Bluemix, but it should be improved to work on Bluemix. The issue is how to get the JMX connect URL.
• The JMX connect URL can change on a failure, so ideally the operator would take a list of URLs, or even be able to figure out the URLs automatically and retry on a connection failure.

[m-kotowski]

1. re "Should MetricsSource domain parameter be optional": +1
2. re "Should MetricsSource filterDocument parameter be optional, defaulting to all metrics for all jobs in all instances in the specified domain identifier.": No. For test applications it might be useful to easily get everything, but for an application in production it is probably better to specify exactly what it needs to reduce the amount of transferred metric information.
3. re "all existing apis use domainId or domainID": +1. I will change the parameter name. Since the filter document specifies id/name patterns, we should rename them to xxxPatterns even if the names will be quite long: operatorNamePatterns, domainIdPatterns.
4. re "The sample app fails on the quick start vm since the domain is StreamsDomain": +1. I will add this name to the sample's filter document.
5. re "Filter document being a file would seem to be limiting": I am also thinking about application configuration and/or a control port.
6. re "The issue is how to get the JMX connect URL.": No idea so far ... perhaps calling streamtool during the operator initialization?
7. re "The JMX connect URL can change on a failure,...": If you have a solution, please create a pull request. I was already aware of this and similar things, see issue #5.

[m-kotowski]

re 1: The automatic determination of the domain id does not work for applications running in standalone mode. In this case, the operator raises an exception and aborts.

[ddebrunner]

The automatic determination of the domain id does not work for applications running in standalone mode. In this case, the operator raises an exception and aborts.

Seems reasonable since there is no domain, or the operator could check if its in standalone and fail in a similar fashion to when a domain matches nothing in the filter doc.

[m-kotowski]

Moved bullet 6 and 7 to issue #5.

[m-kotowski]

re 1: delivered re 2: as explained - stay with current solution re 3: delivered re 4: delivered, test app monitors all domains and instances now re 5: created issue #24 to track this separately re 6: moved to issue #5 re 7: moved to issue #5

re 1: The operator already fails if the specified domainId does not match any domainId pattern.

So I am closing this issue. Reopen if needed.