Stack Monitoring - Elasticsearch Nodes not displayed as monitored with Metricbeat

Hi,

I'm trying to set up Stack Monitoring and I went through all the steps from here: Collecting Elasticsearch monitoring data with Metricbeat | Elasticsearch Guide [8.2] | Elastic

  1. Enabled the collection of monitoring data. Check the current settings below:
    "xpack" : {
      "monitoring" : {
        "elasticsearch" : {
          "collection" : {
            "enabled" : "false"
          }
        },
        "collection" : {
          "enabled" : "true"
        }
      }
    }
  1. Installed metricbeat on each node and enabled the elasticsearch-xpack module:
- module: elasticsearch
  xpack.enabled: true
  period: 10s
  scope: node
  hosts: [ "https:/elasticsearch01:9200", "https:/elasticsearch02:9200", "https://elasticsearch03:9200"]
  username: "user"
  password: "password"
  ssl.certificate_authorities: ["/etc/metricbeat/cert.crt"]
  1. Sent the monitoring data to the same cluster:
output.elasticsearch:
  hosts: [ "https:/elasticsearch01:9200", "https:/elasticsearch02:9200", "https://elasticsearch03:9200"]
  protocol: "https"
  username: "user"
  password: "password"
  output.elasticsearch.ssl.certificate_authorities:
    - "/etc/metricbeat/cert.crt"

  1. Started metricbeat.
  2. Disabled the default collection of Elasticsearch monitoring metrics.
  3. Disabled the system module.

However, this is the result from Stack Monitoring. Here "some" means all hot and warm nodes.

What am I missing here?
Any ideas/suggestions would be much appreciated.

Other details:

  • Elastic version: 8.2.0
  • Metricbeat version: 8.2.0
  • the cluster has 3 dedicated master nodes. The best practices in our case suggest to set scope: cluster in the elasticsearch-xpack module which will require a single cluster endpoint in the hosts: [] that will not direct requests to dedicated master nodes. Basically a load-balancer for hot & warm nodes (...in my understanding)? However, at the moment considering this is still not clear for us, we decided to go with scope: node even if this means additional load on the elected master node.