前言

在SAP BTP的云平台下边，有大量的hyperscaler PG的实例需要监控，按不同的region，又分别有不同的provider，主要分AWS, Azure, GCP，国内有Ali Cloud。而PG的磁盘使用量这一块儿的监控，就显得很重要了。

从PG9.6开始，直到现在的PG12， PG14， 也都稳定运行好几年了。或许后来的功能不断增强，比如添加了Multi-AZ高可用、不停服小版本自动升级等，有时候磁盘容量的监控就会出幺蛾子。

现象及应对

最近，在hyperscaler PG对应的Azure和AWS实例里头，就出现数据库的磁盘使用量告警，说使用量已经连续一个小时超过了85%，甚至接近100%。但是后来又慢慢降下来了，降到23%～25%左右的水平。

于是我们联合DBOps找到了所有的监控指标，捋了一下，发现业务程序以及pg_database_size()这一块，并没有使用多大的量。而pg_wal以及archive wal log部分已经基本不计入磁盘使用量，他们一般都把它放到更便宜的文件系统或者oss里头（追求低成本高利润，可以理解）。

这样的话，PG的相关服务团队是不会也不应背这锅的，直接给AWS和Azure发了邮件。质问质疑，为何DB本身以及业务那块儿并没有大动作，磁盘容量却不断报警。

Azure先得到回复，先承认不是因为有大量的WAL log,  也不是有大量的事务读写引起磁盘使用暴涨。他们查了下那个时间段的相关底层日志，发现那个时间段是他们自动运维，做replication备份时有大量的文件需要复制，临时文件导致的空间暴涨。并提供了一个内部自定义参数，让hyperscaler帮助添加到对应的实例当中，以后出现类似情况，通过启用那个参数，就可以从activity当中查到具做干了哪些事情。

这种答复，无疑让人有些不爽。客户花钱买的磁盘空间不是给他们这么用的。复制的时候，完全可以使用别的磁盘空间，而不是直接拿本来就不宽裕的数据库容量空间滥用。凭什么直接占用用户自己申请的空间。何况平时就是拿这个指标做是否要“扩容”的判断标准。原来就是超过85%多长时间，就要启动半自动扩容流程，扩容还可能引起一小段时间的数据库停服。影响非常不好。

为了避免此类“误报”， 临时只能调控监控指标，在已有的storage_utilization超标的情况下，使用database_size作为第二步指标，判断是否数据库本身空间使用有异常，如果没有异常，应该是他们底层的别的运维操作导致的。

事情仍在沟通中， 并给他们提出要求和正式的需求。给人感觉就是云厂商不太愿意使用另外的磁盘空间去做这些事，反而去侵占用户的磁盘空间。给运维和监控造成不必要的困扰。

回想起前段时间，一样在GCP对应的实例中，他们居然把事情做绝到pg_wal和archive wal的空间也都算在了Database使用空间上，于是你原来花钱买的那些空间很快就耗光了。直接触发扩容。那件事让人大为脑火。后来是解决方案是，他们把那两个位置全部移到外部的桶存储里头去了。

这样看来，云厂商为了片面追求利润，有些事情做的确实不太光彩。利用两边信息的不太对称，做出一些违背良心的事。

这件事情，Hyperscaler这边还在跟他们进行沟通，希望能找到一个令双方都满意的结果。

这种现象也给了云环境下数据库的管理与监控人员一些警示，不能简单的根据一些指标做简单的维护动作，具体的情况还是需要具体分析，找出背后的原因和逻辑。