Rally benchmark kubernetes.pod #8443
Conversation
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
🤖 GitHub commentsExpand to view the GitHub comments
To re-run your PR in the CI, just comment with:
|
🌐 Coverage report
|
| "node":{ | ||
| "uid": "{{ $uId }}" , | ||
| "hostname":"host-{{ $nodeid }}", | ||
| "name":"host-{{ $nodeid }}", |
There was a problem hiding this comment.
Let me understand a thing. If you run the tool to generate let's say 1000 events, then there will be 90 different node names in these events. But there will be 1000? different node uids ? So the the same nodes(with same name) will have a different uid. Is this assumption correct?
There was a problem hiding this comment.
I copied the assets from @gizas elastic/elastic-integration-corpus-generator-tool#111
but yes, according to the config this will be correct.
if need to have 90 $nodeId and 90 $uId and they always must match we had to add cardinality: 90 to both of them
There was a problem hiding this comment.
Cardinality doesn't it mean that they will just be 90 different ? How can we know that they will match? Or we could directly link the name with the uid by setting the name:host-{{uid}}.
The reason I am mentioning this, is that if the uid and name don't match it cannot actually be a realistic test.
There was a problem hiding this comment.
does it affect the test if we just remove one of the fields to avoid this scenario?
There was a problem hiding this comment.
but i agree, we are going to come up against these types of 'correlated' fields all the time. we should probably find a way to deal with it.
There was a problem hiding this comment.
Cardinality doesn't it mean that they will just be 90 different ? How can we know that they will match?
They will match because cardinal values are generated sequentially and reiterated at the same time:
cardinality: 3
value1
value2
value3
Or we could directly link the name with the uid by setting the name:host-{{uid}}.
since uid is a call to a function, we cannot apply cardinality indeed (it's not a field defined basically, sorry for the initial suggestion we could apply it).
we could still have name:host-{{uid}} but we will end up with as many host as number of events generated.
The reason I am mentioning this, is that if the uid and name don't match it cannot actually be a realistic test.
uid must a uid, must it? (sorry for the dump question).
we could make it a field in the format word1-word2-word3-word4 and make name and hostname be a "link" to it.
having uid as a field we could apply a cardinality
There was a problem hiding this comment.
Late to the game but trying to catch up.
Summarising to the above:
1)For now the number of nodes did not affect the test.
2) The assumption we made is that the specific test will produce a result of around 10.000 unique pod names and cosidering that we have the limit of 110 pods per node, that is why we resulted to 90 nodes. (See https://github.com/elastic/elastic-integration-corpus-generator-tool/pull/111/files#diff-d34fb1cf4866915a96be5b7ef33896bfecb1d98d1571dc32204396cc8aef5255R38)
So I would say to keep it like that for now
3) We have the same problem with pod.name and pod.uid. We need to correlate specific pod names with pod.uids and the problem there afffects the tests because uids are dimensions https://github.com/elastic/rally-tracks/blob/master/tsdb_k8s_queries/pod-template.json#L663. I will update pod.name to be the a "link" to pod.uid, is simpler and should work.
There was a problem hiding this comment.
I am running some more tests and will update the uids shortly.
To add one above:
See below block that will produce 10000 pod names (based on rangeofid) and will distribute to 90 nodes (based on limit we have that 1node has 110 maximum pods)
- name: rangeofid
range:
min: 0
max: 10000
- name: nodeid
range:
min: 1
max: 90
Then the key is that we produce the result with gotext -t 8640000, which is the number of events when we scrape every 10 sec.
See info
So the ideal would be based on the number of events (and the user gives eg number of pods to calculate number of nodes)
There was a problem hiding this comment.
@aspacca and @gizas I believe the having each generated pod event having a unique node uid does not make sense. We need to apply cardinality. I don't know why uid needs to be a real uid in these tests.
we could make it a field in the format word1-word2-word3-word4 and make name and hostname be a "link" to it.
This makes sense to me.
There was a problem hiding this comment.
@aspacca , @MichaelKatsoulis here is my update template where I removed nodeid and just i divide the rangeofid of pod with 110. This gives me a fix node id for specific group of pods
elastic/elastic-integration-corpus-generator-tool@fe73f69
This way 0-109 pods are inside node-0
110-219 node-1 and goes one!
|
@gizas all good here? :) I've applied the latest change related to node uid |
Enhancement
Proposed commit message
Add artifacts for
elastic-packagerally benchmarkChecklist
- [ ] I have added an entry to my package'schangelog.ymlfile.- [ ] I have verified that Kibana version constraints are current according to guidelines.Author's Checklist
How to test this PR locally
From
kubernetspackage root (remember to bring up the elastic-package stack before):./elastic-package benchmark rally --benchmark pod-benchmark -vRelated issues
Screenshots