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

[Winlogbeat] Switch to ingest node processing #29435

Merged
merged 10 commits into from
Jan 4, 2022

Conversation

leehinman
Copy link
Contributor

@leehinman leehinman commented Dec 15, 2021

What does this PR do?

Switches to ingest node processing instead of local javascript
processing for modules.

Why is it important?

For Agent we are using ingest node processing. This keeps the
Winlogbeat and Agent processing in sync and allows bug fixes to be
shared between them.

Checklist

  • My code follows the style guidelines of this project
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • I have made corresponding change to the default configuration files
  • I have added tests that prove my fix is effective or that my feature works
  • I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Author's Checklist

  • Should we move the loading of pipelines from filebeat/fileset to libbeat?
  • Should we move adapting pipelines for compatibility to libbeat?
  • need to add tests

How to test this PR locally

Test export of pipelines

.\winlogbeat export pipelines --es.version 7.13.1

Test uploading of pipelines with setup

.\winlogbeat setup

Test uploading of pipelines when pipelines don't exist in ES

.\winlogbeat

Related issues

@botelastic botelastic bot added the needs_team Indicates that the issue/PR needs a Team:* label label Dec 15, 2021
@mergify
Copy link
Contributor

mergify bot commented Dec 15, 2021

This pull request does not have a backport label. Could you fix it @leehinman? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

  • backport-v./d./d./d is the label to automatically backport to the 7./d branch. /d is the digit

NOTE: backport-skip has been added to this pull request.

@mergify mergify bot added the backport-skip Skip notification from the automated backport with mergify label Dec 15, 2021
@elasticmachine
Copy link
Collaborator

elasticmachine commented Dec 15, 2021

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

To re-run your PR in the CI, just comment with:

  • /test : Re-trigger the build.

  • /package : Generate the packages and run the E2E tests.

  • /beats-tester : Run the installation tests with beats-tester.

  • run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

@botelastic botelastic bot removed the needs_team Indicates that the issue/PR needs a Team:* label label Dec 15, 2021
@mergify mergify bot removed the backport-skip Skip notification from the automated backport with mergify label Dec 15, 2021
@leehinman leehinman marked this pull request as ready for review December 17, 2021 19:09
@leehinman leehinman requested a review from a team as a code owner December 17, 2021 19:09
@elasticmachine
Copy link
Collaborator

Pinging @elastic/security-external-integrations (Team:Security-External Integrations)

}
f, err := os.Create(filepath.Join(directory, pipeline.id+".json"))
if err != nil {
return fmt.Errorf("unable to create file to export pipeline to: %+v", err)
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we want to use %w here for the error so it gets wrapped? Same applies for other instances below.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

good idea, I switched them.

Copy link
Member

@andrewkroh andrewkroh left a comment

Choose a reason for hiding this comment

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

I like how simple the winlogbeat.yml became. We'll need to do doc updates in a separate PR (that is less time urgent).

libbeat/docs/command-reference.asciidoc Outdated Show resolved Hide resolved
libbeat/docs/command-reference.asciidoc Outdated Show resolved Hide resolved

"github.com/elastic/beats/v7/winlogbeat/checkpoint"
"github.com/elastic/beats/v7/winlogbeat/config"
"github.com/elastic/beats/v7/winlogbeat/eventlog"
)

const pipelinesWarning = "Winlogbeat is unable to load the ingest pipelines" +
" because the Elasticsearch output is not configured/enabled. If you have" +
" already loaded the ingest pipelines or are using Logstash pipelines, you" +
Copy link
Member

Choose a reason for hiding this comment

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

or are using Logstash pipelines

This was probably copied from Filebeat. I don't think it should mention Logstash pipelines.

winlogbeat/beater/winlogbeat.go Show resolved Hide resolved
winlogbeat/module/pipeline.go Outdated Show resolved Hide resolved
winlogbeat/module/pipeline.go Outdated Show resolved Hide resolved
winlogbeat/module/pipeline.go Outdated Show resolved Hide resolved
winlogbeat/module/pipeline.go Show resolved Hide resolved
leehinman and others added 9 commits December 24, 2021 15:12
- remove JS processing
- remove testing of JS processing
- add ingest node pipelines from agent
- use routing pipeline to direct to correct module pipeline
- embed pipelines in winlogbeat executable
- add `export pipeline` command
- add loading of pipelines to setup command
- add loading of pipelines to every ES connection if the pipelines
  don't exist
- exports several functions from filebeat/fileset to avoid code
  duplication
- update docs
- update default config
- update reference config

