基于Amazon CloudFront Extensions开发的CDN监控API

1.背景

在业务全球化的大背景下，全球 CDN加速是必不可少的一项服务，亚马逊云科技的CDN服务-CloudFront，也是众多客户的选择对象。CloudFront可以以低延迟和高传输速度向全球用户安全地分发静态内容和API，缩短等待时间，提高用户体验。由于国内客户对于CDN的使用习惯和要求与海外客户有较大差异，所以在一些方面还是需要做一些定制化的方案来适配国内用户的需求。

在我们实际接触的客户中，客户针对CDN的监控API还是有一定的需求特点的：

客户要求监控的实时性，同时又要求数据准确性，往往要求监控API既能提供低延迟的指标查询用于监控和及时发现问题，又能依照依照标准日志的统计分析数据来用于成本对账和一些其他的数据校正。
需要以客户的业务域名作为host去查询指标，但是CloudFront的本身接口以都是以Distribution ID来查询，因此需要定制专门的接口参数。
客户实际业务需求中有几百个域名，因此也要求接口可以支持多域名并发请求查询。

亚马逊云科技在Amazon CloudFront Extensions中推出了开箱即用的监控解决方案，支持基于实时日志和标准日志的监控，客户可以复用已有的13个监控指标，也可以基于这个架构进行二次开发，这里就分享一下我们在使用Amazon CloudFront Extensions的CloudFront 监控时学习到的一些经验。

2.解决方案概览

2.1 非实时监控non-real-time-monitoring

这个是官方给的基于标准日志监控的架构图，方案的实现流程图中也一目了然，具体的解释可以去参看官方文档的描述，这里不多赘述，详见：https://awslabs.github.io/aws-cloudfront-extensions/zh/monitoring/non-real-time-monitoring/。解决方案最终以API或UI的方式对外提供监控指标查询的。

从使用者的角度看，方案还是很有特点的：

首先是CloudFormation一键部署，这个很方便。方案使用了API Gateway、Lambda、DynamoDB、S3、Athena、Glue、EventBridge。我们后续改造还使用了EC2。不得不说Amazon的服务组件真的够多，虽然减少了很多的开发工作量，但是如果单独去部署这么多组件，学习难度本身就很大了。CloudFormation很好的解决了这个问题。

然后是通过对日志的二次处理提升了查询效率。CloudFront标准日志包含30多个字段。有些字段对于日常监控和数据统计来讲可能不太用的上，因此在方案中并没有标准日志存进S3之后直接用于查询分析，而是进行了一个二次处理，删除了不需要的字段再存进S3，以减少Athena扫描的日志量，提升效率，减少成本。

2.2 实时监控real-time-monitoring

上图是基于实时日志的监控架构图，本身架构也很完善，性能也OK，不过我们再实际使用中，出于成本和实际需要求的考虑，又对实时监控做了另外的改造。

2.3监控改造方案

标准日志监控的部分，沿用了官方Amazon CloudFront Extentions的方案，不过将处理日志的Lambda换成了EC2；

实时监控部分，官方给出的方案中可以基于实时日志分析出很多指标信息，有些指标如根据下载速率基于国家和运营商的分布是CloudWatch中没有的。由于我们的客户需求对于实时监控主要要求的指标有带宽、流量、状态码、缓存命中率、回源带宽等都可以直接从CloudWach获取或转换的指标，所以这里对于实时指标要求较简单的场景来讲，我们可以通过Lambda获取CloudWatch接口数据来处理，然后写入DynamoDB中。对于CloudWatch中不支持的指标，再使用此方案。

这样可以节省掉实时日志监控系统产生的资源成本，又能做到以统一的接口格式对外提供实时监控指标和标准日志的监控指标。

3. 方案部署

3.1基于标准日志的监控

标准日志监控，在亚马逊云科技已经发布了官方的部署指南，部署也很简单，直接通过CloudFormation一键部署即可，这里就不在复述了。我们部署了Non-real time monitoring，不过官方版本部署之后，我们在使用中，还是发现了一些问题，并针对性做了一些调整优化。

3.1.1调整一

