[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