Kong05- Kong 的健康检查和监控

简介: 您可以让 Kong 代理的 API 使用 ring-balancer , 通过添加包含一个或多个目标实体的upstream 实体来配置,每个目标指向不同的IP地址(或主机名)和端口。ring-balancer 将在不同的target之间平衡负载,并基于 uptream 配置对目标执行健康检查,使它们成为健康或不健康的,无论它们是否响应,ring-balancer 将只把流量路由到健康的target。

您可以让 Kong 代理的 API 使用 ring-balancer , 通过添加包含一个或多个目标实体的upstream 实体来配置,每个目标指向不同的IP地址(或主机名)和端口。ring-balancer 将在不同的target之间平衡负载,并基于 uptream 配置对目标执行健康检查,使它们成为健康或不健康的,无论它们是否响应,ring-balancer 将只把流量路由到健康的target。

Kong 支持两种健康检查方式,可以单独使用,也可以组合使用。

  • active checks:其中定期请求目标中的特定 HTTP 或 HTTPS 端点,并根据其响应确定目标的健康状态;
  • passive checks: Kong 分析正在代理的通信,并根据目标的行为响应请求来确定目标的健康状况。

健康和不健康的 target

健康检查功能的目标是为给定的 Kong 节点动态地将 target 标记为健康或不健康。没有集群范围内的健康信息同步,每个 Kong 节点分别确定其 target 的健康状况。这是可以取到的,因为在给定的点上,一个 Kong 节点可能能够成功地连接到一个目标,而另一个节点则无法到达。这样第一个节点将认为它是健康的,而第二个则会将其标记为不健康,并开始将流量路由到upstream 的其他 target。

无论是主动探测(针对主动健康检查)还是代理请求(针对被动健康检查),都会生成用于确定目标是否健康的数据。请求可能会产生TCP错误、超时或HTTP状态代码。基于此信息,健康检查器更新了一系列内部计数器:

  • 如果返回的状态码配置为 “healthy”,则将增加目标的 “Successes” 计数器,并清除其所有其他计数器;
  • 如果连接失败,将增加目标的 “TCP failure”计数器,并清除 “Successes” 计数器;
  • 如果超时,将增加目标的 “timeouts” 计数器并清除 “Successes” 计数器;
  • 如果返回的状态代码配置为 “unhealthy”,它将增加目标的 “HTTP failures” 计数器,并清除 “Successes” 计数器。

如果任何 “TCP failure”、“HTTP failure” 或 “timeout” 计数器达到其配置的阈值,则target 将被标记为不健康。

如果 “success” 计数器达到其配置的阈值,则 target 将被标记为健康。
如果一个 upstream 的所有 target 都是不健康,Kong 会将 upstream 的请求返回 503 Service Unavailable

  1. 健康检查只对状态是 active 的 target 执行,不修改 Kong 数据库中目标的活动状态。
  2. 不健康的 target 不会从 loadbalancer 中删除,因此在使用哈希算法时不会对balancer 布局产生任何影响(只会跳过它们)。
  3. DNS警告和 Balancer 警告也适用于健康检查。如果对 target 使用主机名,需要确保DNS服务器始终为完整的 IP地址和名称,并且不限制响应。如果不这样做,可能会导致没有执行健康检查。

健康检查的类型

健康检查有两种类型,分别是 Active health checksPassive health checks

Active health checks

Active health checks 就是主动探测他们的健康状态。当 upstream 实体启用活动健康检查时,Kong 将定期向 upstream 的每个 target 的配置路径发出 HTTP 或 HTTPS 请求。这允许 Kong 根据探测结果自动启用和禁用 balancer 中的 target 。

Active health checks 的周期性是可以被配置的,当 target 是健康还是不健康。如果其中一个的interval值设置为零,则在相应的场景中禁用检查。如果两者都为零,则完全禁用活动健康检查。

Passive health checks

Passive health checks 是否基于由 Kong 代理的请求(HTTP/HTTPS/TCP)执行检查,而不生成额外的流量。当 target 变得无响应时,被动健康检查器将检测到这一点,并将目标标记为不健康。Ring-balancer 将开始跳过这个 target ,因此不会有更多的流量被路由到它。

当目标的问题解决,并准备再次接收流量时,Kong管理员可以手动通知health checker目标应该再次启用,通过一个Admin API端点:

$ curl -i -X POST http://localhost:8001/upstreams/my_upstream/targets/10.1.2.3:1234/healthy
HTTP/1.1 204 No Content

这个命令将广播一个集群范围的消息,以便将 “health” 状态传播到整个 Kong 集群。这将导致 Kong 节点重置在 Kong 节点的所有 worker 中运行的健康检查器的健康计数器,从而允许环平衡器再次将流量路由到目标。