Closes elastic#29184
Co-authored-by: Andrew Kroh <andrew.kroh@elastic.co>
Co-authored-by: Andrew Kroh <andrew.kroh@elastic.co>
Co-authored-by: Andrew Kroh <andrew.kroh@elastic.co>
Co-authored-by: Andrew Kroh <andrew.kroh@elastic.co>
Co-authored-by: Andrew Kroh <andrew.kroh@elastic.co>
- remove reference to Logstash pipelines
- cleanup grammar in godoc
- move logger creation
- always honor winlogbeat.overwrite_pipelines
- switch to prefix-version-short_id for pipeline ids
winlogbeat/module/pipeline.go Show resolved Hide resolved
x-pack/winlogbeat/cmd/root.go Outdated Show resolved Hide resolved
@efd6 efd6 mentioned this pull request Jan 3, 2022
6 tasks
Copy link
Member

@andrewkroh andrewkroh left a comment

Choose a reason for hiding this comment

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

LGTM 🚀

@andrewkroh
Copy link
Member

I'll merge this when it goes green.

@andrewkroh andrewkroh added breaking change release-note:breaking The content should be included as a breaking change labels Jan 4, 2022
@andrewkroh andrewkroh merged commit a3c2208 into elastic:master Jan 4, 2022
mergify bot pushed a commit that referenced this pull request Jan 4, 2022
What does this PR do?

Switches to ingest node processing instead of local javascript
processing for modules.

Why is it important?

For Agent we are using ingest node processing. This keeps the
Winlogbeat and Agent processing in sync and allows bug fixes to be
shared between them.

Changes

- remove JS processing
- remove testing of JS processing
- add ingest node pipelines from agent
- use routing pipeline to direct to correct module pipeline
- embed pipelines in winlogbeat executable
- add `export pipeline` command
- add loading of pipelines to setup command
- add loading of pipelines to every ES connection if the pipelines
  don't exist
- exports several functions from filebeat/fileset to avoid code
  duplication
- update docs
- update default config
- update reference config

Closes #29184

(cherry picked from commit a3c2208)
@nicpenning
Copy link
Contributor

This looks like a big blow to the Logstash users out there.

Is the local processing being removed entirely?

This would put in a very challenging barrier to upgrade for the users that rely on Logstash for all enrichment before sending to Elasticsearch.

The move makes sense but it will be great to have a plan for those who need to migrate away from heavy Logstash use.

One simple use case is that specific logs are tagged and indexed based on preparsed data from Winlogbeat. Maybe that will go away with data streams but it is without question users will be forced to use ingest pipelines to match current enrichment capabilities and they hope the ingest pipelines have the functionality needed to reproduce what Logstash can without adding complexity to the stack.

Also, I am wondering what this processing performance will look like as it goes from the individual systems to centralizing it on ingest nodes. When talking 10k+ or 100k+ winlogbeat agents, how much ingest processing will be needed since the decentralized processing goes away.

This is just my current reaction to what I can understand from this issue. Great capabilities regardless.

andrewkroh pushed a commit that referenced this pull request Jan 4, 2022
What does this PR do?

Switches to ingest node processing instead of local javascript
processing for modules.

Why is it important?

For Agent we are using ingest node processing. This keeps the
Winlogbeat and Agent processing in sync and allows bug fixes to be
shared between them.

Changes

- remove JS processing
- remove testing of JS processing
- add ingest node pipelines from agent
- use routing pipeline to direct to correct module pipeline
- embed pipelines in winlogbeat executable
- add `export pipeline` command
- add loading of pipelines to setup command
- add loading of pipelines to every ES connection if the pipelines
  don't exist
- exports several functions from filebeat/fileset to avoid code
  duplication
- update docs
- update default config
- update reference config

Closes #29184

(cherry picked from commit a3c2208)

Co-authored-by: Lee E Hinman <57081003+leehinman@users.noreply.github.com>
@herrBez
Copy link
Contributor

herrBez commented Feb 11, 2022

Hi there. Just a question. Would it not make sense to add the ECS field event.ingested directly in the routing pipeline, so that also logs from pplication and system would also have this field populated?

@andrewkroh
Copy link
Member

@herrBez Please open a new issue. 👍

efd6 added a commit to efd6/beats that referenced this pull request May 1, 2022
This brings partially processed event data from a modified version of the testing
code at 8896fd3 (the commit immediately prior to
the removal of the javascript processing pipeline in elastic#29435: commit at
2f3b0c5cbe9cfdd10e11fd52e2a259e564001100).

