This adds the ability to specify a regex to match against database names when specifying what agents should write to which buckets in the data generator.
A default has also been added for ratio so that it doesn't need to be specified if only a single database writer is defined.
This adds the ability for the data generator to write to many databases. A new command line argument, `bucket_list`, is added which should be a file name. The file should contain a list of databsaes, one per line, with the structure of <org>_<bucket>. This is a little odd given the data generator expects org and bucket separately, but I expect the file that we'll be using will be database names, which have this format.
The configuration can specify what percentage of the list should get written to by which agents at what sampling interval. This should allow configurations where databases get different levels of ingest and different types (as specified via different agent specs). The structure is a little wonky, but I think it'll get the job done. The next step is to run some perf tests to see how the data generator performs if writing to 10k databases.
This is work leading up to giving the data generator the ability to write to many databases. The plan is to specify which agents databases will use to write data.
This removes the create databsase command line flag and associated code from the data generator runner. Creation of databases should live outside the generator in other tools.
The direction was required when a database could read or write from/to a
write buffer. Now it is clear from the usage context of a write buffer
context which of the two applications is meant (databases read, routers
write) so the direction flag is no longer required.
This is a huge commit that refactors the data generator. It removes many of the previous features that didn't quite make sense. The goal of this refactor was to make the data generator capable of representing complex tagsets that have values dependent on each other. It also significantly optimizes things to use far less memory and generate data much faster. Follow on work will update the generation of line protocol to support spaces in tags and their keys, double quotes in strings, and add more examples and documentation.
This adds the ability to specify a tag_set and a collection of tag_pairs to measurements in the data generator. Tag pairs are evaluated once when the generator is created. This avoids re-running handlebars evaluations while generating data for tags that don't change value.
This commit also fixes an issue when printing the generation output to stdout while generating from more than one agent. Previously it would be garbled together.
Follow on PRs will update the tag generation code in measurement specs to be more consistent and optimzised for performance. I'll be removing the restriction of using different options while using tag_set and tag_pairs. I wanted to get this in first to show the structure of what is output.
This improves performance of the the file output mode, which should
make it easier to improve the performance of the core generation
logic.
Benchmarked via:
```
time \
./target/release/iox_data_generator \
--spec iox_data_generator/schemas/fully-supported.toml \
--output /tmp/out \
--start '1 month ago'
```
Before:
```
Submitted 271608 total points
real 10.912 10911567us
user 3.129 3129032us
sys 6.257 6257340us
cpu 86%
mem 7152 KiB
```
After:
```
Submitted 271588 total points
real 2.291 2291364us
user 1.969 1969357us
sys 0.058 58030us
cpu 88%
mem 7104 KiB
```
That's 21.0% of the previous time.
This adds the ability to pre-generate values and tag sets in the data generator. This makes it easy to have tags that depend on other tag values (like buckets in an org) and have tag values that have one associated tag (like if something is in production or staging environment). Follow on work will add the actual generation to the agent spec. An added bonus of these pre-generated values is that generating samples won't require any sort of template evaluation for all of the tags in the tag sets. Only unique values (like trace_id or span_id) would need to be generated during sampling generation.
- Move main binary to `src/bin`. It's easier to reason about when all
binaries are in a single directory and the other files in `src` just
belong to the lib. Note that `cargo run [-p iox_data_generator]` still
works.
- Enable lints that we use elsewhere. Fix the few issues that were found
by this (e.g. broken intradoc links).
This allows:
- different types (instead of guessing through the connection URL)
- sequencer counts (not used yet but will be by #2455)
- extensible configs (e.g. to configure Kafka in a more granular way,
not wired up yet)
- future extensions (since we use a message now instead of a single
string)
**BREAKING: This requires changes for deployed systems / existing DBs!**
Adds batch_size to the data genrator to optionally gather multiple calls to generate for each agent. For example, if you have a sampling interval of 10 seconds and start at some point back in time with a batch size of 3, it gather 3 samplings before writing to the points writer. For runs against a server API, this will batch them together in a single API call.
Carol (Nichols || Goulding)
Marco Neumann
dependabot[bot]
Paul Dix
Paul Dix
Raphael Taylor-Davies
Raphael Taylor-Davies
Jake Goulding
Carol (Nichols || Goulding)