一 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的报错