<!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">Hi,</p>
<p dir="auto">right now Hawkular metrics and Hawkular APM are going<br>
relatively separate ways. This is in part due to the backend choice, <br>
but probably also for other reasons.</p>
<p dir="auto">I am proposing that we try to get the two closer together because at the end neither tracing data alone, not classic monitoring data can answer all the questions like:</p>
<p dir="auto">APM<br>
- why is my service XY slow (my be overload of underlying CPU)<br>
- how much disk will my service need in two years<br>
- how much network usage did my service have yesterday</p>
<p dir="auto">Classic montoring<br>
- which service will fail if I pull the plug here<br>
- what are customers buying<br>
- why is my service slow (may be come from a dependency)</p>
<p dir="auto">I am proposing that we integrate the two over the UI - in the first scenario<br>
here the key driver is the APM UI with its trace diagrams (red boxes).<br>
A klick on such a box will then show related metrics from the<br>
classic monitoring.<br>
On the level of the individual pod, both APM and Classic 'instrumentations'<br>
are present. For JVM-based apps this is on one side the APM agent and/or <br>
APM instrumentation ("OT-instrumentation") (*a) On the other side the<br>
jolokia agent/agent bond (*b) </p>
<p dir="auto"><img src="cid:60528B4C-9911-4942-9091-D66129836840@redhat.com" alt="" title="hosa-apm1.png"></p>
<p dir="auto">In this first scenario, APM and classic still have separate agents and connections to the<br>
backends and different backend storage.</p>
<p dir="auto">The 2nd scenario, assumes that it is possible to use only one agent binary that<br>
does both APM and classic metric export. For classic metrics, Hosa will poll it with<br>
P8s metrics. And on top APM trace data will also be made available for grab by<br>
Hosa, which will then forward them to the APM server.</p>
<p dir="auto"><img src="cid:C4FC8BD0-2735-4CF5-9EEA-30A5B176909B@redhat.com" alt="" title="hosa-apm2.png"></p>
<p dir="auto">Thoughts?<br>
Heiko</p>
<p dir="auto">*a) I propose to always deploy the APM agent to get a quick and easy coverage<br>
of standard scenarios, so that the user only needs explicit instrumentation to<br>
increase granularity and/or to cover cases the agent can't cover.<br>
Also "manual" instrumentation should be able to use the agent's connection to<br>
talk to the APM server.</p>
<p dir="auto">*b) I think it would make sense to always use the Prometheus protocol (and Hosa<br>
may learn how to use the more efficient binary protocol) as Jolokia/http is JVM/Jmx <br>
specific, while P8s exporters also exist for other environments like Node or Ruby</p>
<p dir="auto">-- <br>
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,<br>
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn<br>
Handelsregister: Amtsgericht München HRB 153243<br>
Geschäftsführer: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander</p>
</div>
</div>
</body>
</html>