remove monitoring sub

Author: colleenmcginnis

deploy-manage/monitor/stack-monitoring/es-local-exporter.md

@@ -13,7 +13,7 @@ products:
 :::{include} _snippets/legacy-warning.md
 :::
 
-The `local` exporter is the default exporter in {{monitoring}}. It routes data back into the same (local) cluster. In other words, it uses the production cluster as the monitoring cluster. For example:
+The `local` exporter is the default exporter in X-Pack monitoring. It routes data back into the same (local) cluster. In other words, it uses the production cluster as the monitoring cluster. For example:
 
 ```yaml
 xpack.monitoring.exporters.my_local_exporter: <1>
@@ -27,7 +27,7 @@ This exporter exists to provide a convenient option when hardware is simply not
 
 * All indexing impacts the local cluster and the nodes that hold the monitoring indices' shards.
 * Most collectors run on the elected master node. Therefore most indexing occurs with the elected master node as the coordinating node, which is a bad practice.
-* Any usage of {{monitoring}} for {{kib}} uses the local cluster’s resources for searches and aggregations, which means that they might not be available for non-monitoring tasks.
+* Any usage of X-Pack monitoring for {{kib}} uses the local cluster’s resources for searches and aggregations, which means that they might not be available for non-monitoring tasks.
 * If the local cluster goes down, the monitoring cluster has inherently gone down with it (and vice versa), which generally defeats the purpose of monitoring.
 
 For the `local` exporter, all setup occurs only on the elected master node. This means that if you do not see any monitoring templates or ingest pipelines, the elected master node is having issues or it is not configured in the same way. Unlike the `http` exporter, the `local` exporter has the advantage of accessing the monitoring cluster’s up-to-date cluster state. It can therefore always check that the templates and ingest pipelines exist without a performance penalty. If the elected master node encounters errors while trying to create the monitoring resources, it logs errors, ignores that collection, and tries again after the next collection.

deploy-manage/monitor/stack-monitoring/es-pause-export.md

@@ -14,7 +14,7 @@ products:
 :::{include} _snippets/legacy-warning.md
 :::
 
-To stop generating {{monitoring}} data in {{es}}, disable data collection:
+To stop generating X-Pack monitoring data in {{es}}, disable data collection:
 
 ```yaml
 xpack.monitoring.collection.enabled: false
@@ -43,7 +43,7 @@ xpack.monitoring.exporters.my_http_exporter:
 1. Disable the named exporter. If the same name as an existing exporter is not used, then this will create a completely new exporter that is completely ignored. This value can be set dynamically by using cluster settings.
 
 
-::::{note} 
+::::{note}
 Defining a disabled exporter prevents the default exporter from being created.
 ::::
 

docset.yml

@@ -174,7 +174,6 @@ subs:
   webhook-cm:   "Webhook - Case Management"
   opsgenie:   "Opsgenie"
   hive:   "TheHive"
-  monitoring:   "X-Pack monitoring"
   monitor-features:   "monitoring features"
   stack-monitor-features:   "Elastic Stack monitoring features"
   watcher:   "Watcher"

solutions/observability/apm/apm-server/use-internal-collection-to-send-monitoring-data.md

@@ -80,7 +80,7 @@ You specify these settings in the X-Pack monitoring section of the `apm-server.y
 
 ### `monitoring.enabled` [_monitoring_enabled]
 
-The `monitoring.enabled` config is a boolean setting to enable or disable {{monitoring}}. If set to `true`, monitoring is enabled.
+The `monitoring.enabled` config is a boolean setting to enable or disable X-Pack monitoring. If set to `true`, monitoring is enabled.
 
 The default value is `false`.