This provides the same -- more useful -- index memory chart to the index page, instead of just "Lucene Memory", it now breaks down what it shows just like the Node page as as more generalized "Index Memory" chart. It also rolls Fielddata into the Index Memory. With Fielddata now in the Index Memory chart, I decided to add the Segment Count chart to the Index page.
Original commit: elastic/x-pack-elasticsearch@4e3490ce9c
When the monitoring tests are run in isolation, they succeed. However, when the whole suite of
REST tests is being run at the same time, the "Bulk indexing of monitoring data" intermittently
fails with a timeout. Therefore, a timeout of 60 seconds has been added.
Closeselastic/elasticsearch#2809
Original commit: elastic/x-pack-elasticsearch@d11dc7a2be
This change creates the CryptoService during xpack plugin construction,
and also collapses the only implementation of CryptoService into a
class instead of an interface.
Original commit: elastic/x-pack-elasticsearch@7f00a5d6ef
This changes the xpack.monitoring.agent.* settings so that they fall under xpack.monitoring.collection.*.
- This also changes Kibana's equivalent data_collection to collection.
Original commit: elastic/x-pack-elasticsearch@a69bc18055
This changes the way that Kibana (and future applications) send their monitoring stats to Elasticsearch.
Instead of sending their payloads with the System ID (e.g., "kibana") and System Version (e.g., "5.0.0-alpha4"), it now expects the System ID and System _API_ Version (e.g., "2"). This means a few things:
- Future releases are automatically compatible with previous releases as long as the API version doesn't change.
- Users don't have to update Kibana at the exact same time as their cluster (which technically means rolling updates were temporarily blockers of Kibana monitoring before).
- We can accept old API versions (if we need to make a breaking change) and automatically up-convert them to the latest API version. (We are in full control of how far back we choose to accept)
In general, this change implies that users should be updating their Monitoring cluster before their _monitored_ cluster(s) to get the best opportunity of monitoring backwards compatibility. That way if any API change does occur, then it can up-convert as needed. Then, any ES node should be updated, and only then should Kibana be updated. This is not required in any way, but it will give the smoothest experience.
Original commit: elastic/x-pack-elasticsearch@d3c24936e1
Today throughout the codebase, catch throwable is used with reckless
abandon. This is dangerous because the throwable could be a fatal
virtual machine error resulting from an internal error in the JVM, or an
out of memory error or a stack overflow error that leaves the virtual
machine in an unstable and unpredictable state. This commit removes
catch throwable from the codebase and removes the temptation to use it
by modifying listener APIs to receive instances of Exception instead of
the top-level Throwable.
Relates elastic/elasticsearch#2694
Original commit: elastic/x-pack-elasticsearch@7ecdd7d978
This is the xplugins side of moving the client dependency for rest
handlers to the handleRequest method
Original commit: elastic/x-pack-elasticsearch@ce66e35e7b
