首页
/ Apache APISIX 3.12版本Prometheus监控指标缺失问题分析

Apache APISIX 3.12版本Prometheus监控指标缺失问题分析

2025-05-15 16:23:43作者:董宙帆

Apache APISIX作为一款高性能的云原生API网关,其内置的Prometheus插件为运维人员提供了丰富的监控指标。然而在3.12版本中,部分关键指标如http_status、http_latency和upstream_status等出现缺失情况,这对系统监控造成了影响。

问题现象

在APISIX 3.12版本中,通过访问Prometheus暴露的/metrics接口,运维人员发现缺少了几个重要的监控指标:

  • apisix_http_status:HTTP状态码统计指标
  • apisix_http_latency:请求延迟指标
  • apisix_upstream_status:上游服务状态指标

这些指标的缺失使得运维人员无法全面监控API网关的运行状态,特别是无法获取HTTP请求的成功率、响应时间分布以及后端服务健康状态等关键信息。

问题根源

经过深入分析,发现问题出在Prometheus插件的配置上。在默认配置中,这些指标被设置了expire参数,值为600秒。这个参数实际上会导致指标在600秒后过期并被清除,从而造成监控系统中这些指标的缺失。

Prometheus插件配置示例如下:

pluginAttrs:
  prometheus:
    export_uri: /apisix/prometheus/metrics
    metric_prefix: apisix_
    default_buckets:
      - 50
      - 100
      - 500
      - 1000
      - 5000
    metrics:
      http_status:
        expire: 600
      http_latency:
        expire: 600
      bandwidth:
        expire: 600
      upstream_status:
        expire: 600

解决方案

解决这个问题的方法很简单:只需从配置中移除这些指标的expire参数即可。修改后的配置如下:

pluginAttrs:
  prometheus:
    export_uri: /apisix/prometheus/metrics
    metric_prefix: apisix_
    default_buckets:
      - 50
      - 100
      - 500
      - 1000
      - 5000

移除expire参数后,所有监控指标将保持持久化,不再会因为过期而被清除。这样就能确保Prometheus能够持续收集到完整的监控数据。

技术原理

在APISIX的Prometheus插件实现中,expire参数控制着指标在内存中的保留时间。当设置了expire参数后,指标会在指定时间后被自动清理,这是为了节省内存资源而设计的机制。然而对于监控系统来说,大多数情况下我们希望指标能够长期保留,由Prometheus服务器本身来决定数据的保留策略。

APISIX的Prometheus插件基于nginx-lua-prometheus库实现,该库默认情况下指标是持久化的。只有当显式设置了expire参数时,才会启用过期清理机制。因此,移除这些expire参数可以让指标恢复默认的持久化行为。

最佳实践

对于生产环境中的APISIX部署,建议:

  1. 避免为关键监控指标设置expire参数,确保监控数据的连续性
  2. 对于确实需要定期清理的指标,应该设置合理的expire时间
  3. 定期检查/metrics接口的输出,确保所有需要的指标都能正常获取
  4. 结合Grafana等可视化工具,建立完整的监控告警体系

总结

APISIX 3.12版本中Prometheus监控指标缺失的问题,通过简单的配置调整即可解决。这个案例也提醒我们,在使用开源组件时,需要仔细理解各项配置参数的含义和影响,特别是与监控相关的配置,确保它们符合我们的运维需求。同时,建立完善的监控检查机制,能够及时发现并解决类似问题,保障系统的可靠运行。

登录后查看全文
热门项目推荐
相关项目推荐

项目优选

收起
kernelkernel
deepin linux kernel
C
22
6
docsdocs
OpenHarmony documentation | OpenHarmony开发者文档
Dockerfile
165
2.05 K
nop-entropynop-entropy
Nop Platform 2.0是基于可逆计算理论实现的采用面向语言编程范式的新一代低代码开发平台,包含基于全新原理从零开始研发的GraphQL引擎、ORM引擎、工作流引擎、报表引擎、规则引擎、批处理引引擎等完整设计。nop-entropy是它的后端部分,采用java语言实现,可选择集成Spring框架或者Quarkus框架。中小企业可以免费商用
Java
8
0
RuoYi-Vue3RuoYi-Vue3
🎉 (RuoYi)官方仓库 基于SpringBoot,Spring Security,JWT,Vue3 & Vite、Element Plus 的前后端分离权限管理系统
Vue
954
563
leetcodeleetcode
🔥LeetCode solutions in any programming language | 多种编程语言实现 LeetCode、《剑指 Offer(第 2 版)》、《程序员面试金典(第 6 版)》题解
Java
60
16
apintoapinto
基于golang开发的网关。具有各种插件,可以自行扩展,即插即用。此外,它可以快速帮助企业管理API服务,提高API服务的稳定性和安全性。
Go
22
0
giteagitea
喝着茶写代码!最易用的自托管一站式代码托管平台,包含Git托管,代码审查,团队协作,软件包和CI/CD。
Go
17
0
HarmonyOS-ExamplesHarmonyOS-Examples
本仓将收集和展示仓颉鸿蒙应用示例代码,欢迎大家投稿,在仓颉鸿蒙社区展现你的妙趣设计!
Cangjie
408
387
金融AI编程实战金融AI编程实战
为非计算机科班出身 (例如财经类高校金融学院) 同学量身定制,新手友好,让学生以亲身实践开源开发的方式,学会使用计算机自动化自己的科研/创新工作。案例以量化投资为主线,涉及 Bash、Python、SQL、BI、AI 等全技术栈,培养面向未来的数智化人才 (如数据工程师、数据分析师、数据科学家、数据决策者、量化投资人)。
Python
77
71
rainbondrainbond
无需学习 Kubernetes 的容器平台,在 Kubernetes 上构建、部署、组装和管理应用,无需 K8s 专业知识,全流程图形化管理
Go
14
1