新钛云服已累计为您分享890篇技术干货
背 景
某外企刚使用阿里云作为国内的基础设施，最近几个月费用出现了大幅增加，急需对费用按应用、环境以及多个账号的费用排名进行月度报表的发送，用于清晰的看到费用的分布情况。
基于如上的背景情况，我们构建了一个自动化的阿里云费用报告系统为客户定期的发送费用报告，免去人为的报告制作和发送。
系统整体架构
核心组件
一套完整的阿里云费用报告系统应包含以下核心组件：
-
配置管理：负责加载和管理系统配置，支持环境变量、.env文件等多种配置方式
-
数据收集：从阿里云API收集费用数据，包括月度费用、账号费用、应用费用等
-
数据分析：分析收集到的数据，生成统计信息和趋势分析
-
报告生成：生成HTML、Excel报告和可视化图表
-
邮件发送：将报告通过邮件发送给相关人员
系统架构图
系统架构图说明：该架构展示了阿里云费用报告系统的核心组件和数据流向，从配置管理到数据收集、分析、报告生成，最终通过邮件发送给相关人员。
工作流程详解
1.系统初始化
系统启动后，首先进行初始化操作：
-
加载配置信息
-
初始化各组件（数据收集器、分析器、报告生成器、邮件发送器）
-
测试阿里云API连接
**系统初始化过程说明：**初始化各个组件，主要是为了保障配置的正常加载和 API 调用的正常。确保能正常的获取到阿里云的费用数据。
2.数据收集
数据收集模块从阿里云API获取以下数据：
-
过去12个月的月度费用数据
-
所有账号的费用数据
-
按应用类型（如Demo、Test、Dev）分类的费用数据
-
按标签分类的费用数据
**数据收集过程说明：**以上数据收集模块仅供参考，实际情况需按照各个公司实际想要的费用维度去收集。例如：按应用组、应用、环境、Owner等不同维度去获取日或月的费用
3.数据分析
数据分析模块对收集到的数据进行多维度分析：
-
TOP账号分析：识别费用最高的账号
-
月度趋势分析：分析费用的月度变化趋势
-
环境费用分析：分析不同环境（如dev、prod）的费用分布
-
账号统计分析：统计账号数量、平均费用等指标
-
Untagged资源分析：识别未标记的资源，帮助企业完善资源管理
**数据分析结果说明：**数据分析实际是按照你收集到的数据根据要展现的报告进行分析，因为收集的数据包含的信息很多需要通过进一步分析才能变成我们需要的数据。如下是一些展示的demo
TOP5账号费用
|----|-----------------|------------|-------|
| 排名 | 账号名称 | 费用 | 占比 |
| 1 | demo-prod-01 | ¥32,500.75 | 26.5% |
| 2 | test-prod-01 | ¥27,800.50 | 22.6% |
| 3 | dev-prod-01 | ¥18,200.25 | 14.8% |
| 4 | demo-staging-01 | ¥13,500.00 | 10.9% |
| 5 | test-staging-01 | ¥9,800.75 | 8.0% |
月度费用趋势
|---------|-------------|-------|
| 月份 | 费用 | 同比增长 |
| 2024-01 | ¥105,800.25 | - |
| 2024-02 | ¥110,250.75 | +4.2% |
| 2024-03 | ¥115,680.50 | +4.9% |
| 2024-04 | ¥113,800.25 | -1.7% |
| 2024-05 | ¥120,350.75 | +5.8% |
环境费用分布
|---------|------------|-------|
| 环境 | 费用 | 占比 |
| prod | ¥82,600.75 | 68.7% |
| staging | ¥20,850.50 | 17.3% |
| dev | ¥13,200.25 | 11.0% |
| test | ¥3,700.25 | 3.1% |
4.报告生成
报告生成模块生成多种格式的报告：
-
HTML报告：包含详细的费用分析和图表
-
Excel报告：便于进一步人工数据处理和分析
-
可视化图表：直观展示费用分布和趋势
**报告生成流程说明：**报告生成模块根据分析结果生成多种格式的报告，包括HTML报告、Excel报告和可视化图表，满足不同场景的需求，在我们的真实场景需要根据用户要求来进行调整，这里的用户是指想看这些报告的人，建议在做之前先和用户沟通好，他们想看什么样的报告。
5.邮件发送
邮件发送模块将生成的报告通过邮件发送给相关人员：
-
支持HTML邮件内容
-
支持内嵌图表
-
支持附件（如Excel报告）
**邮件发送流程说明：**邮件发送只是一种常见的报告渠道，用户也可以通过大屏形式去展现。
配置与部署
配置文件
系统通过环境变量或.env文件进行配置，主要配置项包括：
-
阿里云API凭证（AccessKey ID、AccessKey Secret）
-
主账号ID和子账号列表
-
报告配置（输出目录、启用的报告类型）
-
邮件配置（SMTP服务器、发件人、收件人）
配置总结：建议把敏感的配置信息放在.env文件里，如果有条件的可以把配置放到Vault或KMS凭据里去调用。进一步保障敏感配置不泄露
部署方式
系统可以通过以下方式部署：
-
**本地部署：**在本地服务器上运行，定期执行
-
**容器化部署：**使用Docker容器化，便于管理和扩展
-
**云函数部署：**使用阿里云函数计算，实现无服务器运行
部署总结：这种次数少的报告，推荐使用阿里云函数计算服务来部署，无须准备资源，按次计费，对费用成本是极大的节省。
自动化实现方案
定时执行
要实现报告的自动化生成和发送，可以采用以下方式：
**1.Cron定时任务：**在Linux服务器上设置cron任务，定期执行报告生成脚本
apache
# 每月5日凌晨1点执行0 1 5 * * cd /path/to/project && python main.py**2.阿里云函数计算：**使用事件触发，设置定时触发器
-
创建函数计算服务
-
配置定时触发器（如每月5日执行）
-
将代码部署到函数计算
**3.容器编排：**使用Kubernetes CronJob
-
创建CronJob配置
-
设置执行时间和镜像
-
配置环境变量
监控与告警
为确保自动化流程的可靠性，应实现监控和告警机制，主要监控当报告生成失败时发送告警邮件，其次监控费用异常进行告警，比如总费用比上个月突增 50%或费用为 0 需要发送告警，最后还要监控下阿里云的API，万一没有权限了或 API 地址废弃了需要告警来进行及时的调整。
自动化可靠性保障
1.错误处理：
-
实现完善的异常捕获和处理
-
提供错误恢复机制
-
记录详细的错误信息
2.重试机制：
- 对API调用实现自动重试
**自动化监控说明：**监控与告警模块确保自动化流程的可靠性，包括执行状态监控、告警机制和日志管理，及时发现和处理系统异常。
扩展与复用
扩展场景
该系统架构不仅适用于费用报告，还可以扩展到以下场景：
-
**资源使用报告：**分析阿里云资源的使用情况，如ECS实例、RDS数据库 CPU和内存平均使用率低于设定的阈值进行报告发送
-
**安全合规报告：**检查阿里云资源的安全配置和合规性，不过这个阿里云应该是有产品能实现的。如果企业想节省成本自己做一些规则来实现也是可以的
-
**成本优化报告：**分析费用构成，提供成本优化建议，例如某些数据库都没有访问，可以发送报告，然后人工确认后释放
复用策略
为了避免重复造轮子，可采用以下复用策略：
-
**模块化设计：**将系统分解为独立的模块，便于复用和扩展
-
**配置驱动：**通过配置文件控制系统行为，避免硬编码
-
**工具类复用：**提取通用功能为工具类，如日期处理、文件操作、日志管理等
注意事项
在构建和使用阿里云费用报告系统时，需要注意以下事项：
1.数据准确性
-
确保阿里云API凭证具有足够的权限
-
处理API分页和重试机制，确保数据完整收集
-
验证数据的一致性和完整性
2.性能优化
-
合理设置API调用频率，避免触发阿里云API限流
-
优化数据存储和处理，减少内存使用
-
考虑使用缓存机制，避免重复计算
3.安全性
-
保护API凭证和配置信息，避免泄露
-
加密存储敏感数据
-
定期轮转API凭证
4.可维护性
-
完善日志记录，便于排查问题
-
编写详细的文档，便于后续维护
-
实现监控和告警机制，及时发现问题
5.费用分析特殊情况处理
1.Untagged资源分析：
-
需要将月度费用明细中包含tag的数据拉出来进行分析
-
有些费用是不按实例来的单独为一项（如流量费），因此untagged资源是必然存在的
-
分析时需要区分真正的未标记资源和本身不需要标记的费用项
2.年付费账单处理：
-
有些账号的资源是年付费的，会出现月度费用为0的情况，需要在数据分析时特别处理这种情况，避免影响整体统计
-
建议费用统一为月付费或按量计费，便于结算
3.账单与环境对应关系
-
有些账号是单账号多环境的，有些是一个账号一个环境的，需要在系统设计时考虑这种差异，确保环境费用分析的准确性
-
可以通过标签或账号命名规范来区分不同环境
4.阿里云关账时间：
- 阿里云一般在每个月4号关账，建议在5号运行报表，确保数据完整准确
5.费用查询方法：
- 建议使用DescribeInstanceBill方法查询费用数据，QueryInstanceBill方法不再提供50000行以后数据的查询
6.测试模式：
- 工具需要添加一个测试模式，发送到测试邮箱，在正式发送前一天先手动测试，确保数据准确性
最佳实践建议
1.账号规划建议
-
**应用不多的情况：**建议采用单应用单环境一个账号的方式，这样方便按应用或环境计算费用，无须打tag
-
**应用较多的情况：**建议先按Landingzone做好账号规划，一个领域或一个应用组一个账号
-
**命名规范：**建立统一的账号命名规范，包含应用、环境等信息，便于识别和管理
2.共享资源费用拆分
-
**K8S资源：**可以按照pod的request mem进行拆分，相对合理
-
**数据库资源：**可以按照实例维度进行拆分
-
**存储资源：**可以按照存储容量维度进行拆分
-
**网络资源：**可以按照流量使用量维度进行拆分
3.便签管理建议
-
**统一标签规范：**制定统一的标签键值规范，确保标签的一致性
-
**必打标签：**应用组、应用、环境、负责人等关键信息应作为必打标签
-
**标签自动化：**结合IAC和CI/CD流程，实现标签的自动添加和管理
-
**持续监控：**新建资源如发现没有标签，就发送告警
结 语
自动化是现代IT运维的核心趋势，一套自动化的阿里云费用报告系统不仅可以帮助企业及时了解云费用情况，还可以为成本优化提供数据支持，同时减少人工干预，提高工作效率。
通过本文介绍的架构和流程，企业可以构建适合自己的费用报告系统，并将其扩展到其他阿里云管理场景，实现云资源的有效管理和优化。自动化的实现不仅体现在报告的自动生成和发送，还包括监控、告警和错误处理等方面，确保系统的可靠性和稳定性。
在实施过程中，企业应根据自身需求和技术栈选择合适的部署方式和自动化方案，同时注重系统的可扩展性和可维护性，避免重复造轮子，提高开发效率。
真实报告展示
以下是实际报告的展示效果，包含费用概览和详细分析两个部分：
费用概览报告
TOP 3 报告
**报告展示说明：**这些图片展示了实际报告的效果，包括费用概览和详细分析两个部分，帮助相关人员直观了解云费用情况。
如有相关问题，请在文章后面给小编留言，小编安排作者第一时间和您联系，为您答疑解惑。
推荐阅读
