diff --git a/docs/reference/monitoring/how-monitoring-works.asciidoc b/docs/reference/monitoring/how-monitoring-works.asciidoc index 2a89f0aec65..126ec1a0880 100644 --- a/docs/reference/monitoring/how-monitoring-works.asciidoc +++ b/docs/reference/monitoring/how-monitoring-works.asciidoc @@ -6,8 +6,8 @@ How it works ++++ -Each {es} node, {ls} node, {kib} instance, and Beat is considered unique in the -cluster based on its persistent UUID, which is written to the +Each {es} node, {ls} node, {kib} instance, and Beat instance is considered +unique in the cluster based on its persistent UUID, which is written to the <> directory when the node or instance starts. Monitoring documents are just ordinary JSON documents built by monitoring each diff --git a/docs/reference/monitoring/troubleshooting.asciidoc b/docs/reference/monitoring/troubleshooting.asciidoc index 74e18558302..120e80083b8 100644 --- a/docs/reference/monitoring/troubleshooting.asciidoc +++ b/docs/reference/monitoring/troubleshooting.asciidoc @@ -14,6 +14,10 @@ a ticket in the https://support.elastic.co/customers/s/login/[Elastic Support portal]. Or post in the https://discuss.elastic.co/[Elastic forum]. +[discrete] +[[monitoring-troubleshooting-no-data]] +=== No monitoring data is visible in {kib} + *Symptoms*: There is no information about your cluster on the *Stack Monitoring* page in {kib}. @@ -27,3 +31,33 @@ monitoring data by using {metricbeat} the indices have `-mb` in their names. If the indices do not exist, review your configuration. For example, see <>. +[discrete] +[[monitoring-troubleshooting-uuid]] +=== Monitoring data for some {stack} nodes or instances is missing from {kib} + +*Symptoms*: +The *Stack Monitoring* page in {kib} does not show information for some nodes or +instances in your cluster. + +*Resolution*: +Verify that the missing items have unique UUIDs. Each {es} node, {ls} node, +{kib} instance, Beat instance, and APM Server is considered unique based on its +persistent UUID, which is found in its `path.data` directory. Alternatively, you +can find the UUIDs in the product logs at startup. + +In some cases, you can also retrieve this information via APIs: + +* For Beat instances, use the HTTP endpoint to retrieve the `uuid` property. +For example, refer to +{filebeat-ref}/http-endpoint.html[Configure an HTTP endpoint for {filebeat} metrics]. +* For {kib} instances, use the +{kibana-ref}/access.html#status[status endpoint] to retrieve the `uuid` property. +* For {ls} nodes, use the +{logstash-ref}/monitoring-logstash.html[monitoring APIs root resource] to +retrieve the `id` property. + +TIP: When you install {es}, {ls}, {kib}, APM Server, or Beats, their `path.data` +directory should be non-existent or empty; do not copy this directory from other +installations. + +