云厂商涨价，我的多云监控工具链遭遇两坑？

哎，Zui近一波云厂商的调价，真是把我这颗老码农的心给掏空了。

说实话，我本来还挺自信，手里Yi经撸好一套自研的多云成本监控工具链。

结果呢，两大坑接连跳出来差点把我逼到键盘上砸键盘。

今天就跟你们唠嗑唠嗑，kankan这两坑到底怎么整的。

先说 AWS 那边吧。

我在脚本里写了一个“实时告警”，想要每天上午 9 点把昨天的费用推送到企业微信。

可是啊，Cost Explorer 的 API 那玩意儿，有个约 24 小时的数据延迟。

刚开始我还以为是代码写错了调试了好几遍。

不对不对，应该是官方文档里藏得hen深的一句话：

# 注意：Cost Explorer 有约 24 小时延迟，当天数据不准确

所以当你请求今天的费用时返回的几乎dou是 $0.

害，这直接导致告警失灵。

我的临时解决方案是：

from datetime import datetime, timedelta
def get_aws_daily_cost:
    """获取 AWS 每日成本，注意数据延迟"""
    ce = boto3.client
    if not start_date:
        # 用昨天整天的数据Zuo“今日”估算
        start_date =  - timedelta).strftime
    if not end_date:
        end_date = datetime.utcnow.strftime
    response = ce.get_cost_and_usage(
        TimePeriod={"Start": start_date, "End": end_date},
        Granularity="DAILY",
        Metrics=,
        GroupBy=,
    )
    result = {}
    for period in response:
        date = period
        result = {
            group: float
            for group in period
        }
    return result

哈哈，这段代码基本上Neng把“昨天费用”搬运过来用作今天的预估。

再配合 CloudWatch 的实时计费告警，基本上就Neng覆盖掉那块盲区了。

说完 AWS，我们再聊聊阿里云。

我用的是 BSS OpenAPI 的 QueryInstanceBill 接口来抓取月度账单明细。

这个接口返回的是分页数据，但只给了一个 TotalCount，没有直接告诉你总页数。

于是我在循环分页的时候，经常会出现：

# 第三页Yi经拉完，但 TotalCount 却在变化
# 导致后面的第四页根本不存在

这下子，我的聚合脚本在中途抛异常，日志里全是 “IndexError”。

解决办法其实也不难：

import math
def get_aliyun_monthly_bill:
    client = AcsClient
    page_size = 50
    # 首次请求拿到 TotalCount
    request = QueryInstanceBillRequest
    request.set_BillingCycle
    request.set_PageSize
    request.set_PageNum
    response = client.do_action_with_exception
    data = json.loads
    total_count = int
    total_pages = math.ceil
    all_items = 
    for page in range:
        req = QueryInstanceBillRequest
        req.set_BillingCycle
        req.set_PageSize
        req.set_PageNum
        resp = client.do_action_with_exception
        d = json.loads
        items = d
        all_items.extend
    return 

算出总页数后就Ke以稳稳地把所有账单拉下来不会再出现 “分页错位” 的尴尬。

好了把 AWS 和阿里云的数据dou抓下来后我就把它们统一到一个报告对象里再推送到企业微信。

下面是一段简化版的聚合代码：

import httpx
from dataclasses import dataclass
@dataclass
class DailyCostReport:
    date: str
    aws_usd: float
    aliyun_cny: float
    @property
    def total_cny -> float:
        # 粗略汇率，仅示例；实际请调用实时汇率接口
        USD_TO_CNY = 7.1
        return self.aws_usd * USD_TO_CNY + self.aliyun_cny
    def check_alert -> bool:
        return self.total_cny> threshold_cny
def send_wecom_alert:
    """发送企业微信告警"""
    msg = (
        f"⚠️ 云成本告警
"
        f"日期：{report.date}
"
        f"AWS：${report.aws_usd:.2f}
"
        f"阿里云：¥{report.aliyun_cny:.2f}
"
        f"合计：¥{report.total_cny:.2f}"
    )
    httpx.post

咱就是说这套流程现在每天早上自动跑一次：

AWS 拉昨天费用

阿里云全量分页拉取

统一换算成 CNY 并判断阈值

触发企业微信告警

AWS 那块Zui容易忽视——hen多人直接用 “当天数据” Zuo报表，结果发现报表一直偏低。

我之前也被这玩意儿坑得哭笑不得。

COST EXPLORER 延迟约 24 小时： 每日任务Zui好以 “昨日完整一天” 为单位抓取。

CW 实时计费 Alarm： 适合监控突发大额消费，但只Nengkan月累计，不适合作日结报表。

#小技巧： Ke以用 CloudWatch Metric “EstimatedCharges” 再配合自定义阈值，实现geng细粒度报警。

TotalCount 不等于 TotalPages： 一定要先拿一次 TotalCount，然后根据 PageSize 手动算出总页数。

AWS 多区域/多账户合并： 每个账号/区域dou要分别跑一次再统一聚合，否则会有遗漏。

#小技巧： 将每次请求的响应时间戳记录下来Ru果同一天内 TotalCount 突然增大，要重新计算分页范围。

① 初期只关注大头——CPU、存储、网络流量； ② 随着业务增长，再加入 AI/ML 专项实例； ③ Zui后加上辅助服务的细粒度计费。

#温馨提示#：

🔹 阿里云账单采集前，请确保Yi在 RAM 控制台为对应账号授予 AlicloudBSSReadOnlyAccess 权限。 🔹 AWS 调用 Cost Explorer API 时每次请求dou会产生微小费用，请务必控制调用频率。

COST TOOLCHAIN 跑起来以后你会发现原本每月几千块的钱，现在Neng精准定位到哪个项目、哪个实例在消耗Zui多资源——这才是真正价值所在呀！哈哈~