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.

Sign up for GitHub

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

Jump to bottom

Handle event log mappings changing within the same release #58518

Closed
mikecote opened this issue Feb 25, 2020 · 2 comments · Fixed by #61633
Closed

Handle event log mappings changing within the same release #58518

mikecote opened this issue Feb 25, 2020 · 2 comments · Fixed by #61633
Assignees
@pmuellr
Labels
Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@mikecote
Copy link
Contributor

This issue comes from: #55639 (comment).

@pmuellr

I'm still a bit worried with the PR that fixes this, that we'll have problems for Kibana devs when we merge a new event mapping to master. The new mapping will only get picked up when the cached ES in the .es directory gets updated - before that, writes to the eventLog may not work if the event written doesn't match the old mappings.

I think we can fix this by not using "strict" in our object mappings, but "ignore". That way you could write "new" incompatible events to an "old" event log, but of course "new" fields wouldn't be "stored/indexed" (in the ES sense, I think they'd still be in the _source).

A few options are to make the mappings dynamic or to hash the mappings and compare on startup.

If we go the hash approach, we'll be able to log a warning that the event log expects a different mapping or something.
@mikecote mikecote added Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) labels Feb 25, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

@mikecote mikecote mentioned this issue Feb 25, 2020
Closed
@pmuellr
Copy link
Member

pmuellr commented Feb 28, 2020

It seems like it would be safe to set dynamic to false, so unmapped fields are ignored.

As the situation described above of a Kibana dev picking up a new eventLog mapping but running with an older ES, we could probably just compare the mappings we expect to the mappings that are there. I think this is only a dev-time concern, customers should never run into this. There must be some kind of dev flag we could key off of to make this additional check. OTOH, it shouldn't be an expensive check (1 ES call), only run at startup, probably wouldn't hurt to do it all the time.

I think I'd like eventLog to do both of those.

@pmuellr pmuellr self-assigned this Mar 26, 2020
@pmuellr pmuellr mentioned this issue Mar 27, 2020
Merged
pmuellr added a commit to pmuellr/kibana that referenced this issue Mar 27, 2020
@pmuellr
[alerting] change eventLog schema to use dynamic false
81f33b7 
resolves elastic#58518

Changes the object properties in the eventLog mappings to use `dynamic: false`
instead of `dynamic: strict`.  This provides a bit of a safety net for cases
where the mappings change during development, or potentially in production
cases.  Rather than completely lose entire events and see errors in logs, we'll
silently drop properties from events.

While researching the `dynamic` property, I remember there's also a `meta`
property available, which is a convenient place to drop our meta-data about
a field being an array value, for internal processing.  Bonus, it can live in
the generated mappings as well.

references:

- https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-field-meta.html
- https://www.elastic.co/guide/en/elasticsearch/reference/current/dynamic.html
pmuellr added a commit that referenced this issue Mar 27, 2020
@pmuellr
[alerting] change eventLog schema to use dynamic false (#61633)
8d539aa 
resolves #58518

Changes the object properties in the eventLog mappings to use `dynamic: false`
instead of `dynamic: strict`.  This provides a bit of a safety net for cases
where the mappings change during development, or potentially in production
cases.  Rather than completely lose entire events and see errors in logs, we'll
silently drop properties from events.

While researching the `dynamic` property, I remember there's also a `meta`
property available, which is a convenient place to drop our meta-data about
a field being an array value, for internal processing.  Bonus, it can live in
the generated mappings as well.

references:

- https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-field-meta.html
- https://www.elastic.co/guide/en/elasticsearch/reference/current/dynamic.html
pmuellr added a commit to pmuellr/kibana that referenced this issue Mar 27, 2020
@pmuellr
[alerting] change eventLog schema to use dynamic false (elastic#61633)
1dd60ab 
resolves elastic#58518

Changes the object properties in the eventLog mappings to use `dynamic: false`
instead of `dynamic: strict`.  This provides a bit of a safety net for cases
where the mappings change during development, or potentially in production
cases.  Rather than completely lose entire events and see errors in logs, we'll
silently drop properties from events.

While researching the `dynamic` property, I remember there's also a `meta`
property available, which is a convenient place to drop our meta-data about
a field being an array value, for internal processing.  Bonus, it can live in
the generated mappings as well.

references:

- https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-field-meta.html
- https://www.elastic.co/guide/en/elasticsearch/reference/current/dynamic.html
pmuellr added a commit that referenced this issue Mar 30, 2020
@pmuellr @elasticmachine
[alerting] change eventLog schema to use dynamic false (#61633) (#61707)
b3a7b74 
resolves #58518

Changes the object properties in the eventLog mappings to use `dynamic: false`
instead of `dynamic: strict`.  This provides a bit of a safety net for cases
where the mappings change during development, or potentially in production
cases.  Rather than completely lose entire events and see errors in logs, we'll
silently drop properties from events.

While researching the `dynamic` property, I remember there's also a `meta`
property available, which is a convenient place to drop our meta-data about
a field being an array value, for internal processing.  Bonus, it can live in
the generated mappings as well.

references:

- https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-field-meta.html
- https://www.elastic.co/guide/en/elasticsearch/reference/current/dynamic.html

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
@kobelb kobelb added the needs-team Issues missing a team label label Jan 31, 2022
@botelastic botelastic bot removed the needs-team Issues missing a team label label Jan 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@pmuellr pmuellr

Labels
Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[alerting] change eventLog schema to use dynamic false pmuellr/kibana
4 participants
@pmuellr @kobelb @mikecote @elasticmachine