-
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
Upgrade to ECS 1.7.0 #22571
Upgrade to ECS 1.7.0 #22571
Conversation
filebeat/docs/fields.asciidoc
Outdated
@@ -44305,7 +44305,7 @@ Examples include Beats. Agents may also run on observers. ECS agent.* fields sha | |||
Extended build information for the agent. | |||
This field is intended to contain any build information that a data source may provide, no specific formatting is required. | |||
|
|||
type: keyword | |||
type: wildcard |
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.
So, I'm not entirely sure how we want to document these -- do we need to change the doc generator to specify that sometimes this is a wildcard (if you're Elastic licensed), sometimes it's a keyword (if you're OSS)? Or should we add some sort of top-level documentation that says "all wildcards are keywords in OSS"?
@andrewkroh @webmat @ebeahan any thoughts?
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.
Yeah we have an issue in ECS for 1.8 to document the "fallback" idea for OSS implementations, and what it means at a high level. We can probably cover the Beats and Logstash implementations there as well.
Perhaps Beats docs can link to that?
We can make sure this page is ready in advance of the Stack 7.11 release.
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.
Just to answer your question a little more directly
do we need to change the doc generator...
I don't think we need to. The "OSS" fallback is not an official variant of ECS, it's a best effort workaround for purely OSS implementations. People could even use that to adopt ECS on 6.x if they have complex setups with many versions. But we're not making tons of efforts to fully support this. For example basic types that don't really have a fallback will simply not be supported.
This may deserve a mention somewhere in the Beats documentation, but I'm not even sure if there's a section about OSS Beats.
One thing's for sure, with tens of fields moving to wildcard
, I don't think it's worth adding a blurb about this all over the place. The OSS Beats usage is a small percentage, most people use the default/basic Beats, so I think it would be too much noise about something that doesn't affect most users.
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.
👍 -- also, should we mention that we're using "experimental" features of ECS somewhere in our docs?
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 sure. It's likely something that could flip flop from one release to another. For instance, "multi-user" stage 3 RFC is now merged, and will be part of mainline ECS in 1.8. Wildcard is approved, and it's a matter of time until it's merged as well.
So next release this notice may go away. And the following release, if we have another "stage 2" change we're pushing to adopt aggressively, the notice may need to come back... So I think it could add more confusion than anything.
It would be a fair warning to have though, so I wouldn't oppose if you want to add this.
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 do think this deserves a mention in the documentation so that users are aware that OSS beats will automatically be using keyword
rather than wildcard
. And that the same happens if you're using older, pre-wildcard ES versions.
@dedemorton Do you have a recommendation on where to include such a notice?
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.
This is a tough call. It sounds like saying something in the field description (where it would be the most noticeable) is not a good idea because it would be repetitive (plus our docgen process limits us).
We can put a statement at the top-level page in the field reference for each Beat, but IMO it's likely to be overlooked by users.
When are users most likely to care about the type difference? Will they be able to continue using the pre-built dashboards? Are there any upgrade implications if they decide to move to basic later on? Will there be a log message to let users know that keyword is being used instead of wildcard (and the implications/limitations)?
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.
@dedemorton wildcard
is a drop-in replacement in terms of functionality. Everything will continue to work functionally the same (including dashboards). Only the performance characteristics are changing. So everything keeps working, some things faster, some things slower (check out the table in the blog post for a breakdown).
A user upgrading Basic Beats from 7.10 to 7.11 or from Beats OSS to Beats Basic 7.11+ will go through the same non-event. The wildcard
and keyword
types are compatible and mixed indices being queried together will work flawlessly.
Users will only be able to fully take advantage of the performance improvements enabled by wildcard
once the older data has aged out, though.
💚 Flaky test reportTests succeeded. Expand to view the summary
Test stats 🧪
|
@andrewstucki ECS 1.7 is out. You can go grab the official v1.7.0 artifacts to update the PR :-) |
Pinging @elastic/security-external-integrations (Team:Security-External Integrations) |
@@ -1,5 +1,5 @@ | |||
# WARNING! Do not edit this file directly, it was generated by the ECS project, | |||
# based on ECS version 1.7.0. | |||
# based on ECS version 1.7.0+exp. |
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.
Pristine file 👍 😉
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.
😅
@andrewstucki We found a problem in the Beats YML file today, relating to the APM and ECS logger "tracing" fields. In Beats they're added under a "tracing" section, which makes them incorrectly appear as "tracing.trace.id", "tracing.transaction.id" and so on, instead of "trace.id" and "transaction.id". We have a PR to address this issue elastic/ecs#1164 already. I think it's worth waiting for it to be merged and pull this bug fix in, before merging this PR. |
@andrewstucki Alright, the fix has been merged in ECS branch "1.7". You can go grab it. Note that the tracing fields are now at the same level in the YAML document as field groups usually are. The field groups generally don't have a dot in their name, only fields defined within them do... So I'm not 100% sure if this will work as is. Please let us know if this causes an issue, we can adjust it further. Sorry I only noticed/ thought about that after it was backported. |
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.
Latest import and trace.id correction LGTM 👍
* Upgrade to ECS 1.7.0 * Update changelog * remove user.effective fields from custom fields and update functionbeat * Run make update (not mage update) on heartbeat * Add in dns.address and re-update all beats * fix x-pack metricbeat host processor * Update to released ECS 1.7 * update to fixed ECS * Fix bad filebeat ECS name * metricset -> fileset * Fix up expected load balancer log * Fix up alb expected log (cherry picked from commit a551b25)
* Upgrade to ECS 1.7.0 (#22571) * Upgrade to ECS 1.7.0 * Update changelog * remove user.effective fields from custom fields and update functionbeat * Run make update (not mage update) on heartbeat * Add in dns.address and re-update all beats * fix x-pack metricbeat host processor * Update to released ECS 1.7 * update to fixed ECS * Fix bad filebeat ECS name * metricset -> fileset * Fix up expected load balancer log * Fix up alb expected log (cherry picked from commit a551b25) * remove unnecessary epr file
What does this PR do?
This adds the upcoming ECS 1.7.0 yml file and updates all references to
ecs.version
-- also, it addsecs.version
data to the beats that were lacking it.It's currently in draft because the final ECS 1.7.0 release isn't cut yet. But, once it is, if anything has changed, it should just be a matter of re-importing the
fields.ecs.yml
file and re-runningmake update
.Checklist
- [ ] I have added tests that prove my fix is effective or that my feature worksCHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.