Skip to content
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

Exclude non-message streams from search in aggregation events #17087

Merged
merged 5 commits into from Nov 10, 2023

Conversation

patrickmann
Copy link
Contributor

@patrickmann patrickmann commented Oct 26, 2023

Relates to Graylog2/graylog-plugin-enterprise#6042

When no source stream is given for an event definition we use all streams in the ES/OS search query. We now exclude all non-message streams.

Motivation and Context

Users cannot select non-message streams as a source stream in the event definition. But these were still being included in the search when no source stream had been explicitly defined. This is unnecessary, inconsistent, and hurts performance. It may also push the search URI over the length limit, when there is a large number of streams.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Refactoring (non-breaking change)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.

@patrickmann patrickmann requested review from a team and thll and removed request for a team October 30, 2023 07:50
Copy link
Contributor

@thll thll left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current implementation produces different search query streams filters for aggregation events and for filter events. I think those two should be consistent.

@@ -219,7 +220,7 @@ private Set<String> getStreams(AggregationEventProcessorParameters parameters) {

private void filterSearch(EventFactory eventFactory, AggregationEventProcessorParameters parameters,
EventConsumer<List<EventWithContext>> eventsConsumer) throws EventProcessorException {
final Set<String> streams = getStreams(parameters);
final Set<String> streams = eventStreamService.buildEventSourceStreams(getStreams(parameters), Collections.emptySet());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is the wrong method, because, as the name suggests, it is supposed to operate on the results of a search. I think we should use the same method that we use for aggregations here.

It appears as if that one will also take care of filtering out the investigation streams, if the enterprise plugin is present. Otherwise we'll end up using different stream filters on the search queries for aggregation and filter events.

@patrickmann patrickmann requested a review from thll November 7, 2023 16:23
@thll thll merged commit 8f3f6c4 into master Nov 10, 2023
4 checks passed
@thll thll deleted the excludeNonMsgStreams branch November 10, 2023 14:40
maxiadlovskii pushed a commit that referenced this pull request Nov 14, 2023
* exclude non-message streams from default search

* update CL

* update CL

* apply filtering to search query

* use PermittedStreams for filter search
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants