-
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
Make elasticsearch/index_summary metricset work for Stack Monitoring without xpack.enabled flag #20615
Make elasticsearch/index_summary metricset work for Stack Monitoring without xpack.enabled flag #20615
Conversation
…ases and new metricset fields. No code changes yet.
}, | ||
}, | ||
// following field is not included in the Stack Monitoring UI mapping | ||
"is_throttled": c.Bool("is_throttled"), |
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.
If the field is not needed by the Stack Monitoring UI (@chrisronline may want to confirm) and it wasn't a field we were already collecting in data.go
, then it's safe to not collect it at all. So I would remove this line and others like it.
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 correct. We need to not only collect the mappings, but also continue to collect and index any other fields we used to because we often read values from the source
document that weren't considered when the finalized mappings were produced.
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.
@chrisronline So just to clarify, you're saying we should collect this field, is_throttled
, but we should not include it in the fields.yml
so it doesn't show up in the mappings, right?
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.
Correct
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.
Understood 🙂
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.
We don't really even want to index fields that aren't used and we could take another pass on which fields we read from source directly, but we're also currently in talks about potentially indexing as much data as possible (even if the stack monitoring UI doesn't use it) to enable users to build custom dashboards. Nothing is decided but I'd rather leave the functionality as is in case we do go down that path
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.
Wait a sec 😄 as far as I understood, we should map this fields in elasticsearch fields.yml
mapping. But should we still map it in the metricset fields.yml
file? As a Metricbeat convention, it must be mapped, AFAIK 100% of Metricbeat fields are map in fields.yml
of their respective metricsets. Metricbeat is not going to fail though, we however have a commonly used python test (like this one in MySQL module https://github.com/elastic/beats/blob/master/metricbeat/module/mysql/test_mysql.py#L47) to check if all fields are map in fields.yml
but fortunately it's not included in the python test code for the elasticsearch module.
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.
.monitoring-*
indices have dynamic mapping set to false
, but perhaps metricbeat-*
handles this differently? In that case, maybe we should add every field we are indexing to fields.yml
but if the field isn't contained in the used mappings list, we set the mapping to enabled: false
?
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.
@sayden I can try to help clarify about when and where to map fields for stack monitoring metricsets. 😅
Consider a field, say elasticsearch.<foo>.bar.baz
that is newly (i.e. not already in master
) being collected by the elasticsearch/<foo>
metricset in data.go
. For this field:
-
Go ahead and define the field in the
module/elasticsearch/<foo>/_meta/fields.yml
file. -
Now, check if the field has a corresponding field in the
.monitoring-es-*
index mappings.- If yes: let's say the corresponding field in
.monitoring-es-*
issome_thing.some_thing_else.qux.boom
. Go ahead and define a field alias fromsome_thing.some_thing_else.qux.boom
=>elasticsearch.<foo>.bar.baz
in themodule/elasticsearch/_meta/fields.yml
file. - If no: edit the field mapping you created in step 1 in
module/elasticsearch/<foo>/_meta/fields.yml
and addenabled: false
to it. This will ensure that the field is mapped (so theassert_fields_are_documented
test assertion you are talking about in your comment will pass) but not be unnecessarily indexed.
- If yes: let's say the corresponding field in
Hopefully this now clear as mud 😃.
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.
Good idea, @chrisronline re: enabled: false
. I will edit my comment above to reflect this step.
@sayden Just a heads up that I made a mistake in the |
- Rename index_summary to index.summary in elasticsearch fields.yml - Remove call to eventsMappingXPack
- Add a missing comment about a non used field in data.go - Run make update
@sayden As part of this PR you will also need to make this metricset one of the metricsets that's enabled by default when the user runs |
I'm trying to make CI work but it's complaining about field |
@sayden Can you check whether the field shows up if you run the following?
If it doesn't, then there's something wrong in the |
Okay, I fixed the missing field thing thanks to the comment of @ycombinator I just need to fix the Go integration test now |
Pinging @elastic/integrations-services (Team:Services) |
Integration test finished and current CI error is not related! 🎉 |
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.
Code looks good, just left a few minor comments.
I'm seeing an issue here. After running this PR, this query:
Returns an empty block:
However, Maybe I'm missing something? |
@chrisronline you are right. After taking a look I have just realized that there's something missing. https://github.com/elastic/beats/pull/20615/files#diff-ecd66d9e3da80b956adc12f104330b4cR90 I'll take a look |
Okay! Thanks for the help @chrisronline ! Now it should be ok. {
"hits" : {
"hits" : [
{
"_source" : {
"elasticsearch" : {
"index" : {
"summary" : {
"total" : {
"search" : {
"query" : {
"count" : 56,
"time" : {
"ms" : 585
}
}
}
}
}
}
}
}
}
]
}
} |
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.
LGTM! All the necessary fields have data populated and the ES cluster overview charts look right!
It looks like we are no longer using |
I have moved |
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.
LGTM. Thanks for taking this on and iterating through it, @sayden!
Hey folks, any update on this? It looks ready to go but hasn't been merged yet. |
@chrisronline @sayden was out all last week so he's probably catching up on backlog. @sayden CI failures look unrelated but Beats |
Pinging @elastic/stack-monitoring (Stack monitoring) |
@ycombinator do you mean to rebase the feature branch to master I guess? |
Yeah, I guess you'll need to do both:
|
…csearch/index_summary-xpack-flag
c2ba106
to
c4934af
Compare
💚 Flaky test reportTests succeeded. Expand to view the summary
Test stats 🧪
|
…without xpack.enabled flag (#20615)
…without xpack.enabled flag (elastic#20615)
Code should be working 😅
Missing steps: