Google Cloud在2026年9月11日宣布，AlloyDB for PostgreSQL可以通过Cloud Monitoring观察审计日志管道。管理员现在不仅能在Cloud Logging中查询pgAudit记录，还能判断日志从数据库节点转发到日志平台的过程是否出现积压。
新能力监控的是异步审计日志处理管道，不是数据库查询吞吐量。它解决的是日志已产生但处理或上传变慢时缺少可见性的问题。
AlloyDB审计日志采用异步转发
AlloyDB先在实例中生成用户审计记录，再异步处理并安全转发到Cloud Logging。异步设计减少了日志传输对前台请求的直接阻塞，但也意味着高峰期可能出现等待处理的数据。
Cloud Logging里暂时没有看到最新记录，不一定代表审计没有开启。还需要结合新指标确认管道是否存在持续积压，避免把转发延迟误判成审计策略失效。
三项新指标分别反映什么
audit/backlog_bytes_count是GAUGE类型，显示节点上等待处理并上传的积压字节数。audit/processed_bytes_count和audit/processed_entries_count为DELTA类型，分别记录成功处理并转发的字节数与条目数。
持续升高的积压值代表管道存在回压。单次尖峰之后快速回落更可能是短暂流量波动，应结合已处理字节和条目变化判断处理能力是否跟得上日志生成速度。
指标位于实例节点资源层级
这三项指标挂载在alloydb.googleapis.com/InstanceNode监控资源上。多节点集群需要分别观察节点，不能只查看集群总览，否则局部节点的异常可能被总体趋势掩盖。
告警应围绕持续时间和增长趋势设置，而不是只用一个固定瞬时阈值。不同业务的审计范围、SQL量和参数记录设置都会改变正常日志规模。
查看pgAudit内容仍需日志权限
pgAudit记录会作为Data Access审计日志进入Cloud Logging。查看这些日志前，项目需要启用Data Access审计日志，操作人员还要拥有Private Logs Viewer角色。
监控指标可见并不代表操作者有权读取审计正文。权限配置仍应遵循最小授权，避免为了排查管道状态而给普通监控账户开放敏感SQL审计内容。
运维告警可以从积压趋势开始
实际配置中，可以把积压字节持续增长作为主要告警信号，同时用已处理字节和条目判断管道是否完全停滞。恢复后还应确认积压回落，并检查Cloud Logging中的时间连续性。
验收标准不是指标重新出现，而是积压稳定下降且新审计条目持续到达。涉及政府、金融或ISO合规场景时，还应把告警响应与日志留存策略一并纳入审计流程。