The evtx.golden.json files were generated by removing the js processing call at
https://github.com/elastic/beats/blob/8896fd319a257f3e0783119a7dd8d0978ef62197/x-pack/winlogbeat/module/testing_windows.go#L132-L135
to match the code in that file as it appears here and then run go test -update
in x-pack/winlogbeat/module/{powershell,security,sysmon}/test on a windows 2019
host.

The test package for each of the modules is also resurrected with modifications
reflecting the loss of the javascript processor.

Tests in x-pack/winlogbeat/module/{security,sysmon}/test fail in this
commit.
efd6 added a commit that referenced this pull request May 3, 2022
This is a moderately involved change. The process is described in the steps
below, but the reader should refer to the commits in the PR to see exactly
what was done and when.

* port forward semi-processed events for tests

This brings partially processed event data from a modified version of the testing
code at 8896fd3 (the commit immediately prior to
the removal of the javascript processing pipeline in #29435: commit at
2f3b0c5cbe9cfdd10e11fd52e2a259e564001100).

The evtx.golden.json files were generated by removing the js processing call at
https://github.com/elastic/beats/blob/8896fd319a257f3e0783119a7dd8d0978ef62197/x-pack/winlogbeat/module/testing_windows.go#L132-L135
to match the code in that file as it appears here and then run go test -update
in x-pack/winlogbeat/module/{powershell,security,sysmon}/test on a windows 2019
host.

The test package for each of the modules is also resurrected with modifications
reflecting the loss of the javascript processor.

Tests in x-pack/winlogbeat/module/{security,sysmon}/test fail in this
commit.

* make sure metadata is available for enrichment of raw values

This fixes failing tests in x-pack/winlogbeat/module/security/test, but tests in
sysmon continue to fail because sysmon-11-filedeletedetected.evtx was added in
33acb3c (2022-01-25) after the origin of the
forward port origin (2021-12-02).

* update golden file for sysmon-11-filedeletedetected.evtx

* ignore opcode field on Windows 2022

Also prohibit generating golden files for PowerShell on Windows 2022 to
prevent unnecessary work in discovering that this will fail on other
versions.

* defer event field filtering until value comparison

This will result in additional diff noise if golden values are generated on multiple
versions of windows so it may be worth keeping the version used reasonably constant.
The version used here was 2019.
mergify bot pushed a commit that referenced this pull request May 3, 2022
This is a moderately involved change. The process is described in the steps
below, but the reader should refer to the commits in the PR to see exactly
what was done and when.

* port forward semi-processed events for tests

This brings partially processed event data from a modified version of the testing
code at 8896fd3 (the commit immediately prior to
the removal of the javascript processing pipeline in #29435: commit at
2f3b0c5cbe9cfdd10e11fd52e2a259e564001100).

The evtx.golden.json files were generated by removing the js processing call at
https://github.com/elastic/beats/blob/8896fd319a257f3e0783119a7dd8d0978ef62197/x-pack/winlogbeat/module/testing_windows.go#L132-L135
to match the code in that file as it appears here and then run go test -update
in x-pack/winlogbeat/module/{powershell,security,sysmon}/test on a windows 2019
host.

The test package for each of the modules is also resurrected with modifications
reflecting the loss of the javascript processor.

Tests in x-pack/winlogbeat/module/{security,sysmon}/test fail in this
commit.

* make sure metadata is available for enrichment of raw values

This fixes failing tests in x-pack/winlogbeat/module/security/test, but tests in
sysmon continue to fail because sysmon-11-filedeletedetected.evtx was added in
33acb3c (2022-01-25) after the origin of the
forward port origin (2021-12-02).

* update golden file for sysmon-11-filedeletedetected.evtx

* ignore opcode field on Windows 2022

Also prohibit generating golden files for PowerShell on Windows 2022 to
prevent unnecessary work in discovering that this will fail on other
versions.

* defer event field filtering until value comparison

This will result in additional diff noise if golden values are generated on multiple
versions of windows so it may be worth keeping the version used reasonably constant.
The version used here was 2019.

(cherry picked from commit f22abe3)

