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/\--dataname=prometheus-endpoint\--dataurl=http://localhost:8001# 为全局启用 Prometheus 插件curl-XPOST http://localhost:8001/plugins\--data"name=prometheus"这将把指标暴露在管理 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_bucket
2.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:'kong'scrape_interval:15sstatic_configs:-targets:['kong-host:8001']# 或独立端口labels:gateway:'api-gateway'env:'production'如果管理 API 启用了认证，需要在 Prometheus 中配置basic_auth，或通过反向代理处理。
4. 核心监控指标与 PromQL
Kong 的 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 示例：
- 整体 QPS：
sum(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 自身处理延迟 P99：
histogram_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 == 0
4.4 缓存与限流（如果使用了相应插件）
| 指标 | 含义 |
|---|---|
kong_cache_hit_total/kong_cache_miss_total | 缓存命中/未命中次数 |
kong_rate_limiting_limit_total | 限流触发计数 |
5. Grafana 仪表盘推荐
- Kong Official Dashboard：Dashboard ID7424（最经典），完美适配 Kong Prometheus 插件，展示 QPS、延迟、带宽、上游健康、连接数等。
- Kong Gateway Metrics：ID11765（更现代，适合 Kong 2.x/3.x）
- Kong Ingress Controller：若在 Kubernetes 中使用 KIC，可导入 ID13257。
导入后选择 Prometheus 数据源，通过gateway标签过滤 Kong 实例。
6. 告警规则实战
groups:-name:kong_alertsrules:-alert:KongDownexpr:up{job="kong"}== 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_active>10000for: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 集群，这套方案都能让边缘层的可观测性与应用层无缝衔接，真正实现从客户端到数据库的端到端透明监控。
