[Stack Monitoring] Add I/O metrics for Elasticsearch

[cachedout]

Summary

Add I/O metrics for Elasticsearch to Stack Monitoring. This metric tracks I/O operations/sec for the system on which Elasticsearch is running.

The following metric is now displayed on node overview pages:

On certain platforms, such as OS X, Elasticsearch does not collect I/O metrics. To account for this, a warning is displayed in the tool tip:

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

• This was checked for cross-browser compatibility, including a check against IE11
• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• This was checked for keyboard-only and screenreader accessibility

For maintainers

• This was checked for breaking API changes and was labeled appropriately
• This includes a feature addition or change that requires a release note and was labeled appropriately

[cachedout]

@elasticmachine merge upstream

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[igoristic]

Great job! Looks good 👍 Approved, so long as all the checks pass

[chrisronline]

I don't recall any precedence for this, but is it better for users if we do not bother displaying this chart if the node is running on an unsupported platform (more specifically, if the ES data does not exist)?

[cachedout]

@chrisronline Ultimately, yes, that would be better. I went this route for two reasons.

1. Progress over perfection. We can get this in right now and work back on the task of selectively displaying the metric at a later date.

2. My strong suspicion (though we should probably back this up with telemetry data) is that the vast majority of Elasticsearch users are on a platform that does collect this data and therefore this wouldn't be an issue.

[chrisronline]

Sounds good. I do think that showing a chart that we know will be empty is not a great UX, but we don't have to address it right now.

Also, there are missing labels on this PR

[cachedout]

I do think that showing a chart that we know will be empty is not a great UX, but we don't have to address it right now.

@chrisronline Just so there's no confusion -- I agree with this. In thinking this through, I think there are a few ways in which we'll want to filter/display the metrics that are shown in the long run. For example, I think we'll soon encounter a need to show different metrics based on the role a node has in a cluster. So, I think it's best dealt with in a change that ensures that we account for all of that. I'll create a new issue shortly that expands on my thinking in that regard.

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request