No need to set `xpack.monitoring.collection.enabled` to true when using metricbeat-based stack monitoring?

Elastic Stack Elasticsearch
1

Reading this document, I'm testing stack monitoring using metricbeat not Legacy collection method.

In this stack monitoring document, it says:

1.Enable the collection of monitoring data.
Set xpack.monitoring.collection.enabled to true on the production cluster. By default, it is is disabled ( false ).

But I don't understand why this parameter needs to be set to true, because metricbeat can access to Elasticsearch(9200 port) API to collect its metric data whether this parameter is true of false. In other words, I don't want collect any metric data in this (production) cluster but want to store them in the monitoring cluster.
Also with regard to kibana monitoring, I can use metricbeat to collect metrics. So this parameter can be false.
Anyone knows this is just a document bug, or there is some reason we should change this parameter true?

Thanks.
Tetsuya

1 Like
2

Hi @tetsuyasodo,

Technically, you are correct. You do not need to enable this setting for Metricbeat monitoring to work properly. In the future, this will be removed from the docs. However, we currently have a need to do this for Metricbeat users, where cluster alerts are currently created and managed by the legacy monitoring architecture, which is a known issue too.

We are actively trying to migrate these alerts to Kibana alerting which will make the above issue moot. You can follow along on that effort with this ticket.

For now, follow the steps as written as they are designed to help get around this issue. Once we have finished the migration to Kibana alerting, we will update the docs and remove that step.

2 Likes
3

Hi @chrisronline ,

Thank you for your comment. I could deeply understand the background and the current status.
To confirm this index for the cluster alerts, I saw indices in my fresh ES 7.10.1 cluster this morning after "xpack.monitoring.collection.enabled" has been set to true. But I can't find this index (.monitoring-alerts-*) in the cluster. (My 3 node ES cluster and X-pack enabled for trial)
Any additional condition required to see this index?

# curl localhost:9200/_cat/indices
green open .triggered_watches              2WVkKTt1SyaiK5Gpfp-tNg 1 1    6    0  10.1kb     5kb
green open .apm-custom-link                7LPQqoMmSQmZ5kge6ppNFw 1 1    0    0    416b    208b
green open .kibana_task_manager_1          diVbujArRBekdsvifNX8iA 1 1    5   60 157.3kb  50.9kb
green open .monitoring-es-7-2020.12.12     -UFXIP0dRmap03pl25GQZw 1 1 1379 1332   2.9mb   1.2mb
green open .apm-agent-configuration        WN0FRVPtTGyNxapXH60znw 1 1    0    0    416b    208b
green open .kibana-event-log-7.10.1-000001 FY6JO9zcTWCe2UWiL8HvmA 1 1    3    0  32.9kb  16.4kb
green open .monitoring-kibana-7-2020.12.12 jlXpOqwoQg-8shUt74vwMA 1 1  476    0 412.5kb 158.2kb
green open .watches                        gv8sYbTVSsOGt2cOy4heTA 1 1    6   66 214.6kb 154.2kb
green open .kibana_1                       3uEt79h5SJicLtNzLXrVew 1 1   29   34   4.2mb   2.1mb
4

Hi @tetsuyasodo,

The index will only exist when one of the watches enters a "firing" state.

You can use the Watcher UI in Kibana (Stack Management -> Watcher) to see if the six watches exist for Stack Monitoring.

1 Like
5

I completely understand.
I've tested Watcher UI and I can see six watchers exist.
Thank you for your clear explanation.

6

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