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
Fix drop processor for monitoring events #2982
Fix drop processor for monitoring events #2982
Conversation
This pull request does not have a backport label. Could you fix it @belimawr? 🙏
NOTE: |
088fa14
to
563533f
Compare
🌐 Coverage report
|
ad0ca46
to
6ab8c1e
Compare
This pull request is now in conflicts. Could you fix it? 🙏
|
It fixes the drop processor for monitoring component logs, instead of using the dataset that does not include any information about whether the component is a monitoring component it now uses the `component.id`.
79f128b
to
85f208a
Compare
rebase onto |
Pinging @elastic/elastic-agent (Team:Elastic-Agent) |
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.
LGTM
One request for a non-blocking enhancement request in test.
testing/integration/enroll_test.go
Outdated
|
||
t.Log("waiting 20s so the components can generate some logs and" + | ||
"Filebeat can collect them") | ||
time.Sleep(20 * time.Second) |
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.
Not blocking but do we have an option besides Sleep? Any chance we could generate and read some kind of pre and post sentinel logs where we know a monitoring event would have been sent between the 2 of them?
This pull request is now in conflicts. Could you fix it? 🙏
|
buildkite test it |
Removing double installation/enrollment + remove tests based on the unwanted behavior (we no more have lines in logs for monitoring)
@pierrehilbert looks like integration tests coverage is not considered. Do you know if we generate any coverage report? This breaks the sonarcloud check |
/test |
Reducing code
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 think this is an extra changelog fragment... I don't see the related change and I think it's already been merged, 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.
Aside from the extra changelog fragment (not sure if it's a correction for a previous PR or a leftover and should be removed), the rest LGTM
Removing the backport, we are now too close to the 8.9 release. |
@pierrehilbert I think this is a small enough change that it could be backported. It should at least be in 8.9.1. |
I was thinking about this in 8.9.1 because we are really close to the last BC but if that's the wrong call and the fact that's a really small change makes us confident, let's change this :-) |
This one is small and fixes something that is currently completely broken, so let's backport it. For larger changes, we are definitely in the window where we need to think carefully about backporting. |
* integration:local can run a single test * Fix drop processor for monitoring components It fixes the drop processor for monitoring component logs, instead of using the dataset that does not include any information about whether the component is a monitoring component it now uses the `component.id`. * Update enroll_test.go Removing double installation/enrollment + remove tests based on the unwanted behavior (we no more have lines in logs for monitoring) * Update enroll_test.go Reducing code --------- Co-authored-by: Pierre HILBERT <pierre.hilbert@elastic.co> (cherry picked from commit 7cb5295)
* integration:local can run a single test * Fix drop processor for monitoring components It fixes the drop processor for monitoring component logs, instead of using the dataset that does not include any information about whether the component is a monitoring component it now uses the `component.id`. * Update enroll_test.go Removing double installation/enrollment + remove tests based on the unwanted behavior (we no more have lines in logs for monitoring) * Update enroll_test.go Reducing code --------- Co-authored-by: Pierre HILBERT <pierre.hilbert@elastic.co> (cherry picked from commit 7cb5295) Co-authored-by: Tiago Queiroz <tiago.queiroz@elastic.co> Co-authored-by: Craig MacKenzie <craig.mackenzie@elastic.co>
What does this PR do?
It fixes the drop processor for monitoring component logs, instead of using the dataset that does not include any information about whether the component is a monitoring component it now uses the
component.id
.Why is it important?
There can be an infinity loop of a monitoring component failing to send an event, logging it, then having it picked up from the logs which will be sent and fail, creating an infinity loop of error messages.
Checklist
./changelog/fragments
using the changelog tool## Author's ChecklistHow to test this PR locally
Run Elastic-Agent with monitoring enabled, then go to Kibana and look at the dataview
logs-*
, there should be no logs wherecomponent.id
matches the regexp.*-monitoring$
.Related issues
## Use cases## Screenshots## LogsQuestions to ask yourself