用Prometheus监控PostgreSQL error_log表新增行：方案B的可行性验证

你的判断是对的——方案B确实比方案A更可靠，而且完全符合Prometheus基于时间序列采样的核心设计理念。

为什么方案B适配Prometheus？ #

Prometheus的核心是收集可被持续采样的时间序列指标，方案B通过采集error_log表的总记录数（或自增主键的最大值），本质是生成一个单调递增的计数器类指标，这正是Prometheus最擅长处理的指标类型。

具体实现的关键要点 #

1. 指标暴露方式
   可以通过postgres_exporter配置自定义SQL查询，暴露记录数指标：

   SELECT COUNT(*) AS error_log_total FROM error_log;
   

   如果你的表有定期清理旧日志的操作（比如归档删除），用自增主键的最大值更稳妥：

   SELECT COALESCE(MAX(id), 0) AS error_log_max_id FROM error_log;
   

2. 告警规则配置
   不要直接对比两次采样的记录数，而是用Prometheus的increase()函数计算指定时间窗口内的增量：

   increase(error_log_total[1m]) > 0
   

   这个表达式会计算过去1分钟内记录数的增长量，只要大于0就说明有新行产生。配置告警规则时，可以设置连续2次采样（即60秒内）都检测到增量，避免误报。

方案B解决方案A的核心问题 #

• 无遗漏风险：即使Prometheus中断，恢复后采集到的是当前最新的记录数，increase()函数会自动计算中断期间的总增量，不会漏掉这段时间产生的新日志。
• 无重复告警：只有当记录数确实产生新的增量时，increase()才会返回大于0的值，不会像方案A那样因为采样窗口重叠重复触发通知。

注意事项 #

如果你的error_log表存在删除旧数据的操作，不要用COUNT(*)作为指标，因为记录数可能会下降，导致increase()无法正确计算增量。这种情况下，用自增主键的MAX(id)是更可靠的选择——只要有新行插入，MAX(id)就会单调递增，不受旧数据删除影响。

内容的提问来源于stack exchange，提问作者dafie