nginx(三十六)健康检查

一   ngx_http_upstream_module  官方自带

①    server

1.  该指令用于'指定后端服务器'的名称和'optional'参数

2.  服务器的名称可以是一个'域名'、一个'ip地址'+端口号或'unix socket'

upstream  backend {
  server  wzj.example.com    weight=5;
  server  127.0.0.1.8080     max_fails=3   fail_timeout=30s;
  server  unix:/tmp/wzj
}

②  parameters解读

1）常用max_fails和fail_timeout

max_fails和fail_timeout：最大失败次数和失败时间段，两个参数需要'一起使用'

默认值：分别为1'次'和10s

+++++++++++++++  "案例解读"  +++++++++++++++

server 172.25.2.100:8081 max_fails=2 fail_timeout=10s;

[1] 在10s内'访问到此服务器'2次,若'都访问'失败,则认为此服务器暂时不可用,nginx则会把'请求分发'到其他服务器

[2] 等待'10s后'继续访问此服务器,若'该时间段'内'2次都失败'继续执行'上述'过程;若成功,则'正常'运行

细节点：只有'请求过来的'时候,才会'尝试','不会'主动探测与后端的'连通性'

down：'节点下线用','不让'流量'转发'到这个'后端'节点

  2）不常用

说明：涉及'参数比较多',需要时'查找'即可

 max_conns 节点服务器的最大连接数,服务器的并发最大连接数 可以设置合理范围 相当于'限流'

二    ngx_http_proxy_module  了解

nginx如何隐藏上游的错误

①   proxy_next_upstream

proxy_next_upstream 指定出现'何种错误或异常',将请求'转到'下一个节点

invalid_header: 后端服务器返回'空响应'或者'非法响应头'

细节点：只有在"没有"向客户端发送任何数据"以前",将请求转给'下一台后端服务器'才是可行的.也就是说,如果在传输响应到客户端时出现'错误或者超时',这类错误是'不可能恢复'的

 参考链接

三    nginx_upstream_check_module第三方模块

淘宝官方的解读

①    为什么要使用第三方模块

1. 服务'治理'的一个重要任务是'感知服务的变更',完成服务'自动注册'及'异常例程'的自动摘除

2. 这就需要'服务治理平台'能够：及时、准确的感知服务例程的'健康'状况

nginx'自带'的check模块相对来说比较"粗糙",推荐使用'淘宝技术团队'开发的nginx_upstream_check_module

特点：

  1、'主动'地健康检查,nignx'定时'主动地去ping后端的服务列表

  2、当发现某'服务出现异常'时，把该服务从健康列表中'移除'

  3、当发现某服务'恢复'时,又能够将该服务'加回'健康列表中

思考：这个过程有'日志'记录没有?

++++++++ "说明"  ++++++++

1.  需要'源码'编译,目前'rpm'包'没有'自带

2.  支持'多种维度'的健康检查,粒度更'细'

②  编译安装

补丁版本的选择：'nginx版本' > '补丁版本' 

关注：check_1.12.1+.patch、check_1.14.0+.patch、check_1.16.1+.patch、check_1.20.1+.patch即可

③  check指令语法讲解

+++++++++ 'check指令'参数'细讲' +++++++++

④  check_http_send和check_http_expect_alive

在采用" GET"方法的情况下,请求uri的'大小不宜过大',确保可以在'1个间隔内'传输完成,否则会被健康检查模块'替换'服务器或'网络异常'

 其它参数参照官方解读

 ⑤  tcp的健康检查

upstream wzj {

    server 172.25.2.100 max_fails=0 fail_timeout=0;

    check internal=1500 rise=1 fall=3 timeout=3000 type=tcp;
} 

解读：'禁止'nginx'自带'的检测机制,使用'第三方模块'的,上面是常见的'tcp'涉及的参数

附加：每隔'1.5s'就向'后端server'发一次'tcp'的健康检查包,如果'连续失败三次',则认为后端出现故障;如果'成功一次'则认为'后端'成功

备注：每次'请求响应的超时时间'不能超过'3000ms'

遗留点：nginx 'access.log'或'error.log'是否会'记录'日志?

⑥  http的健康检查

说明：健康检查的'颗粒度'更细,防止'后端进程僵死(port还通)',但是服务'不通(后端处理不了HTTP请求)'

+++++++++++++ "http健康检查的案例"  +++++++++++++

upstream wzj {
    server 172.25.2.100:80 max_fails=0 fail_timeout=0;
    check fall=3 interval=3000 rise=2 timeout=2000 type=http;
    check_http_expect_alive http_2xx http_3xx ;
    # 探针'路径' --> /is_alive
    check_http_send "GET /is_alive HTTP/1.0\r\n\r\n" ;
}

补充：可以加'请求头'满足复杂的'认证'之类的;注意多个请求头以'\r\n'分割

 1）nginx准备配置段

 2）请求1

+++++++ 后端查看是否有'探测'请求 +++++++

遗留： 会产生大量的探测'日志',注意日志'防爆'

4）请求2

⑦  健康状态页面

 字段含义

+++++++++++++ "排查down的原因" +++++++++++++

1）首先从nginx侧telnet或者curl或者wget测试下'端口'的连通性

2）如果四层是ok的，再看nginx的后端是否记录日志

3）如果后端有日志，可能'业务逻辑不支持HEAD请求方式'或者HTTP1.0低协议版本（替换这个两个信息），或者'后端处理请求超时'(超过timeout的阈值)，导致非2xx和3xx的报错

辅助排查：修改check_http_expect_alive为某个'指定的xx'

4）只能tcpdump抓包

⑧   注意事项

openresty配置详解

nginx开源社区视频