[Hawkular-dev] Garbage collection of outdated Servers/Metrics - especially with (orchestrated) containers

Michael Burman miburman at redhat.com
Fri Mar 10 07:35:28 EST 2017


Hi,

This is actually a solved issue if you want to track a single metric's 
history. Remember, metricId has no context information, it could (and it 
should have been so that people don't get confused) a randomly generated 
uuid.

The way you track the container's historic CPU usage is by using the tags:

For example, to get all the datapoints for a single container, you use:

container_name=hawkular-metrics

The podid does not make any difference here, it's just some random 
information. Now, on the other hand, if you want to  compare how the 
hawkular-metrics memory usage has changed between different pod versions 
or pod ids, you can do that also by actually using the tags of pod_id 
and container_version.

Just use pod_id as one sorting method and container_version as one (I 
don't remember the exact names of these tags). Tags are the key to 
sorting and finding the information you want - not the metricId. 
MetricId is something you should completely forget, it's not relevant.

The Kubernetes metrics have tags available that you can use for sorting, 
grouping and finding.

   -  Micke

On 03/09/2017 12:35 PM, Lukas Krejci wrote:
> Isn't the question rather "how do we associate them with the 
> application(s)"?
> Because if we want to track e.g. CPU load generated by an application in a
> container - isn't that something users would want to look at history of? IMHO,
> using the ephemeral "container id" as (part of) metric ids is a wrong thing to
> do, because really the user isn't interested in the container itself, but the
> applications that are running in it and their consumption of container's
> resources.
>
>



More information about the hawkular-dev mailing list