<div dir="ltr">If I understand how tags are getting used, I think tags will provide the ability to keep track of history regardless of whether we are dealing with a new container or an application which is no longer alive.<div><br></div><div>However, what is not clear to me is what happens when the old container goes away. I am assuming that we will no longer be attempting to probe it or gather data from it?</div><div><br></div><div>Ultimately what I, as a user, want to be able to do is change network configuration or platform or container without changing what defines my application. For example, if I have a helloworld.war deployed to an EAP server and am monitoring it, I really don't care about the other stuff. If it changes, so be it. But my helloworld application should still be reflected the same.</div><div><br></div><div>If the database my helloworld application uses changes, so be it. I still want to treat the datasource as the same datasource it always was even if the underlying implementation changes and a new inventory object to represent it gets created. My expectation is that _helloworld-datasource_ is _datasource-pg94_ and _datasource-pg95_ and _datasource_mysql_ combined. Even though in reality I started with PostgreSQL 9.4; upgraded to PostgreSQL 9.5; and decided to migrate to MySQL at some point. In the end, I want to view the datasource metrics based on the entire life-cycle as that datasource relates to my helloworld application.</div><div><br></div><div>The same could be said for my helloworld application's underlying application server. Perhaps I have my WAR deployed to EAP 7.1 to start but later I upgrade to EAP 8. It is still my helloworld application.</div><div><br></div><div>In the past I would suggest providing a "linking" capability that would allow me to identify the EAP 8 instance as a continuation or upgrade of the specific EAP 7.1 instance. Or the MySQL datasource as a continuation or upgrade of the PostgreSQL 9.5 datasource and the 9.5 datasource an upgrade or continuation of the PostgreSQL 9.4 datasource. However, if I understand how tagging is getting implemented, tags would also accomplish this.</div><div><br></div><div>If I have separate objects in inventory, they would just get tagged as helloworld application. When I view history, I am seeing the milestones across the various inventory objects that make up what I am referring to as helloworld application. For example, if I had to spin up a new container every day for the last 7 days, then perhaps it would be interesting to see that indicated in the history, but the metric values are considered to be a single series as they relate to the all 7 containers. </div><div><br></div><div>But to take the burden of the user to tag each new container that represents helloworld, I would hope that we can figure out how to do this automatically and then allow the user to update/fix tags if they are wrong?</div><div><br></div><div>In any event, just my thoughts as this does relate to a very big pain point with the legacy RHQ and JBoss ON implementation.</div><div><div><br></div><div class="gmail_extra">--<br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><span style="font-size:12.8px">Larry O'Leary</span><br></div><div><br></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Fri, Mar 10, 2017 at 6:35 AM, Michael Burman <span dir="ltr"><<a href="mailto:miburman@redhat.com" target="_blank">miburman@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
This is actually a solved issue if you want to track a single metric's<br>
history. Remember, metricId has no context information, it could (and it<br>
should have been so that people don't get confused) a randomly generated<br>
uuid.<br>
<br>
The way you track the container's historic CPU usage is by using the tags:<br>
<br>
For example, to get all the datapoints for a single container, you use:<br>
<br>
container_name=hawkular-<wbr>metrics<br>
<br>
The podid does not make any difference here, it's just some random<br>
information. Now, on the other hand, if you want to compare how the<br>
hawkular-metrics memory usage has changed between different pod versions<br>
or pod ids, you can do that also by actually using the tags of pod_id<br>
and container_version.<br>
<br>
Just use pod_id as one sorting method and container_version as one (I<br>
don't remember the exact names of these tags). Tags are the key to<br>
sorting and finding the information you want - not the metricId.<br>
MetricId is something you should completely forget, it's not relevant.<br>
<br>
The Kubernetes metrics have tags available that you can use for sorting,<br>
grouping and finding.<br>
<br>
- Micke<br>
<span class="im HOEnZb"><br>
On 03/09/2017 12:35 PM, Lukas Krejci wrote:<br>
> Isn't the question rather "how do we associate them with the<br>
> application(s)"?<br>
> Because if we want to track e.g. CPU load generated by an application in a<br>
> container - isn't that something users would want to look at history of? IMHO,<br>
> using the ephemeral "container id" as (part of) metric ids is a wrong thing to<br>
> do, because really the user isn't interested in the container itself, but the<br>
> applications that are running in it and their consumption of container's<br>
> resources.<br>
><br>
><br>
<br>
</span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
hawkular-dev mailing list<br>
<a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a><br>
</div></div></blockquote></div><br></div></div></div>