Add PMM HA Cluster messaging for GA launch (#197)

offerings/expertops/messaging.md

@@ -7,7 +7,7 @@ ExpertOps is Percona's proactive operations offering. Percona engineers provide
 Percona engineers perform operational work directly in your environment: monitoring, tuning, patching, automation, backup validation, and routine maintenance, using PMM for observability and Operators plus engine-appropriate tooling for execution. Unlike [Expert Support](../expert-support/messaging.md), ExpertOps is proactive and hands-on: Percona executes operational work rather than advising your team to execute it.
 
 - **Who ExpertOps is for:** Teams with limited staff or time to manage databases, companies that need 24×7 operational coverage, organizations that want to prevent incidents instead of reacting to them, environments where uptime is business-critical.
-- **Problems ExpertOps solves:** Operational noise and alert fatigue, manual or inconsistent scaling, maintenance and tuning, downtime from preventable issues, operational backlog, staffing limitations, and "day two" risk after migrations or upgrades (inconsistent backups, policy drift, weak monitoring).
+- **Problems ExpertOps solves:** Operational noise and alert fatigue, manual or inconsistent scaling, maintenance and tuning, downtime from preventable issues, operational backlog, staffing limitations, observability loss when the monitoring platform goes down during database incidents, and "day two" risk after migrations or upgrades (inconsistent backups, policy drift, weak monitoring).
 - **Outcomes ExpertOps delivers:** Proactive issue prevention, stable and predictable performance, reduced operational burden on engineering teams, faster incident response from engineers already familiar with the environment, and lower infrastructure waste through rightsizing and standardized operations.
 
 ## Operating model
@@ -22,7 +22,7 @@ ExpertOps is flexible: Percona can own monitoring, tuning, patching, backup vali
 | --- | --- | --- |
 | Underlying infrastructure | Rightsizing guidance, capacity reviews, failover and DR automation support | Cloud account ownership, cluster provisioning policy, network design |
 | Database platform | Operator or instance configuration, patching, backup jobs, HA behavior | Major architecture decisions, vendor selection |
-| Monitoring and alerting | PMM deployment, alert tuning, 24×7 alert response | Business priority definitions for alert thresholds |
+| Monitoring and alerting | PMM deployment and HA operations, alert tuning, 24×7 alert response | Business priority definitions for alert thresholds |
 | Tuning and performance | Query review, index and configuration tuning, proactive capacity checks | Application query design, schema ownership |
 | Access and security | Secure remote access, patch and security advisory response | Identity policy, application credentials |
 | Application | Incident coordination when database symptoms affect apps | Application code, feature releases |
@@ -35,6 +35,7 @@ Exact boundaries are agreed at onboarding and recorded in the subscription.
 - **Post-migration day-two operations:** Consistent backup behavior, policy alignment, and monitoring after cutover (for example, migration to Percona Operator for MongoDB on Kubernetes).
 - **Staffing gaps:** 24/7 operational coverage without full-time hires.
 - **Operator fleet operations:** Hands-on monitoring, backup validation, tuning, patching, and upgrade execution for MySQL, PostgreSQL, and MongoDB clusters on Percona Operators when customers want Percona to run Day-2 work instead of advising on it.
+- **Resilient observability:** PMM HA Cluster deployment, health validation, and 24×7 monitoring operations for teams that need dashboards and alerts to stay up through PMM Server maintenance and failures.
 - **Operator migration and cutover (scoped):** Percona-led moves to operator-managed clusters from VMs, managed services, or legacy StatefulSets, plus post-cutover stabilization, when migration and operational hours are defined in the agreement.
 - **DBaaS exit or hybrid operations:** Operational partnership after moving from managed database services to customer-controlled infrastructure while retaining expert coverage.
 

products/pmm/messaging.md

@@ -8,7 +8,7 @@ The data observability market is projected to grow from USD 3.15B in 2025 to USD
 
 PMM provides observability for backup operations and backup health indicators, while backup execution and policy management remain in dedicated Percona backup tooling.
 
-PMM pairs metrics and Query Analytics with Percona Advisors: bundled Security, Configuration, Performance, and Query checks that run inventory-scoped on a schedule or on demand, so one deployment surfaces live health, historical query insight, and automated risk signals for the engines you monitor. This fit is strongest for mixed estates across MySQL, PostgreSQL, MongoDB, Valkey, and Redis-compatible services running on-premises, in cloud, in Kubernetes, and in OpenShift, especially where teams require local telemetry control and role-based access boundaries.
+PMM pairs metrics and Query Analytics with Percona Advisors: bundled Security, Configuration, Performance, and Query checks that run inventory-scoped on a schedule or on demand, so one deployment surfaces live health, historical query insight, and automated risk signals for the engines you monitor. This fit is strongest for mixed estates across MySQL, PostgreSQL, MongoDB, Valkey, and Redis-compatible services running on-premises, in cloud, in Kubernetes, and in OpenShift. It is strongest of all where teams require local telemetry control, role-based access boundaries, and continuous observability through infrastructure failures and maintenance.
 
 ### Customer Challenges and Value Alignment: PMM
 
@@ -19,12 +19,14 @@ PMM pairs metrics and Query Analytics with Percona Advisors: bundled Security, C
 - Query-level and engine analytics: Teams can diagnose root causes faster by using the correct PMM surface for each engine. PMM's QAN component exposes query execution plans and latency for MySQL, PostgreSQL, and MongoDB, while Valkey and Redis observability is delivered through dedicated PMM dashboards and exporter metrics. QAN covers completed workload history for optimization review. PMM also provides Real-time Query Analytics (RTA) for MongoDB-compatible environments monitored by PMM, with a live 1-5 second stream for active incidents, including long-running queries and lock contention. RTA currently supports MongoDB-compatible environments only, not MySQL or PostgreSQL.
 - Cloud architecture transitions: [Lookout](https://www.percona.com/customer-story/lookout-uses-percona-cloud-expertise-to-reduce-footprint-and-maintain-uptime/) used PMM on AWS Aurora to examine queries, map metrics, and spot bottlenecks while Percona ExpertOps helped simplify a 35 primary/replica pair topology to 10 instances without compromising responsive mobile security applications.
 - Percona Advisors and reliability: Beyond metrics and QAN, advisor checks flag misconfigurations, degradation, and query-level problems like data loss and corruption early. Runs use configurable intervals or manual execution for engines in inventory, adding rules-based review alongside dashboards and analytics.
-- Engine-native replication metrics: PMM leverages each engine's native capabilities for replication monitoring. For PostgreSQL, PMM reads `pg_stat_wal_receiver` data via custom queries in `postgres_exporter` (namespace: `pg_custom_stat_wal_receiver`, columns include `lag_bytes`), providing accurate replication lag measurement without requiring external heartbeat tools. This is a concrete advantage for MySQL-to-PostgreSQL migration stories: PostgreSQL's built-in replication instrumentation replaces the need for tools like pt-heartbeat. *(Source: `postgres_exporter/queries-hr.yml#L32`; validated Feb 2026.)*
-- HA visibility for incident response: PMM surfaces replication and node health signals that help teams validate high availability behavior and shorten failover diagnosis, especially where incidents involve multi-team handoffs between application, platform, and database owners.
+- High availability for the PMM platform: PMM keeps dashboards, alerts, Query Analytics, and advisors reachable through PMM Server failures and maintenance windows. PMM HA Cluster runs three PMM Server replicas with automated leader election and load-balanced failover routing. Teams monitoring production MySQL, PostgreSQL, MongoDB, Valkey, and Redis estates keep observability when the monitoring layer itself fails, not only when a database node fails. Installation is Helm-based on Kubernetes, with operator-managed storage for metrics, query analytics, and Grafana metadata.
+- Monitoring continuity matched to the availability standard: Docker HA and Kubernetes single-instance HA are production-ready where a short failover gap is acceptable; both restore access within minutes. PMM HA Cluster serves environments that cannot lose dashboards or alerts during a PMM Server transition, delivering immediate failover instead. HA health signals in Inventory and the HA Health Overview dashboard let operators confirm cluster status across all three deployment options.
+- Engine-native replication metrics: PMM uses each engine's native capabilities for replication monitoring. For PostgreSQL, PMM reads `pg_stat_wal_receiver` data via custom queries in `postgres_exporter` (namespace: `pg_custom_stat_wal_receiver`, columns include `lag_bytes`), providing accurate replication lag measurement without requiring external heartbeat tools. This is a concrete advantage for MySQL-to-PostgreSQL migration stories: PostgreSQL's built-in replication instrumentation replaces the need for tools like pt-heartbeat. *(Source: `postgres_exporter/queries-hr.yml#L32`; validated Feb 2026.)*
+- Database HA visibility for incident response: PMM surfaces replication and node health signals that help teams validate database high availability behavior and shorten failover diagnosis, especially where incidents involve multi-team handoffs between application, platform, and database owners.
 - MongoDB storage fragmentation visibility: For MongoDB environments monitored by PMM, MongoDB Cluster Summary and MongoDB ReplSet Summary dashboards surface fragmentation analysis that relates free space to allocated storage per collection, so teams can spot wasted capacity and prioritize compaction or growth planning before latency spikes ([fragmentation analysis](https://docs.percona.com/percona-monitoring-and-management/3/release-notes/3.7.1.html#spot-mongodb-storage-fragmentation-at-a-glance)).
 
 **Security, Sovereignty, and Compliance**
-- Granular access and auditability: Role-based access control (RBAC) and integration with standard authentication systems ensure that visibility is properly segmented and traceable, supporting secure deployment at scale and simplifying audit preparation.
+- Granular access and auditability: Role-based access control (RBAC) and integration with standard authentication systems keep visibility segmented and traceable, which supports secure deployment at scale and simplifies audit preparation.
 - Security-category advisors and local findings: Security advisors highlight common database security risks. Advisor check results stay on PMM Server for review and are not sent as part of telemetry ([PMM Advisor documentation](https://docs.percona.com/percona-monitoring-and-management/3/advisors/advisors.html)).
 - Safer diagnostic sharing: PMM masks database passwords and connection-string credentials in diagnostic logs and encrypts [PMM Dump](https://docs.percona.com/percona-monitoring-and-management/3/release-notes/3.8.0.html#encrypted-pmm-data-dumps) exports by default with AES-256-CTR, so teams can share logs or datasets with vendors or internal escalation paths with lower risk of leaking secrets or raw monitoring data.
 - Data sovereignty and transparency: PMM is fully open source and self-hostable in air-gapped or private environments. All components are open for inspection, ensuring alignment with sovereignty requirements and eliminating dependency on opaque SaaS monitoring platforms.
@@ -37,13 +39,15 @@ PMM pairs metrics and Query Analytics with Percona Advisors: bundled Security, C
 
 ### Sales enablement
 
-- **Qualification framework:** Use this module to frame opportunities by estate mix (MySQL, PostgreSQL, MongoDB, Valkey, Redis-compatible), topology (on-premises, cloud, Kubernetes, OpenShift, hybrid, multi-cloud), and dominant pain pattern (query regressions, replication uncertainty, cache memory pressure, or incident handoff delays).
+- **Qualification framework:** Use this module to frame opportunities by estate mix (MySQL, PostgreSQL, MongoDB, Valkey, Redis-compatible), topology (on-premises, cloud, Kubernetes, OpenShift, hybrid, multi-cloud), dominant pain pattern (query regressions, replication uncertainty, cache memory pressure, incident handoff delays, or monitoring downtime), and PMM platform availability requirements (single instance, Docker HA, Kubernetes single-instance HA, or HA Cluster).
 - **Discovery questions:**
   - Where do database incidents lose the most time today: detection, root-cause analysis, or handoff across teams?
   - Which engines and environments are in scope for one monitoring surface today (MySQL, PostgreSQL, MongoDB, Valkey, Redis-compatible, Kubernetes, cloud, on-premises)?
   - How are slow-query regressions, replication lag, and cache memory pressure currently detected and escalated?
   - What telemetry control, access boundaries, or auditability requirements must observability satisfy?
   - Are licensing or vendor lock-in constraints driving a move toward self-hosted, open source observability?
-- **Fit indicators:** PMM fit is strongest when teams need a self-hosted observability surface with local telemetry control, role-based access boundaries, and one operational view across mixed engines.
+  - Can observability tolerate a short outage during PMM Server maintenance and failover, or must dashboards and alerts stay reachable throughout?
+  - How is PMM deployed today (single instance, Docker HA, Kubernetes, OpenShift), and who owns monitoring resilience when the platform itself fails?
+- **Fit indicators:** PMM fit is strongest when teams need a self-hosted observability surface with local telemetry control, role-based access boundaries, and one operational view across mixed engines. PMM HA Cluster fit is strongest when the monitoring platform carries its own uptime requirement: procurement or architecture reviews set an availability bar for it, or teams want built-in PMM resilience instead of a custom monitoring failover stack.
 - **Supported technologies:** PMM covers database observability for MySQL, PostgreSQL, MongoDB, Valkey, and Redis-compatible deployments, backup observability for PBM surfaces, and a Grafana plus VictoriaMetrics (Prometheus-compatible) observability stack.