Prometheus 监控 Kong 全栈实战API 网关的透明化可观测性Kong 作为云原生 API 网关承载着所有进入微服务集群的南北流量。它的请求吞吐量、上游服务健康、延迟分布、缓存命中率、连接数等指标直接决定了业务 API 的可用性和性能。从 Kong 2.0 版本开始内置的 Prometheus 插件可以无侵入地将所有关键指标以标准格式暴露无需部署额外的 Exporter。本文将带你从启用插件、配置 Prometheus 抓取到解读核心指标、搭建 Grafana 大屏和落地告警规则彻底透视 API 网关层的每一个细节。1. 方案选型原生 Prometheus 插件方案说明Kong Prometheus 插件推荐自 Kong 2.0 起内置启用后自动暴露/metrics端点在管理 API 端口 8001 或自定义端口包含 HTTP、连接、上游、缓存、带宽等维度性能开销极低自定义日志插件 Fluentd/Logstash需额外组件非实时指标不适合告警外部 HTTP 黑盒探测只能判断网关端口可达无法感知内部上游状态、延迟细节本文采用Kong 内置 Prometheus 插件无论你是传统部署、Kubernetes Ingress Controller 还是 KIC都适用。2. 启用 Prometheus 插件2.1 全局启用推荐监控所有服务和路由通过 Kong Admin API默认http://localhost:8001执行curl-XPOST http://localhost:8001/services/\--datanameprometheus-endpoint\--dataurlhttp://localhost:8001# 为全局启用 Prometheus 插件curl-XPOST http://localhost:8001/plugins\--datanameprometheus这将把指标暴露在管理 API 的/metrics路径上。无需关联任何具体 Service 或 Route全局插件会采集所有流量。2.2 使用 Kong 配置文件启用无 DB 模式在kong.conf中添加plugins bundled,prometheus重启 Kong。然后再通过 API 或声明式配置全局启用插件。2.3 验证端点curlhttp://localhost:8001/metrics你应该看到大量以kong_开头的指标例如kong_http_requests_totalkong_bandwidth_byteskong_latency_ms_bucket2.4 安全隔离生产环境中管理端口8001不应直接对外暴露。可以选择在 Kong 中配置admin_listen仅监听127.0.0.1然后用反向代理如 Nginx将/metrics暴露给 Prometheus并添加 Basic Auth。或者使用prometheus插件的配置项自 Kong 3.x 起将指标暴露在独立的监听端口上与 Admin API 分离。3. 配置 Prometheus 抓取scrape_configs:-job_name:kongscrape_interval:15sstatic_configs:-targets:[kong-host:8001]# 或独立端口labels:gateway:api-gatewayenv:production如果管理 API 启用了认证需要在 Prometheus 中配置basic_auth或通过反向代理处理。4. 核心监控指标与 PromQLKong 的 Prometheus 插件暴露的指标以kong_为前缀标签包括service、route、consumer、status_code等。4.1 HTTP 请求与响应指标含义kong_http_requests_total接收到的 HTTP 请求总数Counter按service、route、consumer、status_code分组kong_kong_latency_ms(Histogram)Kong 内部处理延迟从收到请求到转发给上游的时间kong_upstream_latency_ms(Histogram)上游服务响应时间kong_request_latency_ms(Histogram)总请求延迟 Kong 延迟 上游延迟PromQL 示例整体 QPSsum(rate(kong_http_requests_total[1m]))按状态码的 5xx 错误率sum(rate(kong_http_requests_total{status_code~5..}[5m])) / sum(rate(kong_http_requests_total[5m]))上游服务 P95 延迟histogram_quantile(0.95, rate(kong_upstream_latency_ms_bucket[5m]))Kong 自身处理延迟 P99histogram_quantile(0.99, rate(kong_kong_latency_ms_bucket[5m]))4.2 连接数指标含义kong_connections_active活跃客户端连接数kong_connections_reading正在读请求的连接数kong_connections_writing正在写响应的连接数kong_connections_waiting长连接保持等待的连接数可类比 Nginx 的连接指标监控连接风暴。4.3 上游健康与状态指标含义kong_upstream_target_health上游目标健康状态1健康0不健康kong_bandwidth_bytes接收和发送的字节数Counter告警上游不健康kong_upstream_target_health 04.4 缓存与限流如果使用了相应插件指标含义kong_cache_hit_total/kong_cache_miss_total缓存命中/未命中次数kong_rate_limiting_limit_total限流触发计数5. Grafana 仪表盘推荐Kong Official DashboardDashboard ID7424最经典完美适配 Kong Prometheus 插件展示 QPS、延迟、带宽、上游健康、连接数等。Kong Gateway MetricsID11765更现代适合 Kong 2.x/3.xKong Ingress Controller若在 Kubernetes 中使用 KIC可导入 ID13257。导入后选择 Prometheus 数据源通过gateway标签过滤 Kong 实例。6. 告警规则实战groups:-name:kong_alertsrules:-alert:KongDownexpr:up{jobkong} 0for:1mlabels:severity:criticalannotations:summary:Kong 网关实例 {{ $labels.instance }} 不可达-alert:KongHigh5xxRateexpr:sum(rate(kong_http_requests_total{status_code~5..}[5m])) by (gateway) / sum(rate(kong_http_requests_total[5m])) by (gateway)0.01for:5mlabels:severity:criticalannotations:summary:Kong 网关 5xx 错误率超过 1%-alert:KongUpstreamUnhealthyexpr:kong_upstream_target_health 0for:2mlabels:severity:criticalannotations:summary:Kong 上游目标 {{ $labels.upstream }} 变为不健康状态-alert:KongHighUpstreamLatencyexpr:histogram_quantile(0.99,rate(kong_upstream_latency_ms_bucket[5m]))2000for:5mlabels:severity:warningannotations:summary:上游服务 P99 延迟超过 2000ms-alert:KongHighConnectionCountexpr:kong_connections_active10000for:5mlabels:severity:warningannotations:summary:Kong 活跃连接数超过 10000-alert:KongCacheHitRateLowexpr:rate(kong_cache_hit_total[5m]) / (rate(kong_cache_hit_total[5m]) rate(kong_cache_miss_total[5m])) 0.5for:10mlabels:severity:warningannotations:summary:Kong 缓存命中率低于 50%根据网关流量规模调整阈值。7. 进阶多节点、Kubernetes 与安全7.1 监控多个 Kong 节点每个 Kong 节点如集群中的多个 Pod 或传统多实例都需被 Prometheus 抓取。使用file_sd或 Kubernetes Pod Annotations 自动发现。7.2 Kubernetes 中的 Kong Ingress Controller (KIC)KIC 默认启用 Prometheus 插件同样暴露/metrics在 admin 端口通常为 8100。可使用 Prometheus Operator 的 ServiceMonitor 自动抓取。7.3 独立指标端口在 Kong 3.x 中可以通过kong.conf设置prometheus_metrics on和prometheus_metrics_listen 0.0.0.0:9543将指标端口与 admin 分离既安全又方便。7.4 安全加固永远不要将 Kong Admin API 暴露到公网。使用防火墙或 NetworkPolicy 限制访问 8001/9543 端口的 IP 仅为 Prometheus 服务器。如果通过 Admin API 暴露指标可在 Nginx 反代层添加 Basic Auth并在 Prometheus 配置basic_auth。7.5 自定义业务指标Kong 的 Prometheus 插件还支持通过per_consumer true标签暴露消费者级别的指标。如果需要在网关层采集业务独有的指标如 API 版本分布可以开发自定义插件利用 Prometheus Lua 库或新增 metric。8. 总结通过 Kong 原生的 Prometheus 插件API 网关不再是流量的“黑洞”。从全局 QPS 到每个上游的延迟从连接数波动到缓存效率所有关键信号都实时汇聚于 Prometheus在 Grafana 上可视化并通过 Alertmanager 发出告警。无论你是单个网关实例还是大规模的 Kubernetes Ingress 集群这套方案都能让边缘层的可观测性与应用层无缝衔接真正实现从客户端到数据库的端到端透明监控。