<commit_before>[role="xpack"]
[[monitoring-production]]
== Monitoring in a production environment

In production, you should send monitoring data to a separate _monitoring cluster_
so that historical data is available even when the nodes you are monitoring are
not. For example, you can use {metricbeat} to ship monitoring data about {kib},
{es}, {ls}, and Beats to the monitoring cluster.
//If you are sending your data to the {esms-init}, see <<esms>>.

If you have at least a gold license, using a dedicated monitoring cluster also 
enables you to monitor multiple clusters from a central location.

To store monitoring data in a separate cluster:

. Set up the {es} cluster you want to use as the monitoring cluster. 
For example, you might set up a two host cluster with the nodes `es-mon-1` and 
`es-mon-2`.
+
--
[IMPORTANT]
===============================
* To monitor an {es} {major-version} cluster, you must run {es} {major-version}
on the monitoring cluster.
* There must be at least one <<ingest,ingest node>> in the monitoring
cluster; it does not need to be a dedicated ingest node.
===============================
--

.. (Optional) Verify that the collection of monitoring data is disabled on the 
monitoring cluster. By default, the `xpack.monitoring.collection.enabled` setting 
is `false`. 
+ 
--
For example, you can use the following APIs to review and change this setting:

[source,console]
----------------------------------
GET _cluster/settings

PUT _cluster/settings
{
  "persistent": {
    "xpack.monitoring.collection.enabled": false
  }
}
----------------------------------

--

.. If the {es} {security-features} are enabled on the monitoring cluster, create 
users that can send and retrieve monitoring data. 
+
--
NOTE: If you plan to use {kib} to view monitoring data, username and password 
credentials must be valid on both the {kib} server and the monitoring cluster. 

--

*** If you plan to use {metricbeat} to collect data about {es} or {kib}, 
create a user that has the `remote_monitoring_collector` built-in role and a 
user that has the `remote_monitoring_agent` 
{stack-ov}/built-in-roles.html#built-in-roles-remote-monitoring-agent[built-in role]. Alternatively, use the 
`remote_monitoring_user` {stack-ov}/built-in-users.html[built-in user]. 

*** If you plan to use HTTP exporters to route data through your production 
cluster, create a user that has the `remote_monitoring_agent` 
{stack-ov}/built-in-roles.html#built-in-roles-remote-monitoring-agent[built-in role]. 
+
--
For example, the 
following request creates a `remote_monitor` user that has the 
`remote_monitoring_agent` role:

[source, sh]
---------------------------------------------------------------
POST /_security/user/remote_monitor<commit_msg>[DOCS] Skip code snippet testing in monitoring example<commit_after>[role="xpack"]
[[monitoring-production]]
== Monitoring in a production environment

In production, you should send monitoring data to a separate _monitoring cluster_
so that historical data is available even when the nodes you are monitoring are
not. For example, you can use {metricbeat} to ship monitoring data about {kib},
{es}, {ls}, and Beats to the monitoring cluster.
//If you are sending your data to the {esms-init}, see <<esms>>.

If you have at least a gold license, using a dedicated monitoring cluster also 
enables you to monitor multiple clusters from a central location.

To store monitoring data in a separate cluster:

. Set up the {es} cluster you want to use as the monitoring cluster. 
For example, you might set up a two host cluster with the nodes `es-mon-1` and 
`es-mon-2`.
+
--
[IMPORTANT]
===============================
* To monitor an {es} {major-version} cluster, you must run {es} {major-version}
on the monitoring cluster.
* There must be at least one <<ingest,ingest node>> in the monitoring
cluster; it does not need to be a dedicated ingest node.
===============================
--

.. (Optional) Verify that the collection of monitoring data is disabled on the 
monitoring cluster. By default, the `xpack.monitoring.collection.enabled` setting 
is `false`. 
+ 
--
For example, you can use the following APIs to review and change this setting:

[source,console]
----------------------------------
GET _cluster/settings

PUT _cluster/settings
{
  "persistent": {
    "xpack.monitoring.collection.enabled": false
  }
}
----------------------------------
// TEST[skip:security errs]
--

.. If the {es} {security-features} are enabled on the monitoring cluster, create 
users that can send and retrieve monitoring data. 
+
--
NOTE: If you plan to use {kib} to view monitoring data, username and password 
credentials must be valid on both the {kib} server and the monitoring cluster. 

--

*** If you plan to use {metricbeat} to collect data about {es} or {kib}, 
create a user that has the `remote_monitoring_collector` built-in role and a 
user that has the `remote_monitoring_agent` 
{stack-ov}/built-in-roles.html#built-in-roles-remote-monitoring-agent[built-in role]. Alternatively, use the 
`remote_monitoring_user` {stack-ov}/built-in-users.html[built-in user]. 

*** If you plan to use HTTP exporters to route data through your production 
cluster, create a user that has the `remote_monitoring_agent` 
{stack-ov}/built-in-roles.html#built-in-roles-remote-monitoring-agent[built-in role]. 
+
--
For example, the 
following request creates a `remote_monitor` user that has the 
`remote_monitoring_agent` role:

[source, sh]
---------------------------------------------------------------
POST /_security/user/remote_monitor
{'fraction_non_alphanumeric': 0.15259391771019679, 'fraction_numerical': 0.0007155635062611807, 'mean_word_length': 3.4943729903536975, 'pattern_counts': {'":': 4, '<': 11, '<?xml version=': 0, '>': 11, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3097692', 'n_tokens_mistral': 1551, 'n_tokens_neox': 1530, 'n_words': 670}