Address Gaby's comments

mpfuster · mpfuster · commit 90fef580dcb1 · 2026-03-03T13:33:13.000Z
diff --git a/advocacy_docs/supported-open-source/warehousepg/wem/get-started.mdx b/advocacy_docs/supported-open-source/warehousepg/wem/get-started.mdx
@@ -99,11 +99,11 @@ Once you have installed WEM, you can fine-tune how WEM connects to your cluster
     1. Save to apply changes immediately.
 
 !!! Note
-    Some low-level system parameters are only accessible via the configuration file.
+    Some system parameters are only accessible via the configuration file.
 
 2. **Method 2: Edit the configuration file manually**
 
-    For low-level system parameters not exposed in the WEM console, or for automated deployments, edit the WEM configuration file directly on the host server:
+    For system parameters not exposed in the WEM console, or for automated deployments, edit the WEM configuration file directly on the host server:
     1. Stop the service: `systemctl stop wem` on the WEM host.
     1. Edit the file `/etc/wem/wem.conf` and modify the desired parameter.
     1. Restart the service: `systemctl start wem`.
diff --git a/advocacy_docs/supported-open-source/warehousepg/wem/installing/collector.mdx b/advocacy_docs/supported-open-source/warehousepg/wem/installing/collector.mdx
@@ -57,8 +57,8 @@ Once the Collector packages are installed, edit the file `/var/lib/whpg-observab
     WHPG_OBS_DSN="host=whpg-coordinator-host port=5432 dbname=postgres user=gpadmin password=postgres sslmode=disable"
     ```
 
-!!! Note
-    You can specify any database on your WHPG cluster. However, the user must hold the superuser role.
+    !!! Note
+        You can specify any database on your WHPG cluster. However, the user must hold the superuser role.
 
 - `LOKI_ENDPOINT`: Point to your configured Loki endpoint for log files. For example:
 
diff --git a/advocacy_docs/supported-open-source/warehousepg/wem/installing/index.mdx b/advocacy_docs/supported-open-source/warehousepg/wem/installing/index.mdx
@@ -10,7 +10,7 @@ navigation:
 
 
 !!! Note
-This guide assumes you have installed Prometheus and Loki. 
+This guide assumes you have installed Prometheus and Loki.  You can deploy dedicated instances for WEM or integrate with your existing enterprise monitoring stack. 
 !!!
 
 The installation process consists of the following steps:
diff --git a/advocacy_docs/supported-open-source/warehousepg/wem/installing/prerequisites.mdx b/advocacy_docs/supported-open-source/warehousepg/wem/installing/prerequisites.mdx
@@ -5,16 +5,16 @@ description: Understand the prerequisites before installing the WarehousePG Obse
 ---
 
 !!! Note
-This guide assumes you have installed Prometheus and Loki. 
+This guide assumes you have installed Prometheus and Loki. You can deploy dedicated instances for WEM or integrate with your existing enterprise monitoring stack.
 !!!
 
 ## Prerequisites
 
 - WarehousePG (WHPG) version 6.x running on RHEL 7 or RHEL 8.
 - WHPG version 7.x running on RHEL 8 or RHEL 9.
 - A separate host for WarehousePG Enterprise Manager (WEM), running RHEL 8 or RHEL 9.
