API网关后端LLM 网关微服务人工智能【免费下载链接】kong The API and AI Gateway项目地址https://gitcode.com/GitHub_Trending/ko/kong点击查看免费下载本文围绕 Kong 仓库中 Prometheus 插件的官方 Grafana 集成文件展开kong/plugins/prometheus/grafana/目录下的README.md说明了仪表盘的身份与维护约定而kong-official.json则是一份可直接导入 Grafana 的完整仪表盘定义对应 Grafana 社区仪表盘库中的 ID 7424。读完本文你将掌握如何把该仪表盘导入自己的 Grafana、理解其六大面板区的每个查询背后的 PromQL 逻辑并弄清这些指标在 Kong 插件源码exporter.lua、schema.lua中的真实来源与启用条件。一、这份集成文件是什么README 核心事实kong/plugins/prometheus/grafana/README.md全文虽短却交代了三件关键事实kong-official.json是官方仪表盘的“源文件”它是 Kong 官方发布在 Grafana Labs 仪表盘库ID 为7424上的仪表盘的本体定义仪表盘名称为 “Kong (official)”。仓库副本与线上副本必须保持同步README 明确要求“本仓库中的这份拷贝与 Grafana Labs 上的拷贝应当保持同步”。同步目前靠人工完成如果在本仓库修改了仪表盘需要登录 Grafana Labs 重新上传新版本反之亦然。这是当前截至本仓库现状唯一约定的维护方式。换句话说想了解 Kong 官方“开箱即用”的监控视图长什么样、有哪些查询、为什么这么写直接读kong-official.json就是最权威的入口。以下各节全部基于该文件的真实内容展开。二、仪表盘元信息与导入前准备2.1 仪表盘核心元信息来自 kong-official.json字段值说明titleKong (official)导入后显示的仪表盘名称uidmY9p7dQmz唯一标识可据此引用或做链接gnetId7424对应 Grafana 仪表盘库中的 IDversion9仪表盘 schema 版本timefrom: now-15m, to: now默认时间范围导入后可在时间选择器调整__requires.grafana8.4.5声明所需 Grafana 最低版本所需面板类型gauge、graph、heatmap、singlestat、table、timeseries老版本面板已随 Grafana 8.x 迁移为 timeseries导入新版 Grafana 时通常可自动兼容所需数据源prometheus插件版本1.0.0面板中统一通过${DS_PROMETHEUS}变量引用文件头部__inputs声明了一个名为DS_PROMETHEUS的 datasource 输入这也是导入向导中“选择数据源”那一屏对应的变量。description字段写明其用途“Dashboard that graphs metrics exported via Prometheus plugin in Kong”即专门可视化 Kong Prometheus 插件导出的指标。2.2 导入步骤确保 Kong 已启用prometheus插件见第五节配置开关并让 Prometheus 成功抓取 Kong 的/metrics端点Status API 或 Admin API 均可见第四节。在 Grafana 中进入Dashboards → New → Import或从搜索面板选择 Import dashboard。选择“Upload dashboard JSON file”上传本仓库的 kong-official.json也可以直接复制文件内容粘贴到 “Import via panel json”。在导入界面为DS_PROMETHEUS选择已配置好的 Prometheus 数据源。点击 Import仪表盘即加载完成默认时间范围now-15m会立刻展示近 15 分钟数据。提示若某个面板长期空白优先检查对应指标的插件开关是否开启第五节因为本仪表盘的大部分请求/延迟/带宽面板依赖插件显式开启status_code_metrics、latency_metrics、bandwidth_metrics等开关默认均为关闭。三、仪表盘面板结构与查询逻辑核心章节kong-official.json共约 3400 行面板按“行row”组织共六大区块Request rate请求速率、Latencies延迟、Bandwidth带宽、Caching缓存/内存、Upstream上游健康、Nginx连接状态。每个区块默认折叠collapsed: true点击行标题展开。下面逐一拆解其查询与设计意图。3.1 Request rate请求速率区块面板PromQL 查询含义Total requests per second (RPS)sum(rate(kong_http_requests_total{instance~$instance}[1m]))全实例每秒请求数RPS per route/servicesum(rate(kong_http_requests_total{service~$service,route~$route,instance~$instance}[1m])) by (service)与by (route)两条序列按服务、按路由拆分的 RPSRPS per route/service by status codesum(...) by (service,code)与by (route,code)带状态码维度的 RPS用于观察错误率分布关键点指标kong_http_requests_total的标签集合为service, route, code, source, workspace, consumer见 exporter.lua。source取值为service或kong代表状态码来自上游响应还是 Kong 自身——官方测试中也验证了sourceservice与sourcekong两种序列见 02-access_spec.lua。该指标是counter因此必须用rate()/irate()计算速率面板统一使用rate(...,[1m])即 1 分钟窗口的平均速率。instance~$instance中的instance标签并非插件产出而是 Prometheus 抓取目标时自动附加的地址标签ip:port配合模板变量实现多节点筛选。3.2 Latencies延迟区块延迟区块同时绘制三组直方图每组都给出p90 / p95 / p99三个分位数曲线面板组指标PromQL 模板含义Kong Proxy Latency全部/按服务/按路由kong_kong_latency_mshistogram_quantile(0.95, sum(rate(kong_kong_latency_ms_bucket{...}[1m])) by (le))Kong 自身及启用插件引入的延迟kong.latencies.kongRequest Time全部/按服务/按路由kong_request_latency_ms同上针对request_latency_ms完整请求总延迟kong.latencies.requestUpstream time全部/按服务/按路由kong_upstream_latency_ms同上针对upstream_latency_ms上游响应时间kong.latencies.proxy实现佐证在 exporter.lua 中定义了三种直方图桶KONG_LATENCY_BUCKETS {1, 2, 5, 7, 10, 15, 20, 30, 50, 75, 100, 200, 500, 750, 1000, 3000, 6000}毫秒——用于kong_latency_msUPSTREAM_LATENCY_BUCKETS {25, 50, 80, 100, 250, 400, 700, 1000, 2000, 5000, 10000, 30000, 60000}——用于upstream_latency_ms与request_latency_ms。写入逻辑位于 exporter.luaserialized.latencies.request记入total_latencyserialized.latencies.proxy记入upstream_latencyserialized.latencies.kong记入kong_latency三者均为observe()直方图观测。面板正是利用这些_bucket序列 histogram_quantile还原分位数属于标准的 Prometheus 直方图分位数计算范式。3.3 Bandwidth带宽区块面板PromQL 查询含义Total Bandwidthsum(irate(kong_bandwidth_bytes{instance~$instance}[1m])) by (type)按方向ingress/egress汇总的每秒吞吐Egress per service/routesum(irate(kong_bandwidth_bytes{directionegress, ...}[1m])) by (service)与by (route)出站流量按服务/路由拆分Ingress per service/routesum(irate(kong_bandwidth_bytes{directioningress, service~$service}[1m])) by (service)入站流量按服务拆分实现佐证exporter.lua 中bandwidth_bytes的标签为service, route, direction, workspace, consumerHTTP 子系统含 consumerstream 子系统不含。写入时exporter.lua取serialized.ingress_size与serialized.egress_size分别以directioningress/egress递增计数。由于是字节累计量面板使用irate(...[1m])计算瞬时每秒速率。3.4 Caching缓存/内存区块面板PromQL 查询含义Kong shared memory usage by Node(kong_memory_lua_shared_dict_bytes{instance~$instance}/kong_memory_lua_shared_dict_total_bytes{instance~$instance})*100各 shared dict 的占用百分比gauge0–100%含 70% 黄 / 90% 红阈值并按instance变量垂直重复生成每个节点的仪表Kong worker Lua VM usage by Nodekong_memory_workers_lua_vms_bytes{instance~$instance}每个 worker 进程的 Lua VM 分配字节数实现佐证这两个指标在 exporter.lua 定义标签含node_id, shared_dict, kong_subsystem或node_id, pid, kong_subsystem并在每次抓取时通过kong.node.get_memory_stats()刷新exporter.lua。它们是gauge类型无需 rate。面板用百分比形式展示 shared dict 容量水位可直接作为 Nginx/LuaJIT 内存压力告警依据。3.5 Upstream上游健康区块面板PromQL 查询含义Healthy statusheatmapsum(kong_upstream_target_health{statehealthy,...}) by (upstream,target,address) * -1 sum(kong_upstream_target_health{state~(unhealthy|dns_error),...}) by (upstream,target,address)将健康状态映射为数值healthy 为 -1、unhealthy/dns_error 为正形成热力图健康状态表格同一指标 label_replace三次映射为state_valuehealthy1、healthchecks_off0、unhealthy/dns_error-1表格列出每个 upstream/target/address 的状态颜色映射1healthy绿、0healthchecks_off黄、-1unhealthy红实现佐证kong_upstream_target_health的 state 取值共四种——healthchecks_off、healthy、unhealthy、dns_error定义在 exporter.lua。抓取时exporter.lua通过balancer.get_upstream_health()拉取每个 upstream 的 target 健康信息先reset()旧值再写入避免暴露过期状态并且只有upstream_health_metrics开关开启且在传统模式非 control_plane下才导出。长循环中还调用kong.tools.yield.yield()主动让出执行权避免抓取拖慢代理请求。heatmap 面板的 y 轴即{{upstream}}:{{target}}可直观看到某 target 何时变红。3.6 Nginx连接状态区块面板PromQL 查询含义Nginx connection statesum(kong_nginx_connections_total{state~active|reading|writing|waiting, instance~$instance}) by (state)活跃连接按 reading/writing/waiting 等状态拆分Total Connectionssum(kong_nginx_connections_total{statetotal, ...})已处理的总请求连接数Handled Connectionssum(...{statehandled, ...})已处理连接数Accepted Connectionssum(...{stateaccepted, ...})已接受连接数实现佐证kong_nginx_connections_total定义于 exporter.lua标签为node_id, subsystem, state每次抓取时通过kong.nginx.get_statistics()将connections_accepted/handled/total/active/reading/writing/waiting写入exporter.lua。该区块属于基础指标无需任何插件开关即默认导出。四、模板变量多实例、多服务、多路由的动态筛选templating.list定义了 5 个变量全部基于 Prometheuslabel_values()动态获取可多选multi: true且支持 “All”includeAll: trueallValue: .*变量定义查询用途$servicelabel_values(kong_http_requests_total, service)筛选服务按名称排序随时间范围刷新$routelabel_values(kong_http_requests_total, route)筛选路由描述注明 “Ingress”$instancelabel_values(kong_nginx_connections_total, instance)筛选 Kong 节点实例地址标签来自 Prometheus 抓取配置refresh: 2表示随查询时间范围变化刷新$upstreamlabel_values(kong_upstream_target_health, upstream)筛选上游驱动 Upstream 区块$DS_PROMETHEUSdatasource 类型变量query: prometheus导入时绑定数据源面板查询中统一以service~$service、route~$route、instance~$instance、upstream~$upstream形式引用。由于allValue为.*选择 “All” 时正则退化为匹配一切实现全局视角多选时则叠加多个取值。这是该仪表盘能同时服务“单节点排查”与“集群总览”的关键机制。五、让面板数据“动起来”的插件配置开关仪表盘中的大部分面板依赖 Kongprometheus插件在config中显式开启的开关。完整字段定义见 schema.lua全部默认关闭配置项默认值作用影响的仪表盘面板per_consumerfalse是否收集按消费者维度的指标开启后kong_http_requests_total、kong_bandwidth_bytes会填充consumer标签请求速率、带宽面板可按 consumer 下钻status_code_metricsfalse是否导出状态码指标kong_http_requests_totalHTTP/kong_stream_sessions_totalstreamRequest rate 区块全部面板latency_metricsfalse是否导出kong_latency_ms、kong_request_latency_ms、kong_upstream_latency_msLatencies 区块全部面板bandwidth_metricsfalse是否导出kong_bandwidth_bytesBandwidth 区块全部面板upstream_health_metricsfalse是否导出kong_upstream_target_health传统模式或数据面Upstream 区块面板ai_metricsfalse是否导出kong_ai_llm_requests_total、kong_ai_llm_cost_total、kong_ai_llm_tokens_total等 AI 指标官方仪表盘未消费供自建面板使用wasm_metricsfalse是否导出 Wasm 相关指标供自建面板使用注意status_code_metrics是 RPS 面板的数据开关——handler.lua 中只有在该开关为真时才填充serialized.status_code而 exporter.lua 只有看到serialized.status_code才会递增kong_http_requests_total。同理延迟、带宽面板分别受latency_metrics、bandwidth_metrics控制。若只启用插件而未开任何开关则只有 Caching、Nginx 等基础指标可看。要使官方仪表盘完整出数一份最小化的插件配置可以是# declarative 配置示例或通过 Admin API / Kong Manager 配置 plugins: - name: prometheus config: per_consumer: true status_code_metrics: true latency_metrics: true bandwidth_metrics: true upstream_health_metrics: true ai_metrics: false wasm_metrics: false另外schema.lua 内置了custom_validator若 Nginx 模板中不存在prometheus_metrics共享字典插件配置会被校验拒绝报错ngx shared dict prometheus_metrics not found。Kong 默认模板会注入该 shared dict因此常规部署无需处理相关行为在 02-access_spec.lua 有专门的单元测试覆盖。细粒度开关的正确性同样有测试背书02-access_spec.lua 中的granular_metrics_set将status_code_metrics → http_requests_total、latency_metrics → kong_latency_ms、bandwidth_metrics → bandwidth_bytes、upstream_health_metrics → upstream_target_health一一对应逐一验证“开关关闭时对应指标不出现、开启时出现”这正是理解面板与开关依赖关系的最佳实证。六、数据链路从请求到仪表盘的完整闭环理解面板后值得顺带掌握其背后的采集链路全部可在本仓库源码中追溯写入log 阶段每个代理请求结束时handler.lua 在log钩子中调用kong.log.serialize()按开关组装serialized数据交给 exporter.lua 的log()递增/观测对应指标。存储性能设计prometheus.lua 使用单个prometheus_metrics共享字典跨 worker 存储指标同时每个 worker 进程内维护独立计数器定期刷入共享字典避免每次计数都锁共享内存。其结果是计数器呈“最终一致”——最多延迟一个同步间隔默认 1 秒才可见。直方图桶的le标签在内部按字典序排列存储输出前还原为规范浮点格式与Inf。抓取/metrics 端点HTTP 子系统通过 Status API 或 Admin API 的/metrics路由暴露status_api.lua 与 api.lua 均注册GET /metrics调用exporter.collect()exporter.lua在抓取瞬间刷新连接数、内存、上游健康、数据面状态等 gauge 型指标并输出全部序列若配置了 stream 监听还会通过 stream API 合并 stream 子系统指标。Prometheus 抓取后由 Grafana 的${DS_PROMETHEUS}数据源读取经第三节的 PromQL 渲染成面板。七、版本同步与贡献约定回到 README.md 的核心维护约定本仓库的kong-official.json与 Grafana Labs 仪表盘库上的 7424 号仪表盘是同一份仪表盘的两个副本目前同步是纯人工流程修改本仓库副本后需要登录 Grafana Labs 上传新版本反之在线上修改后也要回写到本仓库因此贡献者若改动该 JSON应同时更新两个位置保持两者内容一致避免“仓库新、线上旧”或反之的漂移。这也解释了为何该文件保留了gnetId: 7424、iteration迭代时间戳等元字段——它们正是线上仪表盘版本管理的遗留标识。结语Kong 官方 Grafana 仪表盘并非简单的“看图工具”而是一份围绕kong_前缀指标族精心设计的查询模板它以rate/irate处理计数器、以histogram_quantile还原直方图分位数、以label_values实现动态过滤、以数值映射呈现健康状态几乎覆盖了 Prometheus 查询的最佳实践。搭配 schema.lua 中的细粒度开关、exporter.lua 中的指标定义与 02-access_spec.lua 的测试验证你可以放心地将其作为生产环境 Kong 可观测性的起点并在此基础上扩展 AI 指标、Wasm 指标等官方仪表盘尚未消费的新维度。赞分享API网关后端LLM 网关微服务人工智能【免费下载链接】kong The API and AI Gateway项目地址https://gitcode.com/GitHub_Trending/ko/kong点击查看免费下载相关推荐Apache Pulsar 监控指南Grafana 官方仪表盘与 Prometheus 指标解析Apache Pulsar 监控指南Grafana 官方仪表盘与 Prometheus 指标解析 导读 本指南基于 Apache Pulsar 仓库中 gra消息队列后端Linkerd 2 接入 Grafana官方 Helm 配置、仪表盘导入与权限治理实战指南Linkerd 2 接入 Grafana官方 Helm 配置、仪表盘导入与权限治理实战指南 本篇技术指南围绕 Linkerd 2 仓库中的 grafana/服务网格云原生可观测性LX Music 使用指南改 3 处设置多平台一首歌一次搜全LX Music 使用指南改 3 处设置多平台一首歌一次搜全 你的歌散在酷我、酷狗、QQ 音乐、网易云、咪咕几个 App 里切歌等于切软件整理好的歌单桌面应用音视频前端上一篇让老款Mac重获新生OpenCore Legacy Patcher完整指南下一篇PythonRobotics 动态窗口法Dynamic Window Approach实现解析2D 移动机器人局部避障与轨迹规划实战创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考