cdn又拍云日志分析与流量监控的配置与实践建议

1.

准备与前提：账号、域名与权限确认

1.1 登录又拍云（Upyun）控制台，确认有管理该 CDN 域名的权限（主账号或有该域名的子账号权限）。
1.2 确认已备案/已接入的域名与对应的服务配置，记录域名、服务 ID、加速区域等信息。
1.3 准备存放日志的目标：建议使用对象存储（如又拍云对象存储/OSS）、或外部 S3 兼容存储，确保存储有生命周期策略与访问凭证（AK/SK）。

2.

开启又拍云 CDN 日志并配置导出

2.1 控制台操作：登录控制台 -> 找到“CDN/加速域名” -> 进入目标域名设置 -> 找到“访问日志”或“日志管理” -> 打开访问日志开关。
2.2 日志导出目标：选择导出到又拍云对象存储或第三方 S3，填写 Bucket 名、路径前缀、访问密钥等。确保写入权限（PutObject）。
2.3 日志格式：选择文本格式（常见为 Nginx/Apache 风格或又拍云自定义字段），记录字段应包括时间、client_ip、请求方法、uri、状态码、响应大小、上游耗时、cache 状态（hit/miss）、edge 节点等。
2.4 验证：保存并等待 5-10 分钟，使用对象存储控制台查看是否有按天/小时生成的日志文件（通常按日期前缀）。

3.

获取并下载日志：自动化获取方法

3.1 使用对象存储 API 直接列举并下载：示例 curl（S3 签名或又拍云 SDK）：编写小脚本（Python/Go）按天拉取并解压日志。
3.2 推荐 crontab：每天凌晨 00:10 运行脚本拉取前一天日志并保存到处理目录：crontab -e -> 10 0 * * * /usr/local/bin/fetch_upyun_logs.sh。
3.3 本地存储与清理：设置日志保留策略，样例：保留 30 天，使用 find /data/logs -mtime +30 -delete 定期清理。

4.

日志解析：使用 Filebeat + Logstash（或直接 Filebeat -> ES）

4.1 部署 Filebeat：在日志存放服务器安装 Filebeat，配置 filebeat.inputs 指向日志目录和通配符，例如 /data/upyun_logs/*.log。
4.2 Logstash 过滤器（示例 grok）：在 /etc/logstash/conf.d/upyun.conf 中配置 pipeline： - input { beats { port => 5044 } }
- filter { grok { match => { "message" => "%{TIMESTAMP_ISO8601:ts} %{IP:client_ip} \"%{WORD:method} %{DATA:uri} HTTP/%{NUMBER:http_ver}\" %{NUMBER:status} %{NUMBER:bytes} \"%{DATA:referer}\" \"%{DATA:ua}\" %{NUMBER:upstream_time:float} %{WORD:cache_status}" } } date { match => ["ts","ISO8601"] } }
- output { elasticsearch { hosts => ["http://es:9200"] index => "upyun-cdn-%{+YYYY.MM.dd}" } }
4.3 说明：根据实际日志格式调整 grok 模式，建议先用 grokdebug.herokuapp.com 测试样例行。若日志为 JSON 格式，可直接 json filter。

5.

Elasticsearch 索引模板与字段映射建议

5.1 为索引设置模板，保证时间字段（@timestamp）为 date，bytes、upstream_time、status 为数值类型。示例 PUT _template/upyun_cdn_template。
5.2 为常查询字段（uri、client_ip、status、cache_status、edge_node）设置 keyword 类型以便聚合。
5.3 设置索引 lifecycle（ILM），样例：热天 7 天，温天 30 天，冷天滚动归档到低成本存储。

6.

Kibana 可视化与常用仪表盘

6.1 创建索引模式 upyun-cdn-*，使用 Discover 检查字段是否正确解析。
6.2 常用可视化（建议）：QPS（每分钟请求数）、带宽（bytes sum/hour）、响应码分布、Top URI、Top Client IP、缓存命中率（cache_status = HIT / MISS）、上游耗时 P95/P99。
6.3 仪表盘布局：将上述可视化组合成单页监控大盘并保存，设置时间范围自动刷新（如 1m）。

7.

实时告警与阈值配置

7.1 告警工具选择：Elasticsearch Watcher（X-Pack）、ElastAlert 或 Prometheus+Alertmanager（通过 exporter 导出）。
7.2 常见告警项与阈值建议：带宽突增（5 分钟内增长 > 2x）、请求数异常（QPS 超过历史均值 + 3σ）、响应 5xx 升高（5 分钟内 5xx 占比 > 3%）、缓存命中率骤降（小于 30%）。
7.3 告警动作：发送钉钉/企业微信/邮件并附上 Kibana 链接与最近 15 分钟 Top URI，便于快速定位。

8.

排查流程与实践建议

8.1 缓存命中率下降：检查请求 URI 是否包含不必要的 query 参数，建议使用 CDN 去参数化或配置缓存 Key；检查 Cache-Control/Expires 源站头。
8.2 带宽/流量突增：通过 Top URI 与 Top referer、Top IP 判断是否为业务真实流量或爬虫/盗链，必要时配置防盗链或 WAF 规则。
8.3 5xx/4xx 增多：查看 upstream_time 与 edge_node，确认是否为源站限流或某个节点异常，使用又拍云控制台回放请求或使用 purge+回源策略测试。

9.

自动化与优化：缓存策略与日志采样

9.1 缓存策略：对静态资源设置长缓存（cache-control: max-age=31536000, immutable），动态内容走 no-cache 或短缓存并加版本号。
9.2 日志采样：在高流量场景下，可在采集层对日志进行采样（例如 1%）用于实时监控，异常检测触发后再回溯全量日志。
9.3 流量削峰：结合又拍云限速/并发控制、源站降级与临时页面策略，应对突发洪峰。

10.

问：如何快速确认又拍云日志中的缓存命中率问题？

答：步骤：1) 在 Kibana 中按时间窗口聚合 cache_status（HIT/MISS/EXPIRED）；2) 计算命中率 = HIT / (HIT+MISS)；3) 若命中率骤降，查看 Top URI 与 Query 参数、Referer，看是否有 query 参数导致缓存键失效；4) 检查源站返回的 Cache-Control 和 Set-Cookie（带 Set-Cookie 则默认不缓存）；5) 如发现问题，调整缓存策略或在 CDN 端配置忽略指定 query 字段。

11.

问：如何在日志解析阶段确保时间同步与精确的响应时间统计？

答：1) 确保所有组件（边缘节点、日志生成服务器、Elasticsearch 节点）使用 NTP 同步时间；2) 在 Logstash 的 date filter 指定日志时间字段并设置时区；3) 在解析中取 up_time/upstream_time 为上游耗时字段并转为 float，使用 scripted metric 在 ES 中计算 P95/P99；4) 在 Kibana 可视化中使用 percentile 聚合以监控响应时间分布。

12.

问：在预算有限的情况下，如何用最少资源实现有效流量监控？

答：建议做法：1) 只解析关键字段（时间、client_ip、uri、status、bytes、cache_status、upstream_time），减少 ES 字段数；2) 使用 Filebeat 直接输出到 Elasticsearch，省去 Logstash 节点；3) 启用索引生命周期管理（ILM）和数据压缩，保留热数据 7-30 天；4) 使用采样+告警模式：平时采样 1%-5% 日志用于监控，触发异常时再临时采集全量；5) 使用又拍云控制台自带的基础监控（免费）结合轻量级 ELK 即可覆盖大部分需求。