ngx_http_upstream_hc_module 模块

ngx_http_upstream_hc_module 模块允许对周围 location 引用的组中的服务器进行定期健康检查,服务器组必须驻留在共享内存中。

如果健康检查失败,服务器将被视为不健康。如果为同一组服务器定义了多个健康检查,则任何检查的单个失败都会使相应的服务器被认为是不健康的。客户端请求不会传递给不健康的服务器和处于“检查”状态的服务器。

请注意,与运行状况检查一起使用时,大多数变量将具有空值。

该模块作为我们商业订阅的一部分提供。

示例配置

upstream dynamic {
    zone upstream_dynamic 64k;

    server backend1.example.com      weight=5;
    server backend2.example.com:8080 fail_timeout=5s slow_start=30s;
    server 192.0.2.1                 max_fails=3;

    server backup1.example.com:8080  backup;
    server backup2.example.com:8080  backup;
}

server {
    location / {
        proxy_pass http://dynamic;
        health_check;
    }
}

使用此配置,nginx 将每五秒向后端组中的每个服务器发送 “/” 请求。如果发生任何通信错误或超时,或者代理服务器响应的状态码不是 2xx 或 3xx,则健康检查将失败,服务器将被视为不健康。

运行状况检查可以配置为测试响应的状态代码、某些标头字段及其值的存在以及正文内容。测试使用 match 指令单独配置,并在 health_check 指令的 match 参数中引用:

http {
    server {
    ...
        location / {
            proxy_pass http://backend;
            health_check match=welcome;
        }
    }

    match welcome {
        status 200;
        header Content-Type = text/html;
        body ~ "Welcome to nginx!";
    }
}

此配置表明,为了通过健康检查,对健康检查请求的响应应该成功,状态为 200,并且在正文中包含 “Welcome to nginx!” 。

指令

health_check 指令

语 法:health_check [parameters];
默认值:—
上下文:location

启用对周围 location 引用的组中的服务器的定期运行状况检查。

支持以下可选参数:

  • interval=time 设置两次连续健康检查之间的间隔,默认为 5 秒。

  • jitter=time 设置每次健康检查随机延迟的时间,默认没有延迟。

  • fails=number 设置特定服务器的连续失败的健康检查次数,之后该服务器将被视为不健康,默认情况下为 1。

  • passes=number 设置特定服务器的连续通过健康检查的次数,之后服务器将被视为健康,默认情况下为 1。

  • uri=uri 定义健康检查请求中使用的 URI,默认为“/”。

  • mandatory [persistent] 设置服务器的初始“检查”状态,直到第一次健康检查完成(1.11.7)。 客户端请求不会传递给处于“检查”状态的服务器。 如果未指定该参数,则服务器最初将被认为是健康的。

    如果服务器在重新加载之前被认为是健康的,那么持久参数 (1.19.7) 在重新加载之后设置服务器的初始“启动”状态。

  • match=name 指定匹配块配置响应应通过的测试以通过健康检查。 默认情况下,响应应具有状态代码 2xx 或 3xx。

  • port=number 定义连接到服务器以执行健康检查 (1.9.7) 时使用的端口。 默认情况下,等于服务器端口。

  • type=grpc [grpc_service=name] [grpc_status=code] 启用 gRPC 服务器或使用可选 grpc_service 参数 (1.19.5) 指定的特定 gRPC 服务的定期运行状况检查。 如果服务器不支持 gRPC 健康检查协议,可选的 grpc_status 参数可用于指定将被视为健康的非零 gRPC 状态(例如,状态代码“12”/“UNIMPLEMENTED”):

health_check mandatory type=grpc grpc_status=12;
  • type=grpc 参数必须在所有其他指令参数之后指定,grpc_service 和 grpc_status 必须跟在 type=grpc 之后。 该参数与 uri 或匹配参数不兼容。

match 指令

语 法:match name { ... }
默认值:—
上下文:http

定义用于验证对健康检查请求的响应的命名测试集。

可以在响应中测试以下项目:

  • status 200;  状态为 200

  • status ! 500;  状态不是 500

  • status 200 204;  状态为 200 或 204

  • status ! 301 302;  状态既不是 301 也不是 302

  • status 200-399;  状态在 200 到 399 的范围内

  • status ! 400-599;  状态不在 400 到 599 的范围内

  • status 301-303 307;  状态是 301、302、303 或 307

  • header Content-Type = text/html;  标头包含值为 text/html 的“Content-Type”

  • header Content-Type != text/html;  标头包含“Content-Type”,其值不是 text/html

  • header Connection ~ close;  标头包含“Connection”,其值匹配正则表达式关闭

  • header Connection !~ close;  标头包含“Connection”,其值与正则表达式不匹配关闭

  • header Host;  标头包含 “Host”

  • header ! X-Accel-Redirect;  标头缺少“X-Accel-Redirect”

  • body ~ "Welcome to nginx!";  body 匹配正则表达式“Welcome to nginx!”

  • body !~ "Welcome to nginx!";  body 不匹配正则表达式“Welcome to nginx!”

  • require $variable ...;  所有指定的变量都不为空且不等于“0”(1.15.9)。

如果指定了多个测试,则响应仅在匹配所有测试时才匹配。

仅检查响应正文的前 256k。

例子:

# status is 200, content type is "text/html",
# and body contains "Welcome to nginx!"
match welcome {
    status 200;
    header Content-Type = text/html;
    body ~ "Welcome to nginx!";
}

# status is not one of 301, 302, 303, or 307, and header does not have "Refresh:"
match not_redirect {
    status ! 301-303 307;
    header ! Refresh;
}

# status ok and not in maintenance mode
match server_ok {
    status 200-399;
    body !~ "maintenance mode";
}

# status is 200 or 204
map $upstream_status $good_status {
    200 1;
    204 1;
}

match server_ok {
    require $good_status;
}
说说我的看法
全部评论(
没有评论
关于
本网站专注于 Java、数据库(MySQL、Oracle)、Linux、软件架构及大数据等多领域技术知识分享。涵盖丰富的原创与精选技术文章,助力技术传播与交流。无论是技术新手渴望入门,还是资深开发者寻求进阶,这里都能为您提供深度见解与实用经验,让复杂编码变得轻松易懂,携手共赴技术提升新高度。如有侵权,请来信告知:hxstrive@outlook.com
公众号