<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">On 28 Feb 2017, at 0:23, <a href="mailto:neil.okamoto+hawkular@gmail.com" style="color:#3983C4">neil.okamoto+hawkular@gmail.com</a> wrote:</p>
<p dir="auto"></p></div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">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</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">Scenario 2 may be unclear here. I did not try to imply that this<br>
may be the same collection system or that they are close enough,<br>
but rather the same "forwarding" system. <br>
Right now one would e.g. deploy Jolokia + DropWizard Metrics<br>
to expose the classic metrics and also the APM agent for the<br>
traces.<br>
This means double configuration, potentially duplicated code<br>
and a lot more places for errors.</p>
<p dir="auto"></p></div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">I would have expected the proposal was to combine the in the presentation/UI *after* collection. Am I misunderstanding?</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">No. And this was the main focus of the 1st scenario.</p>
<p dir="auto"></p></div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">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.</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">Absolutely.</p>
<p dir="auto">And still when you have a trace like the following</p>
<p dir="auto"><img src="cid:6EE38915-A238-4335-8A96-839E1905C916@redhat.com" alt="" title="Bildschirmfoto 2017-02-28 um 10.38.00.png"></p>
<p dir="auto">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.<br>
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</p>
</div>
</div>
</body>
</html>