前言
最近还真碰到了一桩奇怪的案例。不久前有一个上线了一段时间的GCP下的PostgreSQL环境，因为使用的用户相对较少，只配了最大50G的存储空间。通常来说，Google作为底层提供商，它对存储空间的计算应该是相对比较合理的。我也一直认为是这样。
结果……. 发现Cloud下边真的是很离谱，各种规则能让你甚至改变三观。
实作与分析
短短几天时间，存储量从很少的一两个G，猛涨到顶50个G。
要是再看看上边的结果提示，你能气到吐血：Data只有180M，归档日志占了剩下的48.17个GB.
在之前的监控与计算规则里，我们从来没有考虑过归档日志的空间占用情况。而且Google提供的可监控指标，也没有正式提供出来。到目前为止还是：Beta阶段。
详细情况见： https://cloud.google.com/sql/docs/postgres/admin-api/metrics
这个功能居然还是BETA阶段。也无法正式纳入Dynatrace的监控指标当中。
将archive WAL log置入存储计价空间里头，估计GCP是首先这么干的。至少AWS和Azure不是这么干的。
也许GCP意识到了什么，后来又可以支持默认将archive log归档到它的Object Store的bucket里头，那样价格一下子就下下来了。但是已经是旧模式的数据库实例，只能先扩容，然后备份，然后再切换新的存储方式。
对那些已经有了一些用户规模的GCP PostgreSQL实例，可就不能这么干了。只能自己造一个监控加上。
如何监控实际存储空间：
以前是：
SELECT pg_size_pretty(pg_database_size(current_database()));
只需要查询当前数据库的实际占用大小就可以了。在GCP上不灵了。改变：
select (archived_count * 16384*1024::bigint) + pg_database_size(current_database()) as DATA_AND_WAL_SIZE from pg_stat_archiver;
select pg_size_pretty((archived_count * 16384*1024::bigint) + pg_database_size(current_database())) as PRETTY_DATA_AND_WAL_SIZE from pg_stat_archiver;复制现当前要把WAL log的归档部分全部加上去。只能手动加上这种指标放到自定义的监控面板上。
下边是在本地另外一个环境当中的测试结果：
select pg_size_pretty((archived_count * 16384*1024::bigint) + pg_database_size(current_database())) as PRETTY_DATA_AND_WAL_SIZE from pg_stat_archiver;
pretty_data_and_wal_size|
------------------------+
18 GB |
select (archived_count * 16384*1024::bigint) + pg_database_size(current_database()) as DATA_AND_WAL_SIZE from pg_stat_archiver;
data_and_wal_size|
-----------------+
19777233775|复制幸亏给了pg_stat_archiver的查询权限。
对于这类监控，下边的几个SQL语句是很有用的，可惜只有pg_stat_archiver是可以查的，其它都要superuser权限。
postgres=# select pg_stat_reset();
pg_stat_reset
---------------
(1 row)
postgres=# select * from pg_stat_archiver \gx
-[ RECORD 1 ]------+------------------------------
archived_count | 7
last_archived_wal | 00000001000000000000000A
last_archived_time | 2023-07-28 22:01:17.965556+00
failed_count | 0
last_failed_wal |
last_failed_time |
stats_reset | 2023-07-26 11:38:53.571776+00
postgres=# select * from pg_ls_waldir()\gx
-[ RECORD 1 ]+-------------------------
name | 00000001000000000000000F
size | 16777216
modification | 2023-08-01 11:13:13+00
-[ RECORD 2 ]+-------------------------
name | 000000010000000000000010
size | 16777216
modification | 2023-08-01 11:13:59+00
-[ RECORD 3 ]+-------------------------
name | 00000001000000000000000E
size | 16777216
modification | 2023-08-01 11:19:04+00
postgres=# select * from pg_ls_archive_statusdir()\gx
(0 rows)
postgres=# SELECT pg_stat_reset_shared('archiver');
pg_stat_reset_shared
----------------------
(1 row)复制
小结
在Cloud环境下，很多种不自由。经常要考虑到各种资源限制。因而对资源的监控显得非常重要。因为牵扯到资源 ，必须又涉及到各种计价规则。有的确实很离谱，用完感觉是被宰的节奏。早点发现问题，采取合理的方案去使用资源，这样才能在尽量低成本的情况下提供同等质量的服务。
所谓货比三家，真的有点鄙视GCP了。幸亏它现在改过来了，默认新创建的数据库实例可以选择使用Bucket来存储归档日志。
