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.