-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[filebeat] Add support for bulk_max_size
and preset
#42312
base: main
Are you sure you want to change the base?
Conversation
This pull request does not have a backport label.
To fixup this pull request, you need to add the backport labels for the needed
|
|
bulk_max_size
bulk_max_size
and preset
Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane) |
/test |
if !cfg.HasField("bulk_max_size") { | ||
if err := cfg.SetInt("bulk_max_size", -1, defaultBulkSize); err != nil { | ||
return outputs.Fail(err) | ||
} | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why change the ES output implementation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering the same. I believe the ES output must not change as part of this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is only setting bulk_max_size
to a default value if not set, I moved it here, to keep it consistent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was it deleted intentionally?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, I refactored the test cases to take inputs as yaml
strings instead of reading from a file. This helped reuse common parts of the cofe. This also makes sure that as more paramaters will be mapped, we only have to update it in one place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was it deleted intentionally?
require.NoError(t, err) | ||
}) | ||
|
||
t.Run("test local queue setting is promoted to global level", func(t *testing.T) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm struggling to understand this test case.
Why do we have queue
as a part of the output configuration and then move to the filebeatreceiver
level? It should always be on the filebeatreceiver
level, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have the same question as @rdner, the queue
configuration in Beats is not part of the output.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is possible to set queue
both under filebeatreceiver
level and at output
level. When set under output
level we make sure to promote it to filbeatreceiver
level. This is done to allow existing
behavior of specifying queue settings at the top level. Also, when presets are applied, it is first set under output
level. This logic ensures that queue
settings that come from both user or presets are promoted one level up.
Ref PR: #36788
Our documentations currently do not mention setting queue
at output level. Opened an issue for the same #42310
require.NoError(t, err) | ||
}) | ||
|
||
t.Run("test local queue setting is promoted to global level", func(t *testing.T) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have the same question as @rdner, the queue
configuration in Beats is not part of the output.
}) | ||
} | ||
t.Run("basic config translation", func(t *testing.T) { | ||
basicInput := ` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's an output configuration, I'm a bit confused why it's called basicInput
. Maybe it can be called esOutputCfg
.
X-Header-1: foo | ||
X-Bar-Header: bar` | ||
|
||
basicOp := ` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This name here is also confusing me a bit. What does op
stand for here, operation?
What about renaming it to otelOutputCfg
?
basicOp := ` | |
otelOutputCfg := ` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Op
stood for output. I'll rename it to your suggestion, thanks
if !cfg.HasField("bulk_max_size") { | ||
if err := cfg.SetInt("bulk_max_size", -1, defaultBulkSize); err != nil { | ||
return outputs.Fail(err) | ||
} | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering the same. I believe the ES output must not change as part of this PR.
It looks like we are mapping existing parameters in Beats to similarly named parameters in the OTel collector. This only makes sense if we know they behave equivalent from a performance perspective. The bulk_max_size translating to max_size_items looks like it is probably OK, did we test that it behaves exactly the same? https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/exporter/elasticsearchexporter/README.md#batching The presets I am much less sure about and I don't think we should touch them without benchmarking them. The parameter values looking the same doesn't matter, the performance characteristics being the same or better is what matters. How are we measuring that? |
Co-authored-by: Tiago Queiroz <[email protected]>
Yes. It was tested with setting
All parameters that preset overrides are supported including |
Proposed commit message
This PR is a follow up to #41849. It improves test scenarios. It also adds support for
bulk_max_size
andpreset
.We will have to wait for next release of otel-collector to use
compression_level
parameter. But the default compression level used byelasticsearchexporter
is set to 1. So we can go ahead and supportpreset
paramater nowChecklist
CHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.Related Issue
Part of https://github.com/elastic/opentelemetry-dev/issues/614
open-telemetry/opentelemetry-collector-contrib#37260