-
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
Use server-side filtering when retrieving Cloud Foundry logs #33456
Conversation
This pull request doesn't have a |
This pull request does not have a backport label.
To fixup this pull request, you need to add the backport labels for the needed
|
This pull request is now in conflicts. Could you fix it? 🙏
|
/package |
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.
@MichaelKatsoulis @gizas if both logs modes collect the same logs, I wonder if we should just use the new method with server and client filtering, and don't expose the option to user. Wdyt?
// TODO: Handle unknown filters. | ||
return filterNoFilter, -1 |
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.
We should decide if we want some kind of error handling here, or if we just consider all
the default in this case.
return filterLogs, -1 | ||
case FirehoseFilterLogs: | ||
// Uses filter-type=logs in requests to the firehose. | ||
return filterLogs, consumer.LogMessages |
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 to use both filters here.
@@ -80,23 +81,49 @@ func (c *DopplerConsumer) Run() { | |||
} | |||
|
|||
func (c *DopplerConsumer) logsFirehose() { | |||
c.firehose(c.callbacks.Log, consumer.LogMessages) | |||
filter := FirehoseFilterAllLogs |
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.
If we are sure that FirehoseFilterAllLogs
and FirehoseFilterLogs
collect the same logs, but FirehoseFilterLogs
is much more efficient, wdyt about using FirehoseFilterLogs
here and don't expose the option to the user?
filter := FirehoseFilterAllLogs | |
filter := FirehoseFilterLogs |
+1 on that. Let's not expose the |
And given that, shall we be exposing anything at all regarding this? I have pushed a couple of changes, to remove |
This pull request is now in conflicts. Could you fix it? 🙏
|
I agree. Let's keep it simpler. I will test it and then we can merge it |
@jsoriano it works as expected. We can merge when ci passes |
It reduces CPU usage of Filebeat significatively. Co-authored-by: MichaelKatsoulis <[email protected]> (cherry picked from commit 5cd8b09)
…ud Foundry logs (#33637) * Use server-side filtering when retrieving Cloud Foundry logs (#33456) It reduces CPU usage of Filebeat significatively. Co-authored-by: MichaelKatsoulis <[email protected]> (cherry picked from commit 5cd8b09) * Update CHANGELOG.next.asciidoc Co-authored-by: Jaime Soriano Pastor <[email protected]> Co-authored-by: Michael Katsoulis <[email protected]>
It reduces CPU usage of Filebeat significatively. Co-authored-by: MichaelKatsoulis <[email protected]>
What does this PR do?
Use server-side filtering when retrieving Cloud Foundry logs.
Why is it important?
It reduces CPU usage of Filebeat significatively.
Checklist
I have made corresponding change to the default configuration filesCHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.Author's Checklist
How to test this PR locally
firehose_filter: logs
, check that log messages are still collected.Related issues
Use cases
Screenshots
Logs