add metricbeat benchmark module

[leehinman]

Proposed commit message

Add a metricbeat benchmark module.

This module will generate a synthetic metric every period. It can be configured to send multiple events by setting the count option.

This is useful if you need to write integration tests that produce metrics without having to setup something to monitor. It is also useful for testing output configuration and sizing of systems.

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Disruptive User Impact

None. New module.

Author's Checklist

• [ ]

How to test this PR locally

Unit tests

cd x-pack/metricbeat/module/benchmark/info
go test -v .

By Hand

build metricbeat from this PR, and then run with the following metricbeat.yml

metricbeat:
  modules:
    - module: benchmark
      metricsets:
        - info
      count: 1
      enabled: true
      period: 1s
output:
  console:
    pretty: true

Related issues

• closes elastic/ingest-dev#4438

Use cases

Screenshots

Logs

[elasticmachine]

Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane)

[ycombinator]

Should this be a numeric type?

[leehinman]

Probably not. Even though it is numeric "data", it is unlikely we would use range searches, it is much more likely we want fast retrieval. ie you search to make sure that benchmark metric number 13 was actually indexed.

Here is the tip from elasticsearch docs I'm basing this off of.

Mapping numeric identifiers

Not all numeric data should be mapped as a numeric field data type. Elasticsearch optimizes numeric fields, such as integer or long, for range queries. However, keyword fields are better for term and other term-level queries.

Identifiers, such as an ISBN or a product ID, are rarely used in range queries. However, they are often retrieved using term-level queries.

Consider mapping a numeric identifier as a keyword if:

• You don’t plan to search for the identifier data using range queries.
• Fast retrieval is important. term query searches on keyword fields are often faster than term searches on numeric fields.

If you’re unsure which to use, you can use a multi-field to map the data as both a keyword and a numeric data type.

[ycombinator]

Does this need to change as part of this PR?

[leehinman]

No, in that it isn't part of this change. But Yes in that mage config generates it. I don't know why #40411 didn't already pull this change in.

[ycombinator]

Should this be a numeric type?

[leehinman]

See previous comment on why "numeric" data shouldn't always have a numeric type in elasticsearch.

[mergify]

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b onweek_metricbeat_benchmark upstream/onweek_metricbeat_benchmark
git merge upstream/main
git push upstream onweek_metricbeat_benchmark

[leehinman]

@ycombinator how do you feel about the numeric vs keyword reasoning?