# ELK Monitoring Cluster - issue with indexes reaching

**URL:** <https://discuss.elastic.co/t/elk-monitoring-cluster-issue-with-indexes-reaching/339021>\
**Category:** Elasticsearch\
**Created:** [July 23, 2023, 9:02pm UTC](https://discuss.elastic.co/t/elk-monitoring-cluster-issue-with-indexes-reaching/339021 "2023-07-23T21:02:57Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![dominbdg](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dominbdg/32/102457_2.png) [@dominbdg](https://discuss.elastic.co/u/dominbdg)\
**Post date:** [July 23, 2023, 9:02pm UTC](https://discuss.elastic.co/t/elk-monitoring-cluster-issue-with-indexes-reaching/339021/1 "2023-07-23T21:02:57Z")

</div>

Hello,  
I have following issue.  
I created ELK Onenode cluster with self-monitoring enabled (as ELK Monitoring Cluster)  
I joined another ELK Cluster environment to Monitoring Cluster.  
From another ELK Cluster I configured metricbeats to connect to elasticsearch from Monitoring Cluster and elasticsearch-xpack module to access locally elasticcsearch for monitoring.

My environment is configured that way that ELK Cluster is sending data to elasticsearch in monitoring Cluster using port 9200. This is only one port enabled between servers.

My issue is - when from Monitoring Cluster I'm going to monitored ELK Cluster and want to see indexes, after couple of minutes I'm receiving error 504.

The question is - should I configure something more there ?  
I was looking about to configure beats-xpack module - will I need it to successfull communication ?

---

<div class="post-metadata">

**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\
**Post date:** [July 23, 2023, 11:05pm UTC](https://discuss.elastic.co/t/elk-monitoring-cluster-issue-with-indexes-reaching/339021/2 "2023-07-23T23:05:49Z")

</div>

@dominbdg

monitoring more than 1 cluster with a single monitoring cluster is a commercially licensed feature (Multi-Stack Monitoring), perhaps that is the issue if you are using a Basic / Free license, See [here](https://www.elastic.co/subscriptions)

 ![Screenshot 2023-07-23 at 4.04.41 PM](https://us1.discourse-cdn.com/elastic/original/3X/0/5/0562c666bdade65931c004ea99ddca3fdd294967.png)

What license are you running? You can also check the elasticsearch or metricbeat logs as well.

---

<div class="post-metadata">

**Author:** ![dominbdg](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dominbdg/32/102457_2.png) [@dominbdg](https://discuss.elastic.co/u/dominbdg)\
**Post date:** [July 23, 2023, 11:18pm UTC](https://discuss.elastic.co/t/elk-monitoring-cluster-issue-with-indexes-reaching/339021/3 "2023-07-23T23:18:49Z")

</div>

no, this is not this issue because right now I have one cluster connected to monitoring - both of them have platinum license.

my issue is that - when from cluster with monitoring I'm going to elasticsearch of monitored cluster, click indices - it is searching and .. error 504 . Maybe this is related with some timeout ?

---

<div class="post-metadata">

**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\
**Post date:** [July 23, 2023, 11:24pm UTC](https://discuss.elastic.co/t/elk-monitoring-cluster-issue-with-indexes-reaching/339021/4 "2023-07-23T23:24:43Z")

</div>

Apologies I am still a little unclear ...

What version is everything.

Perhaps a screenshot AND you should definitely look at the logs of the elasticsearch cluster that is the monitoring cluster.

> [@dominbdg](#):
>
> cluster with self-monitoring enabled (as ELK Monitoring Cluster)  
> I joined another ELK Cluster environment to Monitoring Cluster.

Also if I am reading this right 1 cluster is self-monitoring (deprecated) and one cluster is using metricbeat easlticsearch-xpack module (go forward method).... not sure that is the best setup.... that could be a problem as well and I believe that monitoring indices are different.

Not saying that IS the issue... but not sure if you can mix them.

Self Monitoring Indices...

 ![Screenshot 2023-07-23 at 4.27.57 PM](https://us1.discourse-cdn.com/elastic/original/3X/8/d/8dfbbef006548601f97d2f6cafd25ae3531611ab.png)

Metricbeat Monitoring

Datastream + backing indices

 ![Screenshot 2023-07-23 at 4.37.23 PM](https://us1.discourse-cdn.com/elastic/original/3X/7/8/78c69e9d14a343cc596bf19d6946c9257526b9ea.png)

 ![Screenshot 2023-07-23 at 4.37.35 PM](https://us1.discourse-cdn.com/elastic/original/3X/1/7/1747ce01a88f8a4df39168076faf79552cd636e9.png)

---

<div class="post-metadata">

**Author:** ![dominbdg](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dominbdg/32/102457_2.png) [@dominbdg](https://discuss.elastic.co/u/dominbdg)\
**Post date:** [July 23, 2023, 11:45pm UTC](https://discuss.elastic.co/t/elk-monitoring-cluster-issue-with-indexes-reaching/339021/5 "2023-07-23T23:45:49Z")

</div>

ok,  
You said that this is not correct setup.  
May I ask how should I implement monitoring ?

Let me explain my implementation:  
On one server I installed called as ELK Monitoring Cluster - elasticsearch and kibana.  
I choosed under monitoring tab in kibana - enable self monitoring

On the another server which I would like to have be monitored:  
in elasticsearch I have installed metricbeat.  
in /etc/metricbeat/metricbeat.yml I included elasticsearch configuration (host,username,password) points to ELK Monitoring.  
enabled elasticsearch-xpack.yml in modules,  
in /etc/metricbeat/modules/elasticsearch.yml included configuration of local elasticsearch.

In monitoring cluster I see monitoring environment, all looks like fine,  
but when I click on monitored environment -\> elasticsearch -\> indices  
it is looking for indices and after couple of minutes cannot find anythhing and throws 504

I have a question also - if my implementation of monitoring is correct or I should change it.

---

<div class="post-metadata">

**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\
**Post date:** [July 24, 2023, 12:05am UTC](https://discuss.elastic.co/t/elk-monitoring-cluster-issue-with-indexes-reaching/339021/6 "2023-07-24T00:05:23Z")

</div>

What Version?

I did not say your configuration _is not_ correct. I just said it _could_ be an issue... And that is not how we would typically suggest monitoring more than 1 cluster.

> [@dominbdg](#):
>
> May I ask how should I implement monitoring ?

Perhaps take a look at the documentation [here](https://www.elastic.co/guide/en/elasticsearch/reference/current/configuring-metricbeat.html) and [here](https://www.elastic.co/guide/en/elasticsearch/reference/current/monitoring-overview.html)

You could monitor both with a single metricbeat module / single metricbeat instance... you can put more than 1 cluster in the elasticsearch-xpack.yml

I just did this and it works as expected.

example

```auto
- module: elasticsearch
  xpack.enabled: true
  scope: cluster
  period: 10s
  hosts: ["http://localhost:9200"]
  metricsets:
    - node
    - node_stats
    - index
    - index_recovery
    - index_summary
    - ingest_pipeline
    - shard
    - ml_job

- module: elasticsearch
  xpack.enabled: true
  scope: cluster
  period: 10s
  hosts: ["http://otherhost:9200"]
  metricsets:
    - node
    - node_stats
    - index
    - index_recovery
    - index_summary
    - ingest_pipeline
    - shard
    - ml_job

```

However now that you have enabled self monitoring ...  
`xpack.monitoring.collection : true`

I think you are going to need to disable that `false` you can take a look at the settings [here](https://www.elastic.co/guide/en/elasticsearch/reference/current/monitoring-settings.html)

Why you are getting a `504` I have not clue... you would need to look at the logs.

---

<div class="post-metadata">

**Author:** ![dominbdg](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dominbdg/32/102457_2.png) [@dominbdg](https://discuss.elastic.co/u/dominbdg)\
**Post date:** [July 24, 2023, 12:18am UTC](https://discuss.elastic.co/t/elk-monitoring-cluster-issue-with-indexes-reaching/339021/7 "2023-07-24T00:18:39Z")

</div>

maybe there is my issue.

My code of elasticsearch module don't cover things You showed me :

```auto
- module: elasticsearch
  xpack.enabled: true
  period: 10s
  hosts: ["http://localhost:9200"]
  username: "elastic"
  password: "elastic-password"

```

I will try to implement elasticsearch-xpack like You showed me

---

<div class="post-metadata">

**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\
**Post date:** [July 24, 2023, 12:50am UTC](https://discuss.elastic.co/t/elk-monitoring-cluster-issue-with-indexes-reaching/339021/8 "2023-07-24T00:50:20Z")

</div>

Again....what version?... There has been changes 🙂

Make sure you look at the correct documentation and the correct module

Ohh and you might need to clean up the old monitoring indices

---

<div class="post-metadata">

**Author:** ![dominbdg](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dominbdg/32/102457_2.png) [@dominbdg](https://discuss.elastic.co/u/dominbdg)\
**Post date:** [July 24, 2023, 1:27pm UTC](https://discuss.elastic.co/t/elk-monitoring-cluster-issue-with-indexes-reaching/339021/9 "2023-07-24T13:27:04Z")

</div>

I'm using latest version,  
both environments are running version 8.8.1

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [August 21, 2023, 1:27pm UTC](https://discuss.elastic.co/t/elk-monitoring-cluster-issue-with-indexes-reaching/339021/10 "2023-08-21T13:27:11Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
