otel: allow filebeat otel to load otel config files#45093
otel: allow filebeat otel to load otel config files#45093mauri870 merged 9 commits intoelastic:mainfrom
Conversation
🤖 GitHub commentsExpand to view the GitHub comments
Just comment with:
|
|
This pull request does not have a backport label.
To fixup this pull request, you need to add the backport labels for the needed
|
Currently the filebeat otel command only loads beats config files, which it then translates to beats receivers in order to run a OTel collector. This PR augments this functionality to allow the command to load otel configuration files, this aids in testing and running beats receivers in a standalone collector.
7571341 to
2d668c9
Compare
|
This pull request is now in conflicts. Could you fix it? 🙏 |
|
Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane) |
a47c49f to
818c4c8
Compare
|
/test |
|
This should be backported to 8.19 as well, I believe |
… files (#45133) * otel: allow filebeat otel to load otel config files (#45093) * otel: allow filebeat otel to load otel config files Currently the filebeat otel command only loads beats config files, which it then translates to beats receivers in order to run a OTel collector. This PR augments this functionality to allow the command to load otel configuration files, this aids in testing and running beats receivers in a standalone collector. * update notice * add test for multiple receivers * fix monitoring port * test refactor for template * restore condition removed by mistake * allow monitoring http request with variable url (cherry picked from commit 46e855e) * fix linter error --------- Co-authored-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
This test is flaking for a while with a high failure rate. We have an integration test that covers the same scenario added by elastic#45093. Skip this test for now.
| id: filestream-fbreceiver | ||
| enabled: true | ||
| paths: | ||
| - {{$receiver.InputFile}} |
There was a problem hiding this comment.
Hello @mauri870, I just realized that both the receivers are using the same directory. The registry is going to be updated by both receivers at the same time. And since they are ingesting the same log file - there is likely going to be data loss here.
Were you able to test this? I am afarid we will turn out to see this as another flaky test.
It is also best to use unqiue namespaces for both receivers
There was a problem hiding this comment.
Thanks, you are absolutely right. I ran these tests with stress for half an hour but did not find any issues, but they are definitely bound to happen at some point.
khushijain21
left a comment
There was a problem hiding this comment.
Sorry for bringing up few comments after this was merged
This test is flaking for a while with a high failure rate. We have an integration test that covers the same scenario added by #45093. Skip this test for now.
…vers (#45166) * [oteltest][fbreceiver]: skip TestMultipleReceivers (#45147) This test is flaking for a while with a high failure rate. We have an integration test that covers the same scenario added by #45093. Skip this test for now. (cherry picked from commit 5069a00) # Conflicts: # x-pack/filebeat/fbreceiver/receiver_test.go * fix conflicts --------- Co-authored-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
…ivers (#45168) * [oteltest][fbreceiver]: skip TestMultipleReceivers (#45147) This test is flaking for a while with a high failure rate. We have an integration test that covers the same scenario added by #45093. Skip this test for now. (cherry picked from commit 5069a00) # Conflicts: # x-pack/filebeat/fbreceiver/receiver_test.go * fix conflicts --------- Co-authored-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
As a leftover from elastic#45093, the tests added reuse the index names which may cause issues when running the tests in sequence without cleaning up first. Adjusted the existing tests to use unique indexes.
As a leftover from #45093, the tests added reuse the index names which may cause issues when running the tests in sequence without cleaning up first. Adjusted the existing tests to use unique indexes.
…45319) As a leftover from #45093, the tests added reuse the index names which may cause issues when running the tests in sequence without cleaning up first. Adjusted the existing tests to use unique indexes. (cherry picked from commit ea98564) Co-authored-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
* otel: allow filebeat otel to load otel config files Currently the filebeat otel command only loads beats config files, which it then translates to beats receivers in order to run a OTel collector. This PR augments this functionality to allow the command to load otel configuration files, this aids in testing and running beats receivers in a standalone collector. * update notice * add test for multiple receivers * fix monitoring port * test refactor for template * restore condition removed by mistake * allow monitoring http request with variable url (cherry picked from commit 46e855e) # Conflicts: # NOTICE.txt # go.mod # x-pack/libbeat/common/otelbeat/otel.go
|
Huh, for some reason there was no backport for 9.1 even with the backport-active-9 label. |
Proposed commit message
Currently the filebeat otel command only loads beats config files, which it then translates to beats receivers in order to run a OTel collector.
This PR augments this functionality to allow the command to load otel configuration files, this aids in testing and running beats receivers in a standalone collector without depending on EDOT.
How to test
Checklist
CHANGELOG.next.asciidocorCHANGELOG-developer.next.asciidoc.Related