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.

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

Metricbeat-indexed kibana_stats docs differ from internally-indexed ones #48490

Closed
igoristic opened this issue Oct 17, 2019 · 12 comments
Closed
Assignees
Labels
bug Fixes for quality problems that affect the customer experience Team:Monitoring Stack Monitoring team

Comments

@igoristic
Copy link
Contributor

igoristic commented Oct 17, 2019

Related: #34940.

Tested on 7.4.

Internally-indexed kibana_stats docs contain the following keys that are absent from the Metricbeat-indexed kibana_stats docs:

Sourced from: FAILURE elastic/estf-monitoring-snapshots#7.4 90237f3 multijob-kibana - 20191012053923-E5D2DAC4

JSON: kibana.zip

@igoristic igoristic added bug Fixes for quality problems that affect the customer experience Team:Monitoring Stack Monitoring team labels Oct 17, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/stack-monitoring (Team:Monitoring)

@chrisronline
Copy link
Contributor

@igoristic Were you able to reproduce this locally?

@igoristic
Copy link
Contributor Author

@chrisronline What do you mean by "able to reproduce this locally"?

Do you mean by running the parity test via link? If so then yes. I also included the json results in the description.

Or, do you mean by downloading 7.4 ES, Kibana, and Metricbeat; installing and testing kibana_stats docs with and w/o Metricbeat manually? I think this is a lengthy process that should be reserved for the "investigation/fixing process" and not the "reporting process".

Let me know what you think, I'm happy to test it manually if need be

@chrisronline
Copy link
Contributor

I guess both to some degree.

Since parity tests involve multiple stack products, part of the process of responding to them is identifying where the problem lies - is there something up with Metricbeat? Kibana? or maybe ES? Typically, once we identify this, we outline our steps that lead us to that conclusion and then file an issue in the appropriate repo.

Were you able to identify what exactly is going on? Are those fields always missing? Is it a timing issue? Were these missing ones recently added to 7.4?

@igoristic
Copy link
Contributor Author

Okay, I'll try to investigate them as well, just thought those were two different phases based on this template: #35799

@chrisronline
Copy link
Contributor

Yea that ticket is similar for sure, but before @ycombinator filed the ticket, he responded to the failure email with some investigation notes after diving in a bit:

This is failing because, once again, we have differences in what's being indexed natively by Kibana vs. when Kibana is monitored with Metricbeat: #35799 :(

I don't know for sure but there were changes made recently in the native collection code, to do with changing the frequency of telemetry (kibana_stats.usage) collection. These changes shouldn't have caused the above differences but they might be worth looking into as that was when the native collection code was most-recently touched. The PR that made those changes is here: #34609.

@igoristic
Copy link
Contributor Author

This makes sense now. Thank you Chris!

@igoristic
Copy link
Contributor Author

This same test is now passing, going to see if it comes up again during next couple of days then close it if not

@chrisronline
Copy link
Contributor

Definitely some timing issues happening. We don't necessarily need to investigate now, but we should dive deeper at some point and figure out how we can make these more stable

@cachedout
Copy link
Contributor

@chrisronline I will try to investigate further this week during my on-call rotation.

@cachedout cachedout self-assigned this Oct 21, 2019
@cachedout
Copy link
Contributor

I have opened this PR and expect a discussion on these fields may continue there: https://github.com/elastic/elastic-stack-testing/pull/402

@chrisronline
Copy link
Contributor

Tests seem stable now. I'm closing this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Fixes for quality problems that affect the customer experience Team:Monitoring Stack Monitoring team
Projects
None yet
Development

No branches or pull requests

4 participants