On 28 Feb 2017, at 0:23, neil.okamoto+hawkular@gmail.com wrote:

From the outside looking in, this proposal seems to assume monitoring/metrics are similar enough to APM traces that they can and should converge in a single collection system. Whereas

Scenario 2 may be unclear here. I did not try to imply that this
may be the same collection system or that they are close enough,
but rather the same "forwarding" system.
Right now one would e.g. deploy Jolokia + DropWizard Metrics
to expose the classic metrics and also the APM agent for the
traces.
This means double configuration, potentially duplicated code
and a lot more places for errors.

I would have expected the proposal was to combine the in the presentation/UI *after* collection. Am I misunderstanding?

No. And this was the main focus of the 1st scenario.

Because I would have thought the characteristics of these systems would be unique enough to stay separate, e.g. the traffic rates for metrics vs traces would be different, the ‘schema’ of what needs to be forwarded and stored is different, and for sure the APM traces need to be correlated based on their trace IDs and otherwise filtered based on somewhat arbitrary tags supplied in the instrumentation.

Absolutely.

And still when you have a trace like the following

one wants to find out why it took 800ms and where the difference on 600ms was spent. Here looking at data from the underlying pod or even node may be very helpful. Which is where the classical monitoring data comes into play.
Similarly if you have a service scaled to 3 instances and you get a larger variation in request time, the pod information may help you pinpoint the variations