第2章成本数据可视化

第2章成本数据可视化：云厂商账单解析与多维度仪表盘搭建

说实话，做运维成本治理这件事，最怕的是什么？不是云资源太贵，而是你根本不知道钱花在了哪里。我见过太多团队，月底收到账单就是一笔糊涂账——「咦，这个月怎么多花了五万？」然后大家互相甩锅，谁也说不清楚。

所以这一章，咱们就来解决这个根本问题。把云厂商那堆乱七八糟的账单数据，变成你能看懂、能分析、能决策的可视化仪表盘。

2.1 云厂商账单解析：CUR与BR

先说说账单数据源。AWS的叫CUR（Cost and Usage Report），Azure的叫BR（Billing Report）。名字不同，但本质一样——都是云厂商提供的原始计费数据。

CUR（AWS）：一份CSV格式的详细账单，每小时一条记录。包含实例ID、产品类型、用量、单价、总价、标签等信息。我建议你每天拉一次，存到S3里。

BR（Azure）：Azure的账单导出功能，支持按天或按小时粒度。格式也是CSV，字段和CUR大同小异。

嗯，这里有个坑。我曾经帮一家公司做成本分析，发现他们的CUR数据里有些行的单价是0。一开始以为是免费资源，后来一查才发现是预留实例的摊销成本。所以解析的时候，一定要区分「一次性费用」和「摊销费用」。

避坑指南： 我曾经遇到过一个案例，某团队直接拿CUR的「总价」字段做聚合，结果预留实例的费用被重复计算了两次。正确的做法是：用「有效成本」字段，而不是「总价」。

2.2 成本标签体系设计

账单数据解析完了，接下来就是打标签。没有标签的账单，就像没有目录的书——你根本找不到想要的信息。

我个人的习惯是，标签体系分三层：

业务层：项目名、应用名、环境（prod/staging/dev）
资源层：实例规格、区域、可用区
财务层：成本中心、预算编号、负责人

举个例子，一个EC2实例的标签可能是这样：

Project: ecommerce
Application: user-service
Environment: prod
InstanceType: c5.xlarge
Region: ap-southeast-1
CostCenter: CC-2024-001
Owner: zhang@company.com

你想想看，有了这些标签，你就能回答很多问题了：

「电商项目这个月花了多少钱？」→ 按Project=ecommerce聚合
「生产环境比测试环境多花了多少？」→ 按Environment聚合
「哪个负责人超预算了？」→ 按Owner聚合

小技巧： 我建议在创建资源的时候就强制打标签，而不是事后补。事后补标签，总有漏网之鱼。可以用AWS Config或Azure Policy做强制校验，没标签的资源直接告警。

2.3 多维度成本仪表盘搭建

数据有了，标签也有了，接下来就是搭仪表盘。我个人比较喜欢用Grafana，因为它支持多数据源，而且图表类型丰富。

先画一张核心的架构图，帮你理解整个数据流：

这张图就是整个成本可视化系统的核心逻辑。说白了，就是「采集 → 清洗 → 存储 → 展示」四个步骤。

接下来，我分享几个常用的仪表盘面板：

2.3.1 总成本趋势图

这个面板用时间序列图，展示每天/每周的总成本变化。我习惯用柱状图展示每日成本，折线图展示7天移动平均。这样既能看出波动，又能看到趋势。

2.3.2 按服务分类的饼图

EC2花了多少？RDS花了多少？S3花了多少？用饼图一目了然。不过要注意，如果服务太多，饼图会变得很乱。我一般只展示Top 10，剩下的归为「其他」。

2.3.3 按标签聚合的表格

这个最实用。比如按Project聚合，列出每个项目的当月成本、环比增长率、预算使用率。我还会加一个「异常标记」——如果某个项目的成本环比增长超过20%，就标红。

  核心指标：
  当月总成本（MTD）
环比增长率（MoM）
预算使用率（Budget Utilization）
Top 5 高成本资源
未打标签资源占比

2.4 实战：用Grafana搭建成本仪表盘

好了，理论说完了，咱们来点实际的。假设你已经把CUR数据导入了PostgreSQL，接下来用Grafana搭一个简单的仪表盘。

第一步，添加数据源：

类型: PostgreSQL
主机: your-db-host
数据库: cost_analysis
表: cur_data

第二步，写SQL查询。比如总成本趋势：

SELECT
  DATE_TRUNC('day', usage_date) AS day,
  SUM(effective_cost) AS total_cost
FROM cur_data
WHERE usage_date >= NOW() - INTERVAL '30 days'
GROUP BY day
ORDER BY day;

第三步，配置图表。选「时间序列」类型，X轴用day，Y轴用total_cost。嗯，这里有个小细节——我习惯把Y轴的单位设为「美元」，并且保留两位小数。

第四步，加一个变量。比如加一个「Project」变量，这样就能通过下拉菜单切换不同项目的成本视图。

变量名: project
查询: SELECT DISTINCT project FROM cur_data WHERE project IS NOT NULL

然后在你所有的SQL里加上 WHERE project = '$project'，就实现了动态过滤。

避坑指南： 我曾经遇到一个性能问题——CUR数据量太大，每次查询都要扫全表。后来我给usage_date和project加了索引，查询速度从30秒降到了2秒。所以，别忘了加索引！

2.5 成本仪表盘的进阶玩法

基础的仪表盘搭好了，咱们再聊点进阶的。

成本预测：用过去3个月的数据，做一个简单的线性回归预测。Grafana有内置的预测函数，或者你也可以在SQL里用 REGR_SLOPE 函数。这样你就能提前知道下个月大概要花多少钱。

异常检测：设置一个阈值，比如「单日成本超过过去7天平均值的1.5倍」就告警。我习惯用Grafana的Alert功能，配合钉钉或Slack通知。

成本分摊：如果多个团队共享同一个资源（比如一个RDS实例），可以用标签做成本分摊。比如按读写比例、按连接数比例。这个比较复杂，但做出来之后，财务核算就清晰多了。

好了，这一章的内容就到这里。成本可视化这件事，说白了就是「先看清，再管好」。没有数据，一切都是空谈。下一章咱们聊聊如何通过资源优化来降本，那才是真正动手的时候。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录