就部署资源和程序而言，我们在官方的基础上替换了处理原始日志的Lambda，将其替换成了EC2，并且给EC2添加SQS和S3的权限。

为什么这么做呢？原因有两点：

一是Lambda本身是有内存的限制的，而官方在这里的处理机制是把整个日志包全都读入内存之后才开始处理，日志过大就会发生内存溢出进而无法处理对应日志里的内容造成数据缺失，日志太小有会造成资源浪费。

那为什么要换成EC2，不能改Lambda的处理机制呢？当然也可以的，不过这就是我要说的第二点原因。我们账号下正好有一台做日志格式定制化转换的EC2资源，换成EC2也是为了更好地复用资源，节省成本。

当然EC2里处理机制也做了定制开发，改成了边读取边处理，避免出现同样的内存为题。这个机制也可通过Lambda实现。

3.1.2调整二

Athena查询S3桶中日志的sc-bytes字段，官方默认使用的类型是int，这对于小流量是没有问题的，但是我们实际使用当中，比如5分钟的流量字节数超过了int类型的长度限制，就无法查询出正确的结果，如图：

所以这里我们把int改成了bigint。对于大流量用户而言，这里也要注意一下。

3.2实时指标监控

上文中描述了对实时指标的改造，这里需要创建一个Lambda函数，部署代码，以便获取CloudWatch接口指标并写入Amazon DynamoDB中。

在AWS Lambda控制台，点击创建函数，编辑好函数名和编写函数的语言（这里我们用了Python）

关联以下角色权限：

创建后将对应的程序代码部署该Lambda函数中。

4. 方案使用说明

4.1开启日志

基于标准日志的监控分析，部署之后要使用起来，需要先开启对应分配的标准日志。

打开CloudFront控制台，在分配标签下单击需要创建标准日志的分配(Distribution)ID。

在设置中点击编辑按钮，打开编辑设置并找到标准日志记录。

选中打开，并在S3 存储桶列表中找到包含-cloudfrontlogbuckete关键字的选项，将其设置为传输日志文件的 S3 存储桶。如果您没有找到对应名字的S3存储桶，请确认是否在部署解决方案时，参数CloudFront Log Type为yes-Non-Realtime，详情请参阅部署解决方案。

最后点击保存更改，使设置生效。

4.2调用API

URL：endpoint

调用方法： GET

认证：header: x-api-key

请求参数：

参数名	是否必要	参数值
Domain	是	查询域名，多个域名以逗号, 分隔，也可用All 来直接拉取全部域名的值 ( www.a.com,www.b.com,www.c.com )
StartTime	是	开始时间，0时区。格式严格匹配“ YYYY-mm-dd HH:MM:SS ” 例如 2022-05-24 13:00:00
EndTime	是	结束时间，0时区。
Metric	是	标准日志指标参数 [stdRequest \| stdStatusCode \| stdBandwidth \| stdBandwidthOrigin \| stdDownstreamTraffic \| stdChr \| stdRequestOrigin \| stdAll] 实时指标参数 [rtRequest \| rtStatusCode \| rtBandwidth \| rtBandwidthOrigin \| rtDownstreamTraffic \| rtChr \| rtRequestOrigin \| rtAll]

接口响应参数：

{
    "Response": {
        "RequestId": "b30e37f1-4b48-44b5-89cc-d09157b087e9",//请求ID
        "Interval": "5min",//粒度
        "Data": [
            {
                "www.a.com": [//domain
                    {
                        "Metric": "stdBandwidth",//指标类型
                        "DetailData": [//具体指标数据
                            {
                                "Time": "2022-08-01 08:00:00",
                                "Value": "8062630279"
                            },
                        ]
                    }
                ]
            }
        ]
    }
}

5方案测试

5.1单域名标准日志指标测试

5.2多域名实时指标测试

6 小结

本文介绍了我们是如何基于Amazon CloudFront Extensions进行二次开发，最终构建出符合特定客户需求的CDN监控解决方案。除了监控解决方案外， Amazon CloudFront Extensions还提供了CloudFront配置快照、SSL证书批处理和扩展存储库等功能，详情参考：https://awslabs.github.io/aws-cloudfront-extensions/zh/

亚马逊AWS官方博客