Event-data-track from github does not work

Elastic Stack Elasticsearch
1

Hi,

I have issues running the event-data-track from github by
@Christian_Dahlqvist.

I modified my rally.ini in tracks area to this here:

[tracks]
default.url = https://github.com/elastic/rally-tracks
eventdata.url = https://github.com/elastic/rally-eventdata-track

I start rally with the following command:

esrally --offline --target-hosts=qdetjt:9200 --pipeline=benchmark-only --user-tag=testrunName:volume_106,cluster:volume,env:docker,ver:6.6.2,JMS:4g,JMX:4g,laps:1,storageType:volume,StorageDriver:overlay2,aloneOnLoadGenerator:yes,Iteration:106 --laps=1 --track-path=/home/esrally/.rally/benchmarks/tracks/rally-eventdata-track/eventdata/

Rally is comming that far:

[INFO] Racing on track [eventdata], challenge [append-no-conflicts] and car ['external'] with version [6.6.2].

Running delete-index                                                           [100% done]
Running create-index                                                           [100% done]
Running index-append-1000                                                      [  2% done]

rally.log is showing things like that:

2019-03-28 09:38:16,770 ActorAddr-(T|:39104)/PID:41979 esrally.actor INFO LoadGenerator[0] starts driving now.
2019-03-28 09:38:16,774 ActorAddr-(T|:38825)/PID:41968 esrally.actor INFO Resetting relative time of cluster system metrics store.
2019-03-28 09:38:16,777 ActorAddr-(T|:37645)/PID:41976 esrally.actor INFO Resetting relative time of system metrics store on host [[{'port': 9200, 'host': 'qdetjt'}]].
2019-03-28 09:38:16,765 ActorAddr-(T|:37424)/PID:41985 esrally.actor INFO LoadGenerator[6] is executing [index-append-1000].
2019-03-28 09:38:16,764 ActorAddr-(T|:35043)/PID:41983 esrally.actor INFO LoadGenerator[4] is executing [index-append-1000].
2019-03-28 09:38:16,765 ActorAddr-(T|:35043)/PID:41983 esrally.driver.driver INFO Choosing [deterministic scheduler] for [index-append-1000].
2019-03-28 09:38:30,45 ActorAddr-(T|:35043)/PID:41983 esrally.driver.driver INFO Creating time-period based schedule with [deterministic] distribution for [index-append-1000] with a warmup period of [0] seconds and a time period of [1200] seconds.
2019-03-28 09:38:16,766 ActorAddr-(T|:37424)/PID:41985 esrally.driver.driver INFO Choosing [deterministic scheduler] for [index-append-1000].
2019-03-28 09:38:30,43 ActorAddr-(T|:37424)/PID:41985 esrally.driver.driver INFO Creating time-period based schedule with [deterministic] distribution for [index-append-1000] with a warmup period of [0] seconds and a time period of [1200] seconds.
2019-03-28 09:38:30,226 -not-actor-/PID:41983 elasticsearch WARNING POST http://qdetjt:9200/_bulk [status:400 request:0.098s]
2019-03-28 09:38:30,227 -not-actor-/PID:41985 elasticsearch WARNING POST http://qdetjt:9200/_bulk [status:400 request:0.108s]
2019-03-28 09:38:30,352 -not-actor-/PID:41985 elasticsearch WARNING POST http://qdetjt:9200/_bulk [status:400 request:0.055s]
2019-03-28 09:38:30,352 -not-actor-/PID:41983 elasticsearch WARNING POST http://qdetjt:9200/_bulk [status:400 request:0.050s]
2019-03-28 09:38:30,478 -not-actor-/PID:41985 elasticsearch WARNING POST http://qdetjt:9200/_bulk [status:400 request:0.053s]
2

elasticsearch is showing this exception after starting esrally:

That error of the last lines is flooding the log.

My external car is standard single node cluster with 4GB Xmx.

Thanks for any help,
Andreas

3

Hi,

you're refering to the track with --track-path and this means you're effectively disabling Rally's ability to pick the right version of the track based on the Elasticsearch version you're benchmarking. So your benchmark ran against the master branch of the track repo which is suitable for Elasticsearch 7.0.0 and better and this is why you get failures.

You should instead use --track-repository=eventdata --track=eventdata then Rally will recognize that you are benchmarking Elasticsearch 6.x and that there is a branch 6 in that repo which it will then checkout. For more details please see the docs.

Daniel

4

thanks, it's now working.

What is the best practice to test on an air-gap system? Can I just run it once (with same target cluster version) on an on-air system, then copy the track repository to the air gap system?

Is rally only interacting different with ES by each major or also on each minor or bugfix version?

Thanks a lot,
Andreas

5

For our standard tracks we actually have a helper script (see docs). For the rally-evendata-track I suggest you clone the Github repo on a machine with Internet access and then transfer the entire repository to the machine where you run the benchmarks. All the branches are already available locally then and Rally will just check them out. But note that to get any new commits containing fixes or new features you need to transfer the repo again yourself.

That depends and you need to check the respective track repo. In rally-tracks we sometimes have branches even for minor versions (see the versioning scheme docs). The eventdata track does not offer as thorough multi-version support as the standard tracks though (IIRC versions below Elasticsearch 6.x are not supported nor is there an intention to do so).

Daniel

6

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.