为什么你需要关心CDN边缘的日志？
验证与回滚
折腾CDN Worker时，我发现最麻烦的往往不是安装，而是配置。大多数网站或API都在使用CDN（内容分发网络）加速全球访问。CDN边缘节点每天处理海量请求，但日志通常被写进本地文件或传回中心存储，等你回头去分析时，攻击可能已经结束，或者性能瓶颈早就影响用户体验了。这个延迟就是监控的“盲区”。
如果能直接在每个CDN节点上，实时把日志变成Prometheus能吃的指标，然后一边监控网站性能，一边在攻击发生的第一秒触发安全告警，是不是很理想？这就是“边缘Worker日志生成监控指标”的思路。别被这些术语吓到，下面一个一个拆开讲清楚。
补充参考：此处可内链到“CDN Worker故障排查实例”。
核心概念：三句话讲清
边缘Worker是什么？
边缘Worker是一小段代码（通常是JavaScript或Rust），部署在CDN节点上。每次用户请求经过CDN时，Worker可以：修改请求、修改响应、记录日志、甚至主动发起网络请求。它像一个“智能门卫”，站在离用户最近的地方干活。
因为Worker在请求处理过程中执行，所以它能在极短时间内（微秒级）把日志信息提取出来，直接拼成监控指标。
Prometheus是什么？
Prometheus是云原生计算基金会（CNCF）旗下的监控系统。它的核心是：采集时间序列数据。你告诉它“每隔15秒去某个地址拉一次数据”，它就把这些数据存起来，支持图表展示和告警。
被拉取的数据必须满足一种叫Prometheus exposition format的文本格式。例如：
http_requests_total{method="GET",status="200"} 1024这条记录的意思是：GET方法、状态码200的请求总数当前是1024。你看，它包含标签（label）和数值（value），非常简洁。
云原生监控是什么？
“云原生”不是特指某个云厂商，而是一种用容器、微服务、自动化运维的方式。云原生监控强调：监控数据要自动生成、自动暴露、自动告警，尽量不依赖人工配置。用边缘Worker生成Prometheus指标，正符合这种理念——你只需要写一次Worker代码，部署到CDN，指标就自动在每个节点上产生。
延伸阅读：此处可内链到“CDN Worker配置案例”相关文章。
动手实践：用边缘Worker生成指标
假设你用的是支持边缘Worker的CDN（比如Cloudflare Workers、Fastly Compute@Edge、阿里云CDN EdgeScript等）。下面以JavaScript风格的伪代码为例，讲清楚最核心的三步。
第一步：在Worker里采集请求信息
每当一个请求进来，Worker 可以拿到这些信息：
- 请求路径（/api/users）
- 请求方法（GET、POST）
- 响应状态码（200、404、500）
- 响应时长（从接受到发出响应之间的毫秒数）
- 用户IP（可以判断来源地区）
把这些数据暂存在内存中（注意：不能长期存，边缘Worker是无状态的）。
第二步：用Prometheus格式暴露指标
你需要创建一个单独的HTTP端点（比如 /metrics）供Prometheus拉取。每次有请求打到/metrics时，Worker就把当前累计的统计值拼成Prometheus格式的文本。
例如：
# HELP http_requests_total Total number of HTTP requests
# TYPE http_requests_total counter
http_requests_total{method="GET",status="200"} 1234
http_requests_total{method="POST",status="400"} 56
# HELP http_request_duration_seconds Request duration histogram
# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_bucket{le="0.1"} 800
http_request_duration_seconds_bucket{le="0.5"} 1500
http_request_duration_seconds_bucket{le="+Inf"} 2000
http_request_duration_seconds_sum 450.23
http_request_duration_seconds_count 2000如果你的CDN Worker不支持常驻内存累积，可以采用推模式：在每个请求处理结束时，将这条请求的数据推送到Prometheus Pushgateway。不过推模式会增加网络开销，适合低频告警需求。
第三步：配置Prometheus拉取
在Prometheus配置文件 prometheus.yml 里加上：
scrape_configs:
- job_name: 'cdn_edge_metrics'
metrics_path: '/metrics'
static_configs:
- targets: ['your-cdn-endpoint.example.com']这里的your-cdn-endpoint.example.com是你部署了Worker的CDN域名。Prometheus会按设定的间隔（比如15秒）去拉取。由于CDN节点遍布全球，你可能需要把多个节点聚合起来（比如用Anycast DNS，或者用Prometheus federation）。
相关阅读：此处可内链到“CDN Worker常见问题”专题。
安全告警：从指标到通知
故障定位思路
有了指标，安全告警就能基于这些指标定义规则。例如：
- 请求激增告警：5分钟内
http_requests_total增长超过300%，可能是DDoS攻击。 - 4xx/5xx错误率告警：错误率超过10%，可能被扫描或资源出问题。
- 异常来源IP请求：某个IP的请求频率异常高，可以标记为恶意。
在Prometheus里配置Alertmanager规则即可：
groups:
- name: cdn_attack
rules:
- alert: HighRequestRate
expr: rate(http_requests_total[5m]) > 10000
for: 1m
labels:
severity: critical
annotations:
summary: "CDN节点请求速率过高"Alertmanager收到告警后，可以发邮件、钉钉、Slack或者Webhook调用你的安全系统。
为什么要用边缘Worker，而不是传统日志系统？
配置前的检查
传统的做法是：CDN把日志写入文件 → 用fluentd/logstash采集 → 传到Kafka → 清洗后存入Elasticsearch → 再写查询分析。这条路延迟至少几分钟，而且需要维护一套复杂的日志栈。边缘Worker直接在请求发生时处理数据，延迟降低到秒级。而且你不需要额外服务器——Worker的算力由CDN节点提供，相当于“零成本”获得了一个分布式监控采集端。
注意事项与风险
故障定位思路
1. 不要修改响应Body：Worker里只记录日志，不要动实际响应内容，否则影响用户体验。
2. 计数器的累积问题：如果Worker被多个CDN节点执行，每个节点有自己独立的计数器。你需要在Prometheus端通过标签（比如node）区分，或者使用分布式计数器方案（比如通过CDN提供的Key-Value存储）。
3. 性能开销：虽然Worker很快，但如果在每个请求里都执行复杂的字符串拼接，可能增加少量延迟。建议只采集关键字段，不要全量日志。
4. 回滚方案：万一Worker代码有bug导致网站异常，你需要能快速禁用Worker。大多数CDN控制台都有“一键关闭”或版本回退功能。务必先在测试环境验证代码。
验证与测试——CDN Worker
验证与回滚
部署Worker后，用curl访问/metrics端点：
curl https://your-cdn-endpoint.example.com/metrics你会看到Prometheus格式的指标文本。然后在Prometheus的Web UI里执行查询，比如rate(http_requests_total[1m])，如果出现曲线图，说明成功了。
安全告警的验证：可以用压测工具（如wrk、ab）模拟高并发请求，观察是否触发告警规则。
进阶阅读：此处可内链到“CDN Worker性能优化”指南。
小结与CDN Worker
先看关键判断
利用CDN边缘Worker日志生成Prometheus监控指标，是云原生监控里一个非常“边缘”但高效的实践。它让你摆脱传统日志管道的沉重负担，用最贴近用户的方式实时观察网站状态。即使你是完全不懂基础设施的小白，也能通过本文理清原理，并上手尝试。记住：监控的第一步不是工具，而是明确你想看到什么数据。边缘Worker只是一个帮你“随手记”的便捷工具。
下一步可以思考：如何把多个CDN节点的指标合并到一个全局面板？如何利用边缘Worker做更精细的安全拦截（比如根据规则直接阻断请求）？这些进阶内容，我们后续再聊。按这个顺序复查，CDN Worker遇到异常时也更容易定位。
延伸阅读