http状态码(一)汇总

一  http状态码汇总

说明： 该'系列'虽然都是关于'nginx的报错汇总',但是其它http服务也'适用'

补充： 本文'不讲解'nginx的具体报错,只讲解一些'通用'的排错思路

备注： 由于暂时'脱离LB领域,'关于'排查思路'会慢慢进行'添砖加瓦',后续进行'补充'

①  知识铺垫

1、从'请求流'的角度,任何'中间环节'出现问题都有可能'导致异常'

备注： 日志中'没有'记录相关的请求,并不意味者请求没有到'该环节服务'的节点

2、nginx的'访问'和'错误'日志

  1）log_format 'access访问' 日志格式 --> nginx的相关'变量'  --> 有没有记录'请求'日志

  备注： 哪些'变量 信息'能说明'哪些'问题?

  2）error.log的 '日志级别' --> 可以'调整'

  日志级别：要不要'debug'

  3）思考：nginx何时'哪个阶段'才会记录日志,什么情况报错但是'不会'记录日志

3、问题出现的'频率'： '偶现'、必现、有条件的'必显'

  说明： 必显的一般比较好分析,要密切关注发生故障的'时间点'、做哪些'变更操作'、'客户体量爆增'

  附加： 关于'偶现'的问题,比较难分析,一般要从网络环境、监控指标、抓包等'综合'分析

  '有条件'的必显： 改变'请求'方式、某个时间区间访问等

4、跟踪请求'上下文' --> 'time_point'和'跟踪'traceid  

5、nginx的连接分'两个方向'  --> '两个方向的配置参数'

  1、client --> 'nginx' 代理

  2、nginx  --> '后端'

6、报错所提供的 'effective 有效'信息 --> 'client、nginx代理、后端'三个维度的'报错'

 1) 要结合'客户端'现象,客户端是哪种'形式 [postaman、chrome、curl]'等

 客户端提供的有效'关键'信息,哪个'接口(详细信息)',哪个服务,'请求id'追踪

 思考： 客户端展示的'报错'信息是谁'返回'的  --> '自身'、代理、亦或者是'后端返回'

 2) 根据'请求接口和traceid'等方便我们快速定位请求流 --> '请求链路'

 备注： 定位到'具体的nginx机器 [集群]',看相关日志'access'和'error'进行'分析'

 补充： 要观察'nginx代理服务器'的负载、CPU和内存、TCP连接状态等 '监控指标'信息

 3) 如果'$upstream_addr'有值,一般意味着请求转发到'后端'了,此时就要'结合'后端服务分析了

 扩展： 根据自己涉及的'业务环境',合理掌握一些'后端'的排查点,比如Java的'JVM'性能分析

7、请求'链路'经过哪些'组件'

 说明：在无法凭借'经验'快速'定位定界'后,只能通过'一层一层'分析了

 补充：故障'边界',引申出后续的'责任'边界,发生故障的组件不一定是由于自身引起的,上下游都有可能

 引申： 发生规章后,第一'要义'是回复故障

温情提示： '没有'记录日志并不意味着'请求没有到改环节',或者说并不意味着没有'建立连接'

8、关于更多的'排错细节'我们在讲解'具体错误'状态码再进行分析,不同的状态码分析思路有一些'差异'

②   该系列的讲解思路

1、不会按照 '2xx'、'3xx'、'4xx'、'5xx' '递增'的顺序

 备注： 会结合'官方的语义'以及对应'http'报错的场景'综合'讲述

 补充： 关于'nginx'自身提供的http状态码也会'穿插'讲解

2、在'http 应用层'和'传输层'之间搭建桥梁

备注： 虽然讲解的是'http状态码'报错,但更多'倾向'的是nginx的报错