# Conflicts:
#	x-pack/winlogbeat/module/security/test/testdata/security-windows2019_4688_Process_Created.evtx.golden.json
#	x-pack/winlogbeat/module/testing_windows.go
efd6 added a commit that referenced this pull request May 3, 2022
…t processing (#31491)

* {,x-pack/}winlogbeat: resurrect tests for event processing (#31464)

This is a moderately involved change. The process is described in the steps
below, but the reader should refer to the commits in the PR to see exactly
what was done and when.

* port forward semi-processed events for tests

This brings partially processed event data from a modified version of the testing
code at 8896fd3 (the commit immediately prior to
the removal of the javascript processing pipeline in #29435: commit at
2f3b0c5cbe9cfdd10e11fd52e2a259e564001100).

The evtx.golden.json files were generated by removing the js processing call at
https://github.com/elastic/beats/blob/8896fd319a257f3e0783119a7dd8d0978ef62197/x-pack/winlogbeat/module/testing_windows.go#L132-L135
to match the code in that file as it appears here and then run go test -update
in x-pack/winlogbeat/module/{powershell,security,sysmon}/test on a windows 2019
host.

The test package for each of the modules is also resurrected with modifications
reflecting the loss of the javascript processor.

Tests in x-pack/winlogbeat/module/{security,sysmon}/test fail in this
commit.

* make sure metadata is available for enrichment of raw values

This fixes failing tests in x-pack/winlogbeat/module/security/test, but tests in
sysmon continue to fail because sysmon-11-filedeletedetected.evtx was added in
33acb3c (2022-01-25) after the origin of the
forward port origin (2021-12-02).

* update golden file for sysmon-11-filedeletedetected.evtx

* ignore opcode field on Windows 2022

Also prohibit generating golden files for PowerShell on Windows 2022 to
prevent unnecessary work in discovering that this will fail on other
versions.

* defer event field filtering until value comparison

This will result in additional diff noise if golden values are generated on multiple
versions of windows so it may be worth keeping the version used reasonably constant.
The version used here was 2019.

(cherry picked from commit f22abe3)

# Conflicts:
#	x-pack/winlogbeat/module/security/test/testdata/security-windows2019_4688_Process_Created.evtx.golden.json
#	x-pack/winlogbeat/module/testing_windows.go

* fix conflict scars

* silence bad linter

Co-authored-by: Dan Kortschak <90160302+efd6@users.noreply.github.com>
Co-authored-by: Dan Kortschak <dan.kortschak@elastic.co>
@ag-michael
Copy link

@leehinman Does this mean users that use agent module javascript processors before forwarding to logstash are no longer supported?

@nicpenning
Copy link
Contributor

@leehinman Does this mean users that use agent module javascript processors before forwarding to logstash are no longer supported?

That is what I believe since in the latest version (8.2.2) of the Winlogbeat download (zip) they no longer include the javascript modules to parse the data on ingest pipelines for Elastic ingest nodes. :(

@efd6
Copy link
Contributor

efd6 commented Jun 1, 2022

@ag-michael Yes, that is correct.

@flemerle
Copy link

Yes the javascript modules are no longer in the zip, I just happened to figure it as I upgraded an agent today. I imported the module folder from an other agent and it works, this way I can still use logstas as my front-end for my agents.
If found it kind of sad to go away from Logstash like this.

chrisberkhout pushed a commit that referenced this pull request Jun 1, 2023
This is a moderately involved change. The process is described in the steps
below, but the reader should refer to the commits in the PR to see exactly
what was done and when.

* port forward semi-processed events for tests

This brings partially processed event data from a modified version of the testing
code at 8896fd3 (the commit immediately prior to
the removal of the javascript processing pipeline in #29435: commit at
2f3b0c5cbe9cfdd10e11fd52e2a259e564001100).

The evtx.golden.json files were generated by removing the js processing call at
https://github.com/elastic/beats/blob/8896fd319a257f3e0783119a7dd8d0978ef62197/x-pack/winlogbeat/module/testing_windows.go#L132-L135
to match the code in that file as it appears here and then run go test -update
in x-pack/winlogbeat/module/{powershell,security,sysmon}/test on a windows 2019
host.

The test package for each of the modules is also resurrected with modifications
reflecting the loss of the javascript processor.

Tests in x-pack/winlogbeat/module/{security,sysmon}/test fail in this
commit.

* make sure metadata is available for enrichment of raw values

This fixes failing tests in x-pack/winlogbeat/module/security/test, but tests in
sysmon continue to fail because sysmon-11-filedeletedetected.evtx was added in
33acb3c (2022-01-25) after the origin of the
forward port origin (2021-12-02).

* update golden file for sysmon-11-filedeletedetected.evtx

* ignore opcode field on Windows 2022

Also prohibit generating golden files for PowerShell on Windows 2022 to
prevent unnecessary work in discovering that this will fail on other
versions.

* defer event field filtering until value comparison

This will result in additional diff noise if golden values are generated on multiple
versions of windows so it may be worth keeping the version used reasonably constant.
The version used here was 2019.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport-v8.0.0 Automated backport with mergify breaking change release-note:breaking The content should be included as a breaking change
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Winlogbeat] move module processing logic from edge to ingest nodes
9 participants