公司在做压测的时候发现一个奇怪的现象：QPS 跑到 8000 的时候，接口响应时间有个规律性的毛刺——每隔 15 秒，P99 延迟就会跳一下，从 50ms 飙到 200ms，持续一两秒又恢复正常。查了半天，根因是 Prometheus 来拉指标了。JVM 要遍历所有指标、序列化成文本、再通过网络发出去，这一整套操作每次都要几十毫秒。平时感觉不到，高并发下就成了定时炸弹。 Prometheus 好用，但它的 Pull 模式有个固有的问题：每次抓取，应用程序都要做一遍"遍历指标 → 格式化 → 输出"的全流程。 指标越多、频率越高，这个开销越不可忽略。 为什么 Pull 模式在高频采集下会出问题 Prometheus 默认每 15 秒拉一次指标。对于大多数服务来说，这个频率没啥问题——15 秒一次，每次几十毫秒，感知不到。 但如果你把采集频率调成了 5 秒、甚至 1 秒，或者你的应用里有大量自定义指标（几百个 Counter/Histogram），情况就不一样了。 每次采集，JVM 里发生的事情是： Prometheus 发 GET /metrics 请求 │ ├─ 遍历所有注册的指标（....

做监控系统的同学肯定都遇到过这个问题：Prometheus 内存占用越来越高，监控面板加载越来越慢，最后甚至 OOM 崩溃。排查后发现，罪魁祸首居然是某个接口的 Label 值太多，导致指标基数爆炸。 我之前就遇到过这样一个案例：某个接口返回了用户 ID 作为 Label，结果线上有几百万活跃用户，这个 Label 的取值就有几百万种。单个指标瞬间膨胀到几百万个 time series，Prometheus 的内存和 CPU 直接被打爆。 今天我们就来聊聊 Prometheus 指标基数爆炸的问题，以及如何通过聚合采样方案来解决。 什么是指标基数爆炸？ 1. Prometheus 指标模型回顾 Prometheus 的指标由以下几个部分组成： 指标名称 + Label组合 = 唯一的time series 例如： api_request_total{method="GET", status="200", path="/users"} = 12345 api_request_total{method="POST", status="200", path="/orders"} = 6789....

相信很多小伙伴都有过这样的经历：系统上线后运行一段时间，突然出现性能问题或者业务异常，但是却不知道具体原因，只能凭经验猜测，排查起来既费时又费力。特别是当我们需要监控一些关键业务指标（比如订单量、失败率等）时，传统的系统监控往往无法满足需求。 那么，有没有一种方式能让我们轻松地监控自定义的业务指标，并且实时看到这些指标的变化趋势呢？今天我就跟大家分享一套基于SpringBoot + Micrometer + Prometheus + Grafana的完整监控方案。 为什么需要业务指标监控？ 先来说说我们面临的挑战。传统的系统监控主要关注CPU、内存、磁盘等基础设施指标，虽然这些很重要，但对于业务层面的问题（比如订单成功率下降、支付失败率上升等），我们往往缺乏直观的数据支撑。 业务指标监控能帮助我们： 快速发现业务异常 了解业务发展趋势 为业务决策提供数据支持 实现精细化运营 整体架构设计 我们的监控方案由以下几个组件构成： Micrometer：作为指标收集的抽象层，屏蔽底层监控系统的差异 Spring Boot：提供应用框架和Actuator端点 Prometheus：负责指标....

监控的痛点 在我们的日常工作中，经常会遇到这样的场景： 系统突然变慢，但不知道是哪里出了问题 CPU使用率飙升，却不知道是哪个进程导致的 服务响应时间变长，但没有预警机制 业务指标无法直观展示，领导询问时答不上来 传统的日志查看方式不仅效率低下，还缺乏预警和可视化能力。今天我们就来聊聊如何用Prometheus + Grafana构建一个强大的监控平台。 为什么选择Prometheus + Grafana 相比传统的监控方案，Prometheus + Grafana有以下优势： 开源免费：无需付费，社区活跃 时序数据库：专门针对监控场景优化 强大的查询语言：PromQL功能强大，表达能力强 灵活的可视化：Grafana图表精美，定制性强 生态丰富：大量的exporter和集成 解决方案思路 今天我们要解决的，就是如何用Prometheus + Grafana构建一套完整的监控体系。 核心思路是： 数据采集：使用Prometheus收集各类监控指标 数据存储：时序数据库高效存储监控数据 数据可视化：Grafana提供丰富的图表展示 告警机制：及时发现和处理异常情况 Prome....

线上系统突然变慢，但不知道是哪个服务出了问题？用户投诉接口响应时间长，但排查起来像大海捞针？服务之间调用关系复杂，出了问题根本不知道从哪开始查？ 这就是微服务架构下的监控难题。传统的单体应用监控方式已经无法满足微服务架构的需求。今天我们就来聊聊如何用SpringBoot + SkyWalking + Prometheus构建一个完整的微服务监控体系，实现全链路追踪和性能压测闭环。