apply suggestions from @lcawl

Co-authored-by: Lisa Cawley <[email protected]>

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 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:
+The `local` exporter is the default exporter in {{monitor-features}}. 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 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.
+* Any usage of {{monitor-features}} 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-monitoring-collectors.md

@@ -14,7 +14,7 @@ products:
 :::{include} _snippets/legacy-warning.md
 :::
 
-Collectors, as their name implies, collect things. Each collector runs once for each collection interval to obtain data from the public APIs in {{es}} and X-Pack that it chooses to monitor. When the data collection is finished, the data is handed in bulk to the [exporters](es-monitoring-exporters.md) to be sent to the monitoring clusters. Regardless of the number of exporters, each collector only runs once per collection interval.
+Collectors, as their name implies, collect things. Each collector runs once for each collection interval to obtain data from the public APIs in {{es}} that it chooses to monitor. When the data collection is finished, the data is handed in bulk to the [exporters](es-monitoring-exporters.md) to be sent to the monitoring clusters. Regardless of the number of exporters, each collector only runs once per collection interval.
 
 There is only one collector per data type gathered. In other words, for any monitoring document that is created, it comes from a single collector rather than being merged from multiple collectors. The {{es}} {{monitor-features}} currently have a few collectors because the goal is to minimize overlap between them for optimal performance.
 

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

@@ -14,7 +14,7 @@ products:
 :::{include} _snippets/legacy-warning.md
 :::
 
-To stop generating X-Pack monitoring data in {{es}}, disable data collection:
+To stop generating monitoring data in {{es}}, disable data collection:
 
 ```yaml
 xpack.monitoring.collection.enabled: false

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 X-Pack monitoring. If set to `true`, monitoring is enabled.
+The `monitoring.enabled` config is a boolean setting to enable or disable {{monitor-features}}. If set to `true`, monitoring is enabled.
 
 The default value is `false`.