ElasticSearch | capacity VS usage correlation

[AlmogBaku]

1. Right now we pushing pairs of entries that related to capacity versus the actual usage, like: cpu/capacity and cpu/usage_rate
2. In order to create some meaningful virtualization, we clearly need to calculate the relation between them.. i.e. (usage / capacity*100 = % of cpu)
3. There is no way to “join” entries in kibana/elasticsearch
4. Therefore I assume we might need to “merge” this information into a one document/entry, so cpu/usage_rate will have a secondary related value of the capacity, then we’ll be able to create a “calculated field” in kibana (edited)

TBD:
a. What do you think about this approach?
b. Currently I think the easiest way to achieve it is by iterating/manipulating the core.MetricSet and into the combined document elasticsearch.EsSinkPoint
c. I think we need to keep both the “extended usage entry” and the “capacity entry” (so we will have: cpu/capacity and cpu/usage_rate, but the second will include the capacity)
b. I'll appreciate any help to understand the relationships between other metrics

cc: @piosz @huangyuqi

[AlmogBaku]

@piosz @huangyuqi can you help me figure out the questions above?

[DirectXMan12]

It seems reasonable to attach related information together. Requests and limits seem reasonable to attach as well. Does attaching capacity, though, increase storage space much? You'd be duplicating it quite a bit if it appears everywhere cpu/usage_rate does, I believe.

[AlmogBaku]

I believe it's increase the storage.. but probably not much.

Questions:

1. Should we keep the original "capacity entry"? or if we combine this information anyway we can remove it..
2. Should we also attach "units" to the entries?
3. Which entries are related to each other? (I'm not sure even if i was right in my example)

[AlmogBaku]

Following up to my conversation with @DirectXMan12 I came to the conclusion that a change in the schema is required.

Instead of one "type" for all the metrics, we need a type for each "metric family"(cpu/filesystem/memory/network; and one for the rest - "general"; which include the "custom" family and uptime)

This change is basically not very complicated to achieve(since the DataBatch is already organized/aggregated by entities), however it'll be breaking change(and consider the fact this is a VERY new feature, it probably won't affect many people)

[fejta-bot]

Issues go stale after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale