misc changes

Author: mpfuster

advocacy_docs/supported-open-source/warehousepg/wem/get-started.mdx

@@ -16,14 +16,36 @@ To start using the interface:
 
 For security, sessions automatically expire after a period of inactivity; if a timeout occurs, the system will display a "Session Expired" message and redirect you to the login screen. You can also manually terminate your session at any time by clicking the Logout icon located in the sidebar footer.
 
+## Configuring WEM settings post-installation
+
+Once you have installed WEM, you may need to fine-tune how WEM connects to your cluster or external services (like Prometheus and Alertmanager). There are two primary ways to manage these configurations:
+
+1. Using the WEM settings tab
+
+Administrators can modify most operational parameters directly through the browser:
+
+    1. Navigate to **User Management** > **Settings**.
+    1. Update fields such as **Prometheus URL** or **Backup History Database Path**.
+
+!!! Note
+    While convenient, some low-level system parameters are only accessible via the configuration file.
+
+2. Manual configuration file editing
+
+For parameters not exposed in the WEM console or for automated deployments, you can edit the configuration file directly on the host server:
+
+    1. Stop the service: `systemctl stop wem`.
+    1. Edit the file `/etc/wem/wem.conf` on your WEM cluster and modify the desired parameter.
+    1. Restart the service: `systemctl start wem` to apply the changes.
+
+
 ## Navigating the interface structure
 
 The WEM interface is organized into three functional areas:
 1. **Sidebar (left)**: The primary navigation menu.
 2. **Header (top)**: Displays the current page title, system time, and global controls such as filters and refresh triggers.
 3. **Main content (center)**: The primary workspace where data tables, charts, and configuration tools are rendered.
 
-
 ## Understanding user roles and permissions
 
 WEM utilizes Role-Based Access Control (RBAC). The panels available in the console are determined by the role assigned to your user account.

advocacy_docs/supported-open-source/warehousepg/wem/installing/wem.mdx

@@ -19,23 +19,10 @@ Install the WarehousePG Enterprise Manager (WEM) package on your designated host
 
 1. Install WEM on your designated host:
 
-    <TabContainer syncKey="install">
-    <Tab title="RHEL 8, 9">
-
     ```bash 
     sudo dnf install -y whpg-enterprise-manager
     ```
 
-    </Tab>
-    <Tab title="RHEL 7">
-
-    ```bash 
-    sudo yum install -y whpg-enterprise-manager
-    ```
-
-    </Tab>
-    </TabContainer>
-
 ## Configuring WEM
 
 Edit the configuration file `/etc/wem/wem.conf` and configure the following parameters:

advocacy_docs/supported-open-source/warehousepg/wem/monitoring/alerts.mdx

@@ -1,11 +1,14 @@
 ---
 title: Managing alerts
 navTitle: Managing alerts
-description: Use the Alerts panel to monitor system health through real-time notifications and manage the incident lifecycle.
+description: Use the Alerts panel to integrate with Prometheus Alertmanager and govern the incident lifecycle through real-time notifications.
 deepToC: true
 ---
 
-The **Alerts** panel serves as the central nervous system for your cluster, aggregating health signals from canary checks, segment events, and resource breaches. Use these actions to identify and resolve system degradation before it impacts your users.
+The **Alerts** panel serves as the central nervous system for your cluster, aggregating health signals from across your infrastructure. This panel integrates directly with Prometheus Alertmanager to provide a unified interface for incident response and rule management.
+
+!!! Warning "Alertmanager required"
+    If the **Alerts** panel displays `Alertmanager Not Configured`, you must set the `ALERTMANAGER_URL` in your system environment. See [Configuring WEM](../installing/wem#configuring-wem) and [Configuring WEM settings post-installation](../get-started#configuring-wem-settings-post-installation) for details.
 
 ### Identifying alert sources
 
@@ -14,6 +17,7 @@ Alerts are automatically generated from several monitoring vectors:
 - **Segment down events:** Triggered if a segment becomes unreachable or enters a recovery state.
 - **Resource threshold breaches:** Fired when CPU, Memory, or Disk Usage cross predefined limits.
 - **System errors:** Critical database engine events captured from the WHPG log stream.
+- **WEM outages**: If Prometheus is unable to reach the WEM service, it triggers an alert.
 
 ### Understanding severity levels
 
@@ -23,27 +27,10 @@ WEM displays severity levels to help you prioritize your operational workflow:
 - **Info:** Routine informational notices regarding system changes or successful task completions.
 
 
-### Overseeing active notifications
-
-Use the **Active Alerts** view to identify and respond to current system issues that require immediate attention.
-- **Prioritize by severity:** Review the impact level of all active notifications. Focus on critical alerts first, followed by warning alerts to prevent escalation into service outages.
-- **Investigate alert details:** Select any active alert to review its summary and message. Use this data to identify exactly which component—such as a specific segment or a resource threshold—is currently failing.
-- **Acknowledge system events:** If you have **Admin** or **Operator** privileges, click the **Ack** button on an active alert. This signals to the rest of the team that the issue is being investigated, preventing duplicate effort and maintaining a clear timeline for the incident lifecycle.
-
-### Analyzing incident history
-
-Use the **Alert History View** to perform retrospective analysis and identify recurring patterns across your infrastructure.
-- **Audit past incidents:** Review the history of resolved alerts to identify intermittent service instability or consistent resource pressure. Use the summary info cards to see the distribution of critical vs. informational events over time.
-- **Filter by time and severity:*** Narrow your audit trail to specific windows, such as the last 24 hours or the last 7 days. Apply severity filters to isolate specific tiers, such as reviewing all critical events from the past month to identify stability trends.
-
-### Configuring alert logic and rules
-
-Use the **Settings** tab to manage the detection logic that triggers system notifications.
-
-!!! Important
-    Access to this tab is restricted to users with the **Admin** or **Operator** role privilege.
-
-- **Manage alert rules:** Review the configuration dashboard to track active rules by name, type, and severity. You can enable or disable specific rules without deleting them to tune your monitoring during maintenance windows.
-- **Create custom detection logic:** Use the create rule button to define new monitoring parameters. Choose the type of alert, which includes Threshold (numerical values), Pattern (status codes like "down"), or Anomaly (statistical outliers).
-- **Define technical conditions:** Specify the target metric (such as disk_usage or query_duration) and input the technical logic in the condition (json) field. This allows you to tailor alerts to the specific performance characteristics of your hardware.
-
+### Managing the incident lifecycle
+Use the specialized tabs to move through the stages of alert detection, suppression, and resolution.
+- **Respond to current threats:** Use the **Active Alerts** tab to identify and prioritize immediate issues. Filter by severity to address critical failures first, ensuring that total service outages are resolved before investigating warning or info events.
+- **Suppress noise during maintenance:** Use the **Silences** tab to temporarily mute specific alerts. This is essential during scheduled maintenance or segment recovery windows to prevent alert fatigue and ensure that your notification channels remain focused on unexpected issues.
+- **Audit dispatch history:** Review the **Notifications** tab to see exactly when and where alerts were sent (e.g., Slack, Email, or PagerDuty). Use this to verify that the correct stakeholders were notified during an incident.
+- **Evaluate detection logic:** Browse the **Alert Rules** tab to inspect the active triggers defined in your Prometheus configuration. This view allows you to verify the technical conditions (thresholds, durations, and labels) that govern how WEM identifies system degradation.
+- **Perform retrospective analysis:** Use the **Alert History** tab to identify recurring patterns. By auditing resolved alerts, you can isolate intermittent hardware failures or recurring resource pressure that may require long-term capacity planning.

advocacy_docs/supported-open-source/warehousepg/wem/monitoring/cluster-overview.mdx

@@ -1,11 +1,11 @@
 ---
 title: Verifying the cluster health
 navTitle: Verifying the cluster health
-description: Use the Cluster Overview panel to monitor real-time WarehousePG cluster health, verify node availability, and track critical connectivity metrics to ensure high availability
+description: Use the Cluster panel to monitor real-time WarehousePG cluster health, verify node availability, and track critical connectivity metrics to ensure high availability
 deepToC: true
 ---
 
-The **Cluster Overview** panel provides a high-level summary of the WarehousePG (WHPG) cluster configuration and real-time health metrics. This panel is the primary starting point for verifying cluster availability and resource utilization.
+The **Cluster** panel provides a high-level summary of the WarehousePG (WHPG) cluster configuration and real-time health metrics. This panel is the primary starting point for verifying cluster availability and resource utilization.
 
 ### Confirming core cluster availability
 

advocacy_docs/supported-open-source/warehousepg/wem/monitoring/index.mdx

@@ -12,14 +12,13 @@ navigation:
 
 Verify cluster health, maintain operational awareness and respond to system events in real time through the following core actions:
 
-- [Verifying the cluster health:](cluster-overview) Maintain a real-time view of the cluster’s topology and health via the **Cluster Overview** panel. Use this to ensure that coordinator, standby, and segment nodes are online and correctly configured.
+- [Verifying the cluster health:](cluster-overview) Maintain a real-time view of the cluster’s topology and health via the **Cluster** panel. Use this to ensure that coordinator, standby, and segment nodes are online and correctly configured.
 
 - [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.
 
 - [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.
 
-- [Managing alerts:](alerts) Use the **Alerts** panel to oversee the the notification lifecycle. Define thresholds for critical metrics and manage the queue of active alerts to ensure proactive intervention.
-
+- [Managing alerts:](alerts)  Use the **Alerts** panel to integrate with Prometheus Alertmanager and govern the incident lifecycle through real-time notifications.
 

advocacy_docs/supported-open-source/warehousepg/wem/monitoring/logs.mdx

@@ -10,13 +10,13 @@ The **Logs** panel serves as a centralized diagnostic hub. By consolidating inte
 ### Understanding log levels
 
 WarehousePG Enterprise Manager (WEM) displays severity levels generated directly by the underlying WarehousePG (WHPG) engine. These levels categorize every log entry based on its impact on database operations:
-- DEBUG: Contains granular technical details used primarily for deep-dive troubleshooting and development analysis.
-- INFO: Provides standard informational messages regarding routine system operations.
-- LOG: Reports standard engine-level events and process completions.
-- WARNING: Highlights events that are not fatal but may indicate potential configuration issues or approaching resource limits.
-- PANIC: Indicates a critical error that caused all database sessions to be disconnected; the system will usually attempt a restart after a PANIC.
-- FATAL: Indicates an error that caused a specific session to be terminated, though the rest of the database remains operational.
-- ERROR: Reports a problem that prevented a specific command or query from completing successfully.
+- `DEBUG`: Contains granular technical details used primarily for deep-dive troubleshooting and development analysis.
+- `INFO`: Provides standard informational messages regarding routine system operations.
+- `LOG`: Reports standard engine-level events and process completions.
+- `WARNING`: Highlights events that are not fatal but may indicate potential configuration issues or approaching resource limits.
+- `ERROR`: Reports a problem that prevented a specific command or query from completing successfully.
+- `FATAL`: Indicates an error that caused a specific session to be terminated, though the rest of the database remains operational.
+- `PANIC`: Indicates a critical error that caused all database sessions to be disconnected; the system will usually attempt a restart after a `PANIC`.
 
 ### Performing structured database analysis
 

advocacy_docs/supported-open-source/warehousepg/wem/monitoring/monitoring.mdx

@@ -1,40 +1,20 @@
 ---
 title: Validating database responsiveness
 navTitle: Validating database responsiveness
-description: Use the Monitor panel to rack proactive health indicators and automated canary check results to ensure database availability.
+description: Use the Monitor panel to track proactive health indicators and automated canary check results to ensure database availability.
 deepToC: true
 ---
 
 The **Monitoring** panel 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
 
-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 test on the [Users panel](../security/user-management).
+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](../security/user-management).
 
 Use the **Canary Checks** tab to verify that the database can successfully execute core operations.
-- **Run health checks on demand:** Trigger an immediate execution of any check in the list to verify a fix or test real-time connectivity. While you must go to the [Users panel](../security/user-management) to create or edit a check, the monitoring panel allows you to run and stop them at any time to get an instant status update.
-- **Measure query execution speed:** Observe the duration column during a run. If the millisecond count is rising even while the status remains "Success," you are seeing early signs of resource saturation before it impacts users.
-- **Respond to status changes:** Follow the required action protocol for non-passing checks. A "Warning" status is a signal to begin capacity planning, while a "Critical" status requires an immediate audit of system logs.
+- **Assess overall probe health:** Review the header metrics to get an instant snapshot of system integrity. Compare the **Successful** count against the **Total Checks** count to identify if a specific subset of your monitoring is failing.
+- **Verify scheduler activity:** Check the status of the scheduler to ensure it is running. This confirms that the WarehousePG Enterprise Manager (WEM) engine is actively triggering your background probes. If the scheduler is stopped, your health data will become stale and you will lose proactive visibility.
+- **Run health checks on demand:** Trigger an immediate execution of any check in the list to verify a fix or test real-time connectivity. While you must go to the [User Management panel](../security/user-management) to create or edit a check, the **Monitoring** panel allows you to run and stop them at any time to get an instant status update.
+- **Benchmark execution speed:** Monitor the **Average Duration** metric to establish a baseline for expected responsiveness. A sudden spike in this metric, even if checks are still successful, serves as an early warning of resource saturation or network latency.
+- **Investigate specific check failures:** Audit the **Health Checks** table to isolate the root cause of a failure. By checking which specific probe is non-passing, you can determine if the issue is a total service outage or a localized subsystem failure.
 
-
-### Analyzing query concurrency and scheduling
-
-Use the **Smart Analysis** tab to understand how high-volume traffic impacts the internal database scheduler and locking mechanisms.
-
-- **Identify resource queue bottlenecks:** Monitor the **Queued** query count. If this number is high, your resource queues are likely too restrictive or your cluster lacks the CPU/Memory to handle the current concurrent load.
-- **Investigate lock contention:** Check the **Lock Waits** indicator. A high count suggests that long-running transactions are holding onto resources and blocking other users, which is a common cause of application performance degradation.
-- **Correlate connections with performance:** Use the **Connections Over Time** graph to see if spikes in new sessions lead to a rise in average query time. This helps you determine your cluster's true breaking point for concurrent users.
-
-### Managing the alert lifecycle
-
-Use the **Alerts** tab to track threshold violations and coordinate a response to system incidents.
-- **Acknowledge active incidents:** Use the **Ack** button to signal that an investigation is underway. This prevents duplicate efforts and helps maintain an accurate timeline for incident resolution.
-- **Prioritize by severity:** Sort the alert log by impact level to focus on critical infrastructure failures before addressing informational messages or performance warnings.
-
-
-## Tracking historical performance drift
-
-Use the **Trends** tab to move beyond real-time status and analyze the long-term stability of the cluster.
-- **Detecting intermittent service instability:** Review the history of check results to identify services that fail and recover automatically. Repeated triggers for the same service often point to underlying resource exhaustion or network instability rather than a total hardware failure.
-- **Identifying performance degradation:** Monitor if check durations are gradually increasing over weeks or months. This "drift" helps you visualize how data growth and increased user load are slowly impacting your baseline performance.
-- **Isolating recurring warning windows:** Review the frequency of warnings to see if the system consistently underperforms during specific times, such as during daily backup windows or heavy ETL (Extract, Transform, Load) cycles.

advocacy_docs/supported-open-source/warehousepg/wem/monitoring/system-metrics.mdx

@@ -11,7 +11,7 @@ The **System Metrics** panel provides a comprehensive view of the hardware and d
 
 Use the **System Metrics** tab to identify immediate hardware saturation that could be impacting query response times.
 
-- **Spot processing bottlenecks:** Check the **CPU Usage % over time** to see if specific nodes are hitting 100% utilization. If one node is consistently higher than others, you may have data skew issues.
+- **Spot processing bottlenecks:** Check the **CPU Usage % Over Time** to see if specific nodes are hitting 100% utilization. If one node is consistently higher than others, you may have data skew issues.
 - **Assess memory pressure:** Monitor **Available Memory** vs. **Cached Memory**. If the available memory is low and cached is also shrinking, the OS is under pressure and may start swapping, which significantly slows down database operations.
 - **Validate storage and network throughput:** Review **Disk I/O** and **Network Traffic** graphs. High disk read rates during unexpected times might indicate inefficient queries that are forcing full table scans instead of using indexes.
 - **Evaluate system load averages:** Observe the 1m, 5m, and 15m load averages. If the 15-minute load consistently exceeds the number of available CPU cores, the host is over-provisioned and tasks are queuing at the OS level.