-- [Loki](https://grafana.com/docs/loki/latest/setup/install/) 3.5 or later.
-- [Prometheus](https://prometheus.io/docs/prometheus/latest/installation/) 3.5.0 or later.
+- [Loki](https://grafana.com/docs/loki/latest/setup/install/) 3.5 or later.  You can deploy a dedicate instance for WEM or integrate with your existing enterprise monitoring stack.
+- [Prometheus](https://prometheus.io/docs/prometheus/latest/installation/) 3.5.0 or later. You can deploy a dedicate instance for WEM or integrate with your existing enterprise monitoring stack.
 - A database user that holds the superuser role and is able to connect to your WHPG cluster from the WEM host.
 - Optional: An active Anthropic account and a valid API key are required to enable the AI Assistant for query writing and optimization.
 - Optional: An active installation of [Prometheus Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/) version 0.28.1 or later is required to enable centralized alert handling and notifications within WEM.
diff --git a/advocacy_docs/supported-open-source/warehousepg/wem/installing/wem.mdx b/advocacy_docs/supported-open-source/warehousepg/wem/installing/wem.mdx
@@ -55,7 +55,7 @@ Edit the configuration file `/etc/wem/wem.conf` and configure the following para
 
 1. Optionally, configure advanced settings to fine-tune logging and data transmission:
 
-    - `WEM_EXPORTER_LOG_LEVEL`: Sets the verbosity of the Exporter logs ((`debug`, `info`, `warn`, or `error`)) to assist with troubleshooting.
+    - `WEM_EXPORTER_LOG_LEVEL`: Sets the verbosity of the Exporter logs (`debug`, `info`, `warn`, or `error`) to assist with troubleshooting.
 
     - `WEM_EXPORTER_REMOTE_WRITE_INTERVAL`: Defines how frequently (e.g., 15s, 1m, 5m) the Exporter pushes collected metrics to the remote storage.
 
@@ -125,18 +125,18 @@ After starting the service, use these diagnostic tools to ensure all WEM compone
 
 - Run `wem setup` to test WEM configuration settings:
 
-```bash
-wem setup --verify
-```
-See [wem setup command reference](../reference/commands#wem-setup) for details.
+    ```bash
+    wem setup --verify
+    ```
+    See [wem setup command reference](../reference/commands#wem-setup) for details.
 
 - Perform a comprehensive "doctor" check to identify potential configuration errors, missing dependencies, or connectivity issues:
 
-```bash
-wem doctor
-```
+    ```bash
+    wem doctor
+    ```
 
-See [wem doctor command reference](../reference/commands#wem-doctor) for details.
+    See [wem doctor command reference](../reference/commands#wem-doctor) for details.
 
 
 !!! Note Post-installation changes: 
diff --git a/advocacy_docs/supported-open-source/warehousepg/wem/monitoring/index.mdx b/advocacy_docs/supported-open-source/warehousepg/wem/monitoring/index.mdx
@@ -16,7 +16,7 @@ Verify cluster health, maintain operational awareness and respond to system even
 
 - [Visualizing hardware performance:](system-metrics) Use the **System Metrics** panel to tracking the physical health of your infrastructure. Use these charts to identify OS-level bottlenecks, such as CPU spikes, memory exhaustion, or network latency across specific hosts.
 
-- [Validating database responsiveness:](monitoring) Ensure the database engine is actively processing requests. Use the **Monitoring** panel to review automated canary checks—synthetic SQL probes that verify connectivity and execution speed.
+- [Validating database responsiveness:](monitoring) Ensure the database engine is actively processing requests. Use the **Monitoring** panel to review automated Canary checks—synthetic SQL probes that verify connectivity and execution speed.
 
 - [Auditing system logs:](logs) The **Logs** panel allows you to investigate the unified stream of system and database telemetry. Search through coordinator and segment logs to pinpoint the root cause of query failures or administrative changes.
 
diff --git a/advocacy_docs/supported-open-source/warehousepg/wem/monitoring/monitoring.mdx b/advocacy_docs/supported-open-source/warehousepg/wem/monitoring/monitoring.mdx
@@ -5,9 +5,9 @@ description: Use the Monitor panel to track proactive health indicators and auto
 deepToC: true
 ---
 
-The **Monitoring** panel on the left sidebar provides proactive verification of cluster health through automated canary checks. Unlike passive metrics, these checks execute active tasks to ensure the database engine is responding correctly and meeting performance baselines.
+The **Monitoring** panel on the left sidebar provides proactive verification of cluster health through automated Canary checks. Unlike passive metrics, these checks execute active tasks to ensure the database engine is responding correctly and meeting performance baselines.
 
-### Performing proactive health checks: canary checks
+### Performing proactive health checks: Canary checks
 
 Canary checks are recurring, automated scripts that simulate real-world operations to verify the end-to-end integrity of the system. You can configure these tests on the [User Management panel](../system-access/user-management).
 
