OpenSearch/docs/reference/cat/nodeattrs.asciidoc

88 lines
3.1 KiB
Plaintext
Raw Normal View History

[[cat-nodeattrs]]
== cat nodeattrs
The `nodeattrs` command shows custom node attributes.
For example:
[source,js]
--------------------------------------------------
GET /_cat/nodeattrs?v
--------------------------------------------------
// CONSOLE
// TEST[s/\?v/\?v&s=node,attr/]
// Sort the resulting attributes so we can assert on them more easilly
Could look like:
[source,txt]
--------------------------------------------------
node host ip attr value
...
node-0 127.0.0.1 127.0.0.1 testattr test
...
--------------------------------------------------
// TESTRESPONSE[s/\.\.\.\n$/\n(.+ xpack\\.installed true\n)?\n/]
// TESTRESPONSE[s/\.\.\.\n/(.+ ml\\..+\n)*/ _cat]
// If xpack is not installed then neither ... with match anything
// If xpack is installed then the first ... contains ml attributes
// and the second contains xpack.installed=true
The first few columns (`node`, `host`, `ip`) give you basic info per node
and the `attr` and `value` columns give you the custom node attributes,
one per line.
[float]
=== Columns
Below is an exhaustive list of the existing headers that can be
2015-09-18 07:05:19 -04:00
passed to `nodeattrs?h=` to retrieve the relevant details in ordered
columns. If no headers are specified, then those marked to Appear
by Default will appear. If any header is specified, then the defaults
are not used.
Aliases can be used in place of the full header name for brevity.
Columns appear in the order that they are listed below unless a
different order is specified (e.g., `h=attr,value` versus `h=value,attr`).
When specifying headers, the headers are not placed in the output
by default. To have the headers appear in the output, use verbose
mode (`v`). The header name will match the supplied value (e.g.,
`pid` versus `p`). For example:
[source,js]
--------------------------------------------------
GET /_cat/nodeattrs?v&h=name,pid,attr,value
--------------------------------------------------
// CONSOLE
// TEST[s/,value/,value&s=node,attr/]
// Sort the resulting attributes so we can assert on them more easilly
Might look like:
Enforce that responses in docs are valid json (#26249) All of the snippets in our docs marked with `// TESTRESPONSE` are checked against the response from Elasticsearch but, due to the way they are implemented they are actually parsed as YAML instead of JSON. Luckilly, all valid JSON is valid YAML! Unfurtunately that means that invalid JSON has snuck into the exmples! This adds a step during the build to parse them as JSON and fail the build if they don't parse. But no! It isn't quite that simple. The displayed text of some of these responses looks like: ``` { ... "aggregations": { "range": { "buckets": [ { "to": 1.4436576E12, "to_as_string": "10-2015", "doc_count": 7, "key": "*-10-2015" }, { "from": 1.4436576E12, "from_as_string": "10-2015", "doc_count": 0, "key": "10-2015-*" } ] } } } ``` Note the `...` which isn't valid json but we like it anyway and want it in the output. We use substitution rules to convert the `...` into the response we expect. That yields a response that looks like: ``` { "took": $body.took,"timed_out": false,"_shards": $body._shards,"hits": $body.hits, "aggregations": { "range": { "buckets": [ { "to": 1.4436576E12, "to_as_string": "10-2015", "doc_count": 7, "key": "*-10-2015" }, { "from": 1.4436576E12, "from_as_string": "10-2015", "doc_count": 0, "key": "10-2015-*" } ] } } } ``` That is what the tests consume but it isn't valid JSON! Oh no! We don't want to go update all the substitution rules because that'd be huge and, ultimately, wouldn't buy much. So we quote the `$body.took` bits before parsing the JSON. Note the responses that we use for the `_cat` APIs are all converted into regexes and there is no expectation that they are valid JSON. Closes #26233
2017-08-17 09:02:10 -04:00
[source,txt]
--------------------------------------------------
name pid attr value
...
node-0 19566 testattr test
...
--------------------------------------------------
// TESTRESPONSE[s/19566/\\d*/]
// TESTRESPONSE[s/\.\.\.\n$/\n(.+ xpack\\.installed true\n)?\n/]
// TESTRESPONSE[s/\.\.\.\n/(.+ ml\\..+\n)*/ _cat]
// If xpack is not installed then neither ... with match anything
// If xpack is installed then the first ... contains ml attributes
// and the second contains xpack.installed=true
[cols="<,<,<,<,<",options="header",subs="normal"]
|=======================================================================
|Header |Alias |Appear by Default |Description |Example
|`node`|`name`|Yes|Name of the node|DKDM97B
|`id` |`nodeId` |No |Unique node ID |k0zy
|`pid` |`p` |No |Process ID |13061
|`host` |`h` |Yes |Host name |n1
|`ip` |`i` |Yes |IP address |127.0.1.1
|`port` |`po` |No |Bound transport port |9300
|`attr` | `attr.name` | Yes | Attribute name | rack
|`value` | `attr.value` | Yes | Attribute value | rack123
|=======================================================================