-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Add server OS information to telemetry stats #23793
Conversation
💔 Build Failed |
In general LGTM, I want to make sure, when its not Linux, we cover all information (and if not what will not be captured)
|
@AlonaNadler Yes, you'll be able to tell which Windows they're running by referencing the "release" version against this table: https://en.wikipedia.org/wiki/Comparison_of_Microsoft_Windows_versions for Mac, use: https://en.wikipedia.org/wiki/Darwin_(operating_system) After looking through this more I'm going to pare down what we track to simply be this:
|
cc6d475
to
0965cb7
Compare
💚 Build Succeeded |
fetch: () => { | ||
return buffer.flush(); | ||
fetch: async () => { | ||
return await buffer.flush(); |
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 buffer.flush()
returns a promise, then isn't this fundamentally the same as the previous code? A returned promise will have to be awaited by the caller either way, 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.
Spencer got me in this habit of awaiting to make it more clear what was going on and to prevent bugs when you want to catch any exceptions that an async function might throw. If you were to add try/catch around this without awaiting you would never catch anything.
|
||
if (os) { | ||
incrementByKey(cluster.os.platform, os.platform); | ||
incrementByKey(cluster.os.distro, os.distro); |
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.
Have you tested this when the function is processing Logstash and Beats info? LMK if you have questions about how to do that
0965cb7
to
dafc2de
Compare
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.
Tested with Beats and Logstash data and things look good. The os key does not appear on those parts of the telemetry payload and nothing breaks 😄
fetch: () => { | ||
return buffer.flush(); | ||
fetch: async () => { | ||
return await buffer.flush(); |
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.
Spencer got me in this habit of awaiting to make it more clear what was going on and to prevent bugs when you want to catch any exceptions that an async function might throw. If you were to add try/catch around this without awaiting you would never catch anything.
💔 Build Failed |
💔 Build Failed |
retest |
💔 Build Failed |
retest |
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 pending green build!
💔 Build Failed |
💚 Build Succeeded |
* Add server OS data to monitoring collector and telemetry * Fixup naming * Fix functional tests
Summary
Fixes #21978
Adds 4 new keys to the
kibana_stats.os
object in the monitoring index that tracks the Kibana server OS. I'm using thegetos
package that the Reporting plugin also uses to get more detailed distribution data when running on Linux.The release keys include both the name and the version number. I put these in the same key so that when we rollup these values for telemetry purposes the data makes sense. Rolling up just the version number by itself is meaningless at best, and could lead to inaccurate analysis at worst. If two Kibana instances are both running on version 10 of two different OSes (eg. windows and linux), rolling these up to say there are two 10.0 versions running doesn't really mean what we want.
Also adds new
os
key to thekibana_stats
key of data included in telemetry stats. This represents rolled up values similar to how we roll up version counts.