[DOCS] Reformats cluster node info API (#45446)

Co-Authored-By: James Rodewig <james.rodewig@elastic.co>
This commit is contained in:
István Zoltán Szabó 2019-08-13 13:26:57 +02:00
parent 4ee7ac25ae
commit 356a632b95
2 changed files with 142 additions and 99 deletions

View File

@ -1,55 +1,161 @@
[[cluster-nodes-info]] [[cluster-nodes-info]]
=== Nodes Info === Nodes Info
Returns cluster nodes information.
[[cluster-nodes-info-api-request]]
==== {api-request-title}
`GET /_nodes` +
`GET /_nodes/{node_id}` +
`GET /_nodes/{metric}` +
`GET /_nodes/{node_id}/{metric}`
[[cluster-nodes-info-api-desc]]
==== {api-description-title}
The cluster nodes info API allows to retrieve one or more (or all) of The cluster nodes info API allows to retrieve one or more (or all) of
the cluster nodes information. the cluster nodes information. All the nodes selective options are explained
[source,js]
--------------------------------------------------
GET /_nodes
GET /_nodes/nodeId1,nodeId2
--------------------------------------------------
// CONSOLE
The first command retrieves information of all the nodes in the cluster.
The second command selectively retrieves nodes information of only
`nodeId1` and `nodeId2`. All the nodes selective options are explained
<<cluster-nodes,here>>. <<cluster-nodes,here>>.
By default, it just returns all attributes and core settings for a node: By default, it returns all attributes and core settings for a node.
[float]
[[core-info]] [[cluster-nodes-info-api-path-params]]
==== {api-path-parms-title}
`{metric}`::
(Optional, string) Limits the information returned to the specific metrics.
A comma-separated list of the following options:
+
--
`http`::
HTTP connection information.
`ingest`::
Statistics about ingest preprocessing.
`jvm`::
JVM stats, memory pool information, garbage collection, buffer pools, number
of loaded/unloaded classes.
`os`::
Operating system stats, load average, mem, swap.
`plugins`::
Details about the installed plugins and modules per node. The following
information are available for each plugin and module:
+
---
* `name`: plugin name
* `version`: version of Elasticsearch the plugin was built for
* `description`: short description of the plugin's purpose
* `classname`: fully-qualified class name of the plugin's entry point
* `has_native_controller`: whether or not the plugin has a native controller
process
---
`process`::
Process statistics, memory consumption, cpu usage, open file descriptors.
`settings`::
`thread_pool`::
Statistics about each thread pool, including current size, queue and
rejected tasks
`transport`::
Transport statistics about sent and received bytes in cluster communication.
--
include::{docdir}/rest-api/common-parms.asciidoc[tag=node-id]
[[cluster-nodes-info-api-response-body]]
==== {api-response-body-title}
`build_hash`:: `build_hash`::
Short hash of the last git commit in this release. Short hash of the last git commit in this release.
`host`:: `host`::
The node's host name. The node's host name.
`ip`:: `ip`::
The node's IP address. The node's IP address.
`name`:: `name`::
The node's name. The node's name.
`total_indexing_buffer`:: `total_indexing_buffer`::
Total heap allowed to be used to hold recently indexed Total heap allowed to be used to hold recently indexed
documents before they must be written to disk. This size is documents before they must be written to disk. This size is
a shared pool across all shards on this node, and is a shared pool across all shards on this node, and is
controlled by <<indexing-buffer,Indexing Buffer settings>>. controlled by <<indexing-buffer,Indexing Buffer settings>>.
`total_indexing_buffer_in_bytes`:: `total_indexing_buffer_in_bytes`::
Same as `total_indexing_buffer`, but expressed in bytes. Same as `total_indexing_buffer`, but expressed in bytes.
`transport_address`:: `transport_address`::
Host and port where transport HTTP connections are accepted. Host and port where transport HTTP connections are accepted.
`version`:: `version`::
Elasticsearch version running on this node. {es} version running on this node.
It also allows to get only information on `settings`, `os`, `process`, `jvm`, system:
`thread_pool`, `transport`, `http`, `plugins`, `ingest` and `indices`:
`os.refresh_interval_in_millis`::
Refresh interval for the OS statistics
`os.name`::
Name of the operating system (ex: Linux, Windows, Mac OS X)
`os.arch`::
Name of the JVM architecture (ex: amd64, x86)
`os.version`::
Version of the operating system
`os.available_processors`::
Number of processors available to the Java virtual machine
`os.allocated_processors`::
The number of processors actually used to calculate thread pool size. This
number can be set with the `processors` setting of a node and defaults to
the number of processors reported by the OS. In both cases this number will
never be larger than 32.
The `process` flag can be set to retrieve information that concern the current
running process:
`process.refresh_interval_in_millis`::
Refresh interval for the process statistics
`process.id`::
Process identifier (PID)
`process.mlockall`::
Indicates if the process address space has been successfully locked in memory
[[cluster-nodes-info-api-query-params]]
==== {api-query-parms-title}
include::{docdir}/rest-api/common-parms.asciidoc[tag=flat-settings]
include::{docdir}/rest-api/common-parms.asciidoc[tag=timeoutparms]
[[cluster-nodes-info-api-example]]
==== {api-examples-title}
[source,js] [source,js]
-------------------------------------------------- --------------------------------------------------
@ -70,56 +176,10 @@ GET /_nodes/nodeId1,nodeId2/_all
-------------------------------------------------- --------------------------------------------------
// CONSOLE // CONSOLE
The `_all` flag can be set to return all the information - or you can simply omit it. The `_all` flag can be set to return all the information - or you can omit it.
[float] If `plugins` is specified, the result will contain details about the installed
[[os-info]] plugins and modules:
==== Operating System information
The `os` flag can be set to retrieve information that concern
the operating system:
`os.refresh_interval_in_millis`::
Refresh interval for the OS statistics
`os.name`::
Name of the operating system (ex: Linux, Windows, Mac OS X)
`os.arch`::
Name of the JVM architecture (ex: amd64, x86)
`os.version`::
Version of the operating system
`os.available_processors`::
Number of processors available to the Java virtual machine
`os.allocated_processors`::
The number of processors actually used to calculate thread pool size. This number can be set
with the `processors` setting of a node and defaults to the number of processors reported by the OS.
In both cases this number will never be larger than 32.
[float]
[[process-info]]
==== Process information
The `process` flag can be set to retrieve information that concern
the current running process:
`process.refresh_interval_in_millis`::
Refresh interval for the process statistics
`process.id`::
Process identifier (PID)
`process.mlockall`::
Indicates if the process address space has been successfully locked in memory
[float]
[[plugins-info]]
==== Plugins information
`plugins` - if set, the result will contain details about the installed plugins and modules per node:
[source,js] [source,js]
-------------------------------------------------- --------------------------------------------------
@ -128,7 +188,7 @@ GET /_nodes/plugins
// CONSOLE // CONSOLE
// TEST[setup:node] // TEST[setup:node]
The result will look similar to: The API returns the following response:
[source,js] [source,js]
-------------------------------------------------- --------------------------------------------------
@ -186,20 +246,7 @@ The result will look similar to:
// TESTRESPONSE[s/"plugins": \[[^\]]*\]/"plugins": $body.$_path/] // TESTRESPONSE[s/"plugins": \[[^\]]*\]/"plugins": $body.$_path/]
// TESTRESPONSE[s/"modules": \[[^\]]*\]/"modules": $body.$_path/] // TESTRESPONSE[s/"modules": \[[^\]]*\]/"modules": $body.$_path/]
The following information are available for each plugin and module: If `ingest` is specified, the response contains details about the available
* `name`: plugin name
* `version`: version of Elasticsearch the plugin was built for
* `description`: short description of the plugin's purpose
* `classname`: fully-qualified class name of the plugin's entry point
* `has_native_controller`: whether or not the plugin has a native controller process
[float]
[[ingest-info]]
==== Ingest information
`ingest` - if set, the result will contain details about the available
processors per node: processors per node:
[source,js] [source,js]
@ -209,7 +256,7 @@ GET /_nodes/ingest
// CONSOLE // CONSOLE
// TEST[setup:node] // TEST[setup:node]
The result will look similar to: The API returns the following response:
[source,js] [source,js]
-------------------------------------------------- --------------------------------------------------
@ -289,7 +336,3 @@ The result will look similar to:
// TESTRESPONSE[s/"roles": \[[^\]]*\]/"roles": $body.$_path/] // TESTRESPONSE[s/"roles": \[[^\]]*\]/"roles": $body.$_path/]
// TESTRESPONSE[s/"attributes": \{[^\}]*\}/"attributes": $body.$_path/] // TESTRESPONSE[s/"attributes": \{[^\}]*\}/"attributes": $body.$_path/]
// TESTRESPONSE[s/"processors": \[[^\]]*\]/"processors": $body.$_path/] // TESTRESPONSE[s/"processors": \[[^\]]*\]/"processors": $body.$_path/]
The following information are available for each ingest processor:
* `type`: the processor type

View File

@ -828,8 +828,8 @@ See <<ingest-conditionals>> to learn more about the `if` field and conditional e
See <<handling-failure-in-pipelines>> to learn more about the `on_failure` field and error handling in pipelines. See <<handling-failure-in-pipelines>> to learn more about the `on_failure` field and error handling in pipelines.
The <<ingest-info,node info API>> can be used to figure out what processors are available in a cluster. The <<cluster-nodes-info,node info API>> can be used to figure out what processors are available in a cluster.
The <<ingest-info,node info API>> will provide a per node list of what processors are available. The <<cluster-nodes-info,node info API>> will provide a per node list of what processors are available.
Custom processors must be installed on all nodes. The put pipeline API will fail if a processor specified in a pipeline Custom processors must be installed on all nodes. The put pipeline API will fail if a processor specified in a pipeline
doesn't exist on all nodes. If you rely on custom processor plugins make sure to mark these plugins as mandatory by adding doesn't exist on all nodes. If you rely on custom processor plugins make sure to mark these plugins as mandatory by adding