浅谈
- OSS 和云监控是两个独立的产品，但是 OSS 控制台上看到的存储容量监控以及贷款流量监控来自于云监控产品的数据。
- OSS 的监控数据延迟 2-3 小时，同时云监控在采集 OSS 数据时存在窗口期，比如 5 分钟，如果超过窗口期后，云监控不在接受过期的数据，同时也不支持补推。
- 所以建议广大用户不要用 OSS 控制台的监控和账单进行对账，那样是不准确的。如果要进行对账，请务必开通 OSS log 的方式去核对 log 日志计算，那样才是相对准确的值。
案例分析
案例：
云监控 OSS 出现 "数据不足"
分析：
先看下 OSS 控制台的监控的 http code 、以及 QPS 分析，如果 OSS 请求量比较小，而 OSS 对应的时间点有没有请求就会出现数据不足的情况，这种问题最好设置合理的监控数据上报时间。
案例：
云监控发现上传下载延迟
分析：
- 这种情况是云监控产品节点发起的探测请求，不能完全代表真实的 OSS 用户，最好能够以真实的业务请求为准，或者真实的客户端在访问发生延迟时，客户端部署抓包看下为什么有延迟。
- 使用 OSS的日志功能，开始日志后，OSS 的所有者可以自行通过日志进行分析。看下处理时间是否真的有延迟。
案例：
用户自己监控系统发现请求有延迟
分析：
有的公司技术支持比较全面自己做了一套监控系统可以监控 OSS公网全链路，但是监控的只是网络传输的时间，可以辅助的去看问题，但是不可全信，当发现有延迟时。
- 公网的链路无法保证，做好能切到阿里云主机上，使用同 region 的 OSS 域名进行访问比较靠谱，如果有原因不能切到内网，需要进一步再确认。
- 提供上传延迟的 OSS requestID ，通过这个可以让阿里云查下出现问题的处理时间是否真延迟。
- 客户端肯定要抓包了，所有网络问题都逃不了抓包，传授一个抓包技巧
- tcpdump -i <出口网卡> -s0 ( 本机出口IP and OSS域名 ) -w result.pcap
案例：
有效请求率降低
对象存储 OSS (<)Bucket=p2xxx，userId=135114002(>)，有效请求率（30.51<90% ），持续时间0分钟>
分析：
请求率规则是 2xx+3xx/总体数量计算出来的，先看下 OSS 控制台的统计 2XX 3XX 以及其他遗产状态码的占比确认是否因为异常状态码增加导致的有效请求率下降。
另外最靠谱的就是自己开通 OSS 的日志随时可以分析请求行为。
案例：
云监控报警 404
对象存储OSS实例：Bucket=xum-ali，userId=19733976745，资源不存在错误请求数于11:45恢复正常，值为30次，持续时间5分钟。
规则详情：报警规则oss_ResourceNotFoundErrorCount，资源不存在错误请求数的5分钟统计值，连续1次满足表达式当前值>30次
分析：
- 这种问题就是 bucket 资源不存在报警，如果上面的方法都是要自己开通 OSS 日志服务模块来分析，不过这种 404 也是正常的响应，并非是异常状态。
案例：
云监控出现 NoSuchWebSiteConfigration
分析：
出现这种问题是客户端在请求 OSS 时加载的功能配置不存所以报错 404 ，是正常请求，不是异常。200 的转状态是用户已经在 OSS 上配置的功能模块，报警人可以忽略这部分的报错信息。
案例：
OSS 控制台 API 统计图无数据
分析：
这种情况并不是异常，完成的监控数据都是隔天显示，当前时间是 10.12 ，完整的数据还没有出来，所以不能画点，要等到 13 号才能看到完整的 12 号数据。
案例：
通过 OSS 监控计费账单对比
分析：
先了解 OSS 监控
- 概览看到的当月请求次数有 “GET” 读去类型，和 “PUT” 写类型，“GET” 类型包括了 HEAD GET，“PUT” 类型包含了 PUT、DELETE、POST ，这点高搞清楚。
- OSS 的监控是云监控的数据有 2-3 小时的延迟，用它和账单计费肯定是不准的。
结论：
准确合理的对账方式通过两种途径：
- 提前开启 OSS 日志，然后通过 OSS 日志的统计和账单核对。
- 如果自己不愿意核对日志，可以开启 OSS 的日志分析功能，把 OSS 的日志导入到日志分析处理，直接看结果。
案例：
云监控显示某个时间段的有效请求率下降为 0，但是 OSS 的 log 以及控制台的监控数据都是正常。
分析
首先要知道源监控有效请求率的计算是 （2x x+3xx)/总请求数量
发现类似情况观察下 OSS 控制台或者 OSS log 没有异常即可，出现这种问题是因为 OSS 再收敛整个集群日志推送到云监控时超过了云监控的接收窗口期，而云监控不支持补推，所以这块数据调为 0 。
目前 OSS 再 2019-1-1 后对监控数据进行优化可以规避掉这种问题，后续还会持续优化类似场景。