被动健康检查的优点是不会产生额外的流量,但它们不能自动将 target 重新标记为健康状态:“circuit is broken”,需要由系统管理员重新启用目标。

Kong 的监控

Kong 支持使用 Prometheus 进行监控数据采集,并且官方提供了采集方式和 Grafana 的Dashboard 模板

官方的 Kong Plugin Prometheus 会定期更新,看上去比较活跃。

除了官网以外,有网友也提供了一个监控模板,不过最后一次更新时间是2018 年 5 月 17 日,之后就没有更新了,大家也可以参考。kong-prometheus-plugin

小结

Kong 的健康检查主要介绍了健康检查的类型,这两类的健康检查是可以打开和关闭的,打开和关闭的具体方法请参考官网文档。

相关文章
|
XML Java 数据格式
Spring系列(三)之Bean的生命周期以及Bean的单例与多例模式
Spring系列(三)之Bean的生命周期以及Bean的单例与多例模式
|
NoSQL 关系型数据库 MySQL
泛微Ecology9+Emobile7部署
泛微OA的平台化,相比之下,的确是很不错,为方便公司内部考勤,加班审批,报销等流程,这边采用泛微的E9
6787 0
泛微Ecology9+Emobile7部署
|
IDE Java Maven
idea2020版Maven依赖成功导入但仍然报错找不到包解决
idea2020版Maven依赖成功导入但仍然报错找不到包解决
2291 0
idea2020版Maven依赖成功导入但仍然报错找不到包解决
|
应用服务中间件 API nginx
一个超长时间的http api 的 nginx 超时错误 java.io.IOException: unexpected end of stream on Connection
一个长时间的http api 的 nginx 超时错误 直接访问IP是OK的。但是经过了中间一台域名机子,配置了nginx (基本上所有的超时时间timeout配置项都配置了足够的时间)的proxy_pass到这个IP上。
7891 0
|
测试技术 API 数据库
gRPC Status 状态码枚举类型 介绍文档 (更新 gRPC Status 状态码 实操 代码技巧介绍)
gRPC Status 状态码枚举类型 介绍文档 (更新 gRPC Status 状态码 实操 代码技巧介绍)
556 5
|
存储 Java 关系型数据库
[LDAP: error code 34 - invalid DN]
`亲测可用,之前搜索了很多博客,啥样的都有,就是不介绍报错以及配置用处,根本不懂照抄那些配置是干啥的,稀里糊涂的按照博客搭完也跑不起来,因此记录这个。` `项目背景`:公司项目当前采用http协议+shiro+mysql的登录认证方式,而现在想支持ldap协议认证登录然后能够访问自己公司的项目网站。 `举例说明`:假设我们公司有自己的门户网站,现在我们收购了一家公司,他们数据库采用ldap存储用户数据,那么为了他们账户能登陆我们公司项目所以需要集成,而不是再把他们的账户重新在mysql再创建一遍,万一人家有1W个账户呢,不累死了且也不现实啊。
308 13
[LDAP: error code 34 - invalid DN]
|
机器学习/深度学习 自然语言处理 网络协议
为什么ChatGPT采用SSE协议而不是WebSocket?
在探讨大型语言模型ChatGPT的技术实现时,一个引人注目的细节是其选择使用SSE(Server-Sent Events)协议而非WebSocket来实现数据的实时推送。这一选择背后,蕴含着对技术特性、应用场景及资源效率的深思熟虑。本文将深入探讨ChatGPT为何偏爱SSE,以及这一决策背后的技术逻辑。
1239 3
|
网络协议
HTTP协议中的“X-Real-IP”头字段的作用是什么?底层原理是什么?
HTTP协议中的“X-Real-IP”头字段的作用是什么?底层原理是什么?
10660 93
|
关系型数据库 PostgreSQL
【一文搞懂PGSQL】5. 流复制
PostgreSQL流复制架构支持多种常见配置,包括基本的主从复制、结合PGPool-II的读写分离以及使用repmgr实现高可用性。基础环境中,主节点与备用节点分别位于不同IP。配置涵盖创建复制用户、调整核心参数以支持流复制,并确保归档与日志功能正常工作。从节点需通过备份恢复并配置为待机模式,以实现数据同步。此外,还介绍了如何验证复制状态及手动切换主从节点的方法,以及同步复制参数的配置细节。
|
存储 前端开发 Java
深入解析Java类加载机制:原理、过程与实践
深入解析Java类加载机制:原理、过程与实践
599 2

热门文章

最新文章