Skip to content

Cherry-pick #8106 to 6.x: Adding xpack code for ES index recovery metricset#8137

Merged
ycombinator merged 1 commit intoelastic:6.xfrom
ycombinator:backport_8106_6.x
Sep 7, 2018
Merged

Cherry-pick #8106 to 6.x: Adding xpack code for ES index recovery metricset#8137
ycombinator merged 1 commit intoelastic:6.xfrom
ycombinator:backport_8106_6.x

Conversation

@ycombinator
Copy link
Copy Markdown
Contributor

Cherry-pick of PR #8106 to 6.x branch. Original message:

This PR teaches the elasticsearch/index_recovery metricset to index index_recovery documents into .monitoring-es-6-mb-* indices. These documents should be compatible in structure to index_recovery documents in the current .monitoring-es-6-* indices indexed via the internal monitoring method.

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

don't use an underscore in package name

@ycombinator ycombinator requested a review from ruflin August 29, 2018 14:42
@exekias
Copy link
Copy Markdown
Contributor

exekias commented Aug 29, 2018

Just saw there is no changelog either in this PR or the original one, is that intended?

@ycombinator
Copy link
Copy Markdown
Contributor Author

Just saw there is no changelog either in this PR or the original one, is that intended?

Yeah, it's intentional because we don't (yet) want to document the process of using Metricbeat to perform X-Pack monitoring. We'll do that once we have X-Pack monitoring via Metricbeat working for all Elastic products that are monitored today. Otherwise users can end up with a messy setup with only some products allowed to be monitored via Metricbeat and others still needing to do internal monitoring.

@ycombinator
Copy link
Copy Markdown
Contributor Author

jenkins test this

Copy link
Copy Markdown
Contributor

@ruflin ruflin left a comment

Choose a reason for hiding this comment

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

LGTM. Failing windows test is not related. @kvch is looking into it.

@ycombinator
Copy link
Copy Markdown
Contributor Author

@ruflin Thanks for noticing that. Just to double check: my plan is to wait till the 6.x branch CI is green again, then rebase this PR against 6.x so (hopefully) it goes green too. Correct?

@ruflin
Copy link
Copy Markdown
Contributor

ruflin commented Aug 31, 2018

@ycombinator Both options are ok for me. Either rebase when it's green or also now as the failing tests are not related.

* Adding index_recovery xpack monitoring documents

* Get all recoveries if xpack.enabled is true

* Removing newline (which also reordered imports)

* Don't reuse value so much

(cherry picked from commit f6b3e78)
@ycombinator
Copy link
Copy Markdown
Contributor Author

The only failure I'm seeing in CI for this PR is in the windows libbeat build:

10:07:32 Unit testing libbeat
10:08:11 exec : Unit test FAILURE
10:08:11 At C:\Users\jenkins\workspace\elastic+beats+pull-request+multijob-windows\beat\libbeat\label\windows\src\github.com\ela
10:08:11 stic\beats\dev-tools\jenkins_ci.ps1:49 char:1
10:08:11 + exec { Get-Content build/TEST-go-unit.out | go-junit-report.exe -set- ...
10:08:11 + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
10:08:11     + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
10:08:11     + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Exec

This is the same failure that is currently occurring on CI for the target branch of this PR, 6.x (e.g. https://beats-ci.elastic.co/job/elastic+beats+6.x+multijob-windows/25/beat=libbeat,label=windows/console).

Also, this failure is unrelated to the code in this PR.

So I'm going to merge this PR now...

@ycombinator ycombinator merged commit 888a479 into elastic:6.x Sep 7, 2018
@ycombinator ycombinator deleted the backport_8106_6.x branch September 7, 2018 16:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants