背景：

公司开发环境内部开发。路由器做了设置只允许访问特定资源网站。自从做了限制后内网隔离网络环境出现特定资源pending现象。一直也没有做深入的研究。因为同一内网vlan中有能上网的小伙伴。一般情况下他手动去刷新一下就好了。最近频繁出现。记录一下排查问题过程和腾讯云cls日志服务的使用过程。

一 分析cdn日志

1. 分析日志http 状态码(咱们nginx中常用的status)

仔细研究了下cdn日志监控，http code如下（资源都是使用的腾讯云的，不做其他声明都为腾讯云服务）：

301重定向忽略。详见：https://blog.csdn.net/snowin1994/article/details/86478256，顺便盗个图：

2. HTTP CODE 304

304的含义不是重定向。304表示用户查找的资源存在，但是不满足请求需要的条件。一般出现304的情况，请求首部中包含if-xxx这样的条件请求，当判断条件为假的时候就会返回304。看的不甚了了，看不懂。说人话还是下面的：

参见：http://www.361way.com/statuscode/1139.html。这个问题有什么解决方案有没有大佬有好的思路。可以告知下。

通过以上的日志分析，个人基本确定出现这pending的原因大概率是http304原因就是开发小伙伴经常F5刷新，刷新去cdn验证资源发现木有时效。返回304作为cdn加速 我肯定希望用户用本地的资源了......可是昨天聊了下我们这边的前端应该没有处理这样的。....但是本地不知道去哪里加载资源了.....。再次验证了一下出现http code304的ip列表 发现大部分的都是公司的公网ip.....当然了还有早时候应用也出现过。估计都是没有处理这状态。懒得做各种处理了。让客户端应用小伙伴去处理了。

另外下载文件还整了很多自定义类型.....忧伤，如果程序方面自定义文件类型的，我觉得正常应该跟运维提前交流下的,起码自定义下minitype吧？工作就是不停的发现坑埋坑。

二. CDN开启日志服务，检索日志

顺便讲一下啊腾讯云日志服务： cdn中可以开启实时日志服务，顺便聊一下了。

应用管理页面： https://console.cloud.tencent.com/cdn

1. 开通实时日志收集

服务日志-实时日志-立即开通

确定授权-同意授权

2. 新建实时日志收集

新建日志收集信息

关于新增日志主题的主题名称---我是直接域名中间用-分割了（可输入1-255个字符，允许的字符为a-z、A-Z、0-9、_、-，主题名称创建后不可更改）

3. 尝试搜索日志

点检索尝试一下（我昨天点击的时候貌似是直接跳转到日志服务cls的检索分析了）：

这里能进行一下简单的搜索

点下更多检索分析，嗯这里就跳到了日志服务的检索分析，个人来说用日志服务都是做图表用，检索的场景较少。没有接入这样的应用。

三. 做几个图表 visualize

1. http_code饼形图

对着图表分析的实例。做一个饼形图？：

* | select count(*) as count, status group by status

cdn的日志 status对应的是http_code，故：

* | select count(*) as count, http_code group by http_code

what？查询语句解析错误？这个提示很不友好.......。虽然提示里面写了字段要开启统计，但是大多数人默认以为腾讯自己的业务，默认会开启了开启统计功能了。

好吧，打开索引设置。将要开启统计的自动开启统计。个人是开启了client_ip http_code isp request_time time 几个字段。

具体cdn日志字段含义参照：https://cloud.tencent.com/document/product/228/6316

注意：开启统计后可聚合数据只针对当前修改后的数据生效：

304对于我来说占用了大部分 先添加到https://cloud.tencent.com/developer/article/1811695的仪表盘

2. isp饼形图

顺便搞一个isp分布看下用户使用的网络isp服务商：

* | select count(*) as count, isp group by isp

段时间的用户 移动和电信还是占比较高的......,继续保存到仪表盘

3. prov--地域分布饼形图

刚发现prov是代表了地域？也开启一下索引配置，开启统计(开启了也是有延迟的登60秒？)

发现一个很坑的东西：

按照我的理解：

* | select count(*) as count, prov group by prov

对应的数列值应该是不是就应该是count？group by的是聚合列啊？为什么用查询语句出来聚合列变成了count,数列值是prov呢？还要手动让我更改一下......这个地方做的感觉不合理。

而且当然了，这个地方能变成中国地图就更好了......

4. 每分钟地域分布访问折线图与表格

继续复习一下折线图，嗯这个还好聚合的列没有整诡异了。

* | SELECT HISTOGRAM(CAST(__TIMESTAMP__ AS TIMESTAMP), INTERVAL 1 MINUTE) AS dt, COUNT(5) AS "每分钟到每地域的请求数", prov GROUP BY dt, prov order by dt

也可以直接表格

最终仪表盘效果如下：

总结一下：

cdn日志接入cls日志可以更方便的检索，以往都是要等日志生成下载到本地的.而且日志的下载有很大的延迟性：

投递到日志服务好歹算是近实时的了。能追踪更新的日志状态更早的发现问题。

嗯其实还有一个没有说的 https://cloud.tencent.com/developer/article/1811695中写的监控报警。cdn出现各种状态码默认是不知道的。可以在日志检索中搞一个出现非200 404的日志的报警。这样能更早的发现状态的异常。