我有一个使用 PostgreSQL 9.3 的主服务器和热备用服务器设置，并且我正尝试使用该工具和“hot_standby_delay”操作来监视备用服务器上的复制状态check_postgres。这似乎可以通过计算主服务器和备用服务器上的 xlog 位置之间的字节差来实现。
在许多在线示例中，我看到了 < 1MB 范围内的警告和严重阈值。我们在 Nagios 中使用的确切命令是：
/usr/local/bin/check_postgres.pl --action=hot_standby_delay --host=$HOSTNOTES$,$HOSTADDRESS$ --port=5432 --dbname=monitoring --dbuser=monitoring --dbpass=monitoring --warning=1000000 --critical=5000000
这应该在 1MB 左右设置警告，在 5MB 左右设置中断。但是，在我们的服务器上，我们经常看到它飙升到很高的水平，如下所示：
[1417719713] SERVICE ALERT: host;PostgreSQL: Replication Delay;CRITICAL;SOFT;1;POSTGRES_HOT_STANDBY_DELAY CRITICAL: DB "monitoring" (host:host.example.com) 121175880
[1417719773] SERVICE ALERT: host;PostgreSQL: Replication Delay;CRITICAL;SOFT;2;POSTGRES_HOT_STANDBY_DELAY CRITICAL: DB "monitoring" (host:host.example.com) 132780968
[1417719833] SERVICE ALERT: host;PostgreSQL: Replication Delay;CRITICAL;SOFT;3;POSTGRES_HOT_STANDBY_DELAY CRITICAL: DB "monitoring" (host:host.example.com) 21412936
后续 Nagios 检查如下：
[1417719893] SERVICE ALERT: host;PostgreSQL: Replication Delay;OK;SOFT;4;POSTGRES_HOT_STANDBY_DELAY OK: DB "monitoring" (host:host.example.com) 0
因此从一般意义上讲，复制似乎有效（事实上，在主服务器上执行数据更新会立即在备用服务器上看到结果）。
不幸的是，这种情况使得监控变得毫无用处，因为它每天都会触发多次误报。从我在文档和其他使用示例中发现的情况来看，这种结果并不典型，大多数人能够设置 1MB 或更低的阈值，并且只有在确实存在错误时才会看到错误。
有人知道我可以尝试配置来解决这个问题吗？在这个特定的安装中，我们只更改了几个参数，其中只有一些参数wal_keep_segments看起来与此关系不大（我们将其设置为 128）。
主服务器和备用服务器都托管在同一个可用区域的 EC2 中，它们之间似乎没有任何通信延迟。这也是一个流量非常低的数据库，所以我不确定 xlog 增量一开始怎么会相差这么远，除非我遗漏了一些非常关键的事实。
答案1
返回 SOFT CRITICAL 的检查不会触发通知，因为它尚未达到阈max_check_attempts值。这不是误报；这是 Nagios 按照设计运行的结果。这很正常（对于许多服务而言，不仅限于您的情况）。这正是 max_check_attempts 存在的原因。
就您而言，它在初始非正常检查结果出现后 3 分钟内恢复正常。对于某些服务，这种不同步时间是可以接受的，但对于您的用例来说可能不行。我对 Postgres 复制了解不够多，无法明确地说这是否表明存在潜在问题。