-
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
Specify an ECS version in Auditbeat/Packetbeat/Winlogbeat #19159
Specify an ECS version in Auditbeat/Packetbeat/Winlogbeat #19159
Conversation
💔 Build FailedExpand to view the summary
Build stats
Test stats 🧪
Steps errorsExpand to view the steps failures
Log outputExpand to view the last 100 lines of log output
|
run tests |
Pinging @elastic/siem (Team:SIEM) |
run tests |
1 similar comment
run tests |
Thanks for getting this started! I agree ideally a whole Beat should upgrade ECS versions all at once whenever possible. This is an improvement over setting it once in libbeat for all Beats, for a given stack release. Given that these 3 Beats have much fewer datasets than Metricbeat and Filebeat, I think this is an acceptable tradeoff. 👍 |
run tests |
f02adf6
to
593c6cf
Compare
run tests |
Run tests |
593c6cf
to
a135e25
Compare
When we update the Beat (include all of its modules) we will then bump the ECS version that it includes in events. I went for a less granular approach than what is being used in Filebeat because I think it's desirable to move a whole beat to a new ECS version "at once" and more realistic to do so with these Beats that have fewer updates. By "at once" I mean we won't release a version that is partially updated. This implies that if we will be making multiple commits that we should use a feature branch to ensure the update is atomic. Closes elastic#17688
a135e25
to
12fb849
Compare
The kibana container is failing to launch for the integration tests due to elastic/kibana#71343, but the unit tests are all passing so I'm going to merge. |
) When we update the Beat (include all of its modules) we will then bump the ECS version that it includes in events. I went for a less granular approach than what is being used in Filebeat because I think it's desirable to move a whole beat to a new ECS version "at once" and more realistic to do so with these Beats that have fewer updates. By "at once" I mean we won't release a version that is partially updated. This implies that if we will be making multiple commits that we should use a feature branch to ensure the update is atomic. Closes elastic#17688 (cherry picked from commit 256b50d)
* upstream/master: (25 commits) [Elastic Agent] Send checkin payload to Fleet (elastic#19857) [Ingest Manager] Fixed tests across agent elastic#19877 [Ingest Manager] Fix serialization test elastic#19876 Fix service start type mapping in windows/service metricset (elastic#19551) ci: Change comment trigger detection method (elastic#19827) Add 21 autogenerated filesets from rsa2elk devices (elastic#19713) [Ingest Manager] Agent config cleanup (elastic#19848) libbeat/publisher/pipeline: fix data races (elastic#19821) Update monitoring-internal-collection.asciidoc (elastic#19422) (elastic#19697) [Elastic Agent] Trust exchange endpoint must bind to 127.0.0.1 (elastic#19861) Specify an ECS version in Auditbeat/Packetbeat/Winlogbeat (elastic#19159) Add azure billing metricset (elastic#19207) Add support for appinsights in the metricbeat azure module (elastic#18940) Add MySQL query metricset with lightweight module and SQL helper (elastic#18955) [Ingest Manager] Refuse invalid stream values in configuration (elastic#19587) Do not use vendor during integration tests (elastic#19839) LIBBEAT: Enhancement Convert dissected values from String to other basic data types and IP (elastic#18683) [Elastic Agent] Remove support for "logs" and only support logfile (elastic#19761) [CI] support windows-2012 (elastic#19773) Do not update go.mod during packaging and testing (elastic#19823) ...
…19862) When we update the Beat (include all of its modules) we will then bump the ECS version that it includes in events. I went for a less granular approach than what is being used in Filebeat because I think it's desirable to move a whole beat to a new ECS version "at once" and more realistic to do so with these Beats that have fewer updates. By "at once" I mean we won't release a version that is partially updated. This implies that if we will be making multiple commits that we should use a feature branch to ensure the update is atomic. Closes #17688 (cherry picked from commit 256b50d)
) When we update the Beat (include all of its modules) we will then bump the ECS version that it includes in events. I went for a less granular approach than what is being used in Filebeat because I think it's desirable to move a whole beat to a new ECS version "at once" and more realistic to do so with these Beats that have fewer updates. By "at once" I mean we won't release a version that is partially updated. This implies that if we will be making multiple commits that we should use a feature branch to ensure the update is atomic. Closes elastic#17688
What does this PR do?
When we update the Beat (include all of its modules) we will then bump the ECS
version that it includes in events.
I went for a less granular approach than what is being used in Filebeat because
I think it's desirable to move a whole beat to a new ECS version "at once" and
more realistic to do so with these Beats that have fewer updates. By "at once" I
mean we won't release a version that is partially updated. This implies that if
we will be making multiple commits that we should use a feature branch to
ensure the update is atomic.
Why is it important?
We want the
ecs.version
to accurately represent the schema that is implemented.Related issues