背景：
公司开发环境内部开发。路由器做了设置只允许访问特定资源网站。自从做了限制后内网隔离网络环境出现特定资源pending现象。一直也没有做深入的研究。因为同一内网vlan中有能上网的小伙伴。一般情况下他手动去刷新一下就好了。最近频繁出现。记录一下排查问题过程和腾讯云cls日志服务的使用过程。
一 分析cdn日志
1. 分析日志http 状态码(咱们nginx中常用的status)
仔细研究了下cdn日志监控，http code如下（资源都是使用的腾讯云的，不做其他声明都为腾讯云服务）：
查看监控详情。4XX基本是404忽略。看了一眼3XX的监控，
301重定向忽略。详见：https://blog.csdn.net/snowin1994/article/details/86478256，顺便盗个图：
| 状态码 | 备注 |
|---|---|
| 301 | Moved Permanently |
| 302 | Found |
| 303 | See Other |
| 304 | Not Modified |
| 307 | Temporary Redirect |
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的日志的报警。这样能更早的发现状态的异常。