1. 从零搭建一套能用的Metrics监控我踩过的坑和最终方案监控这件事很多团队都是等到线上出了事故才开始重视。我经历过一次典型的场景某个服务响应时间突然从200ms飙到3s用户投诉涌进来但我们花了将近40分钟才定位到是数据库连接池被打满。那40分钟里我们只有零散的日志没有任何系统性的指标数据可以看。这件事之后我开始认真研究Metrics监控工具从最基础的计数器到完整的可视化告警链路前后折腾了大半年踩了不少坑也总结了一套还算靠谱的方案。这篇文章主要面向两类人一是刚接触Metrics监控、不知道从哪下手的开发者二是已经在用一些监控工具、但感觉数据不够用或者告警太吵的团队。我会从核心概念讲起把选型逻辑、部署实操、指标设计、告警配置、问题排查这几个环节都拆开说清楚。每个部分我都会解释“为什么这么做”而不只是“怎么做”。读完你至少能搭出一套覆盖主机、应用、中间件的监控体系并且知道哪些指标值得看、哪些告警该关掉。Metrics监控的本质就是把系统运行时的各种状态用数字记录下来再通过这些数字的变化趋势判断系统是否健康。听起来简单但实际操作中指标选多了噪音大选少了漏问题采集频率高了存储扛不住低了又看不到毛刺。这些取舍才是真正花时间的地方。下面我按自己的实践顺序一步步展开。2. 监控体系的核心设计与选型逻辑2.1 为什么是Metrics而不是Logs或Traces可观测性领域有三个支柱Metrics、Logs、Traces。很多人一开始会混淆它们的定位。我用一个生活化的类比来解释Metrics就像你家里的电表和水表每隔几秒记录一次读数告诉你“现在用了多少”Logs像日记本记录每一件具体发生的事Traces像快递追踪告诉你一个请求从下单到签收经过了哪些环节。Metrics最大的优势是聚合性和低成本。一条时间序列数据点通常只有几十字节即使每秒采集一万个指标一天的存储量也在可控范围内。而同样规模的日志存储成本可能是指标数据的几十倍。更重要的是Metrics天然适合做趋势分析和告警——你不需要逐条读日志只需要看一个数值是否超过了阈值。但这不意味着Metrics能替代Logs和Traces。我的经验是Metrics负责发现异常Logs负责定位原因Traces负责分析链路。三者配合使用效果最好但如果资源有限Metrics应该是第一个建的。2.2 拉模式与推模式的选择Metrics采集有两种基本模式Pull拉和Push推。Pull模式是监控服务端定期去目标端拉取指标Prometheus是典型代表Push模式是目标端主动把指标推送到服务端Graphite、InfluxDB的某些用法属于这一类。我最初用的是Push模式因为觉得“主动上报”更直观。但实际跑下来发现几个问题一是目标端需要知道服务端地址配置耦合度高二是网络抖动时容易丢数据三是很难判断一个实例是“挂了”还是“只是没数据上报”。后来切换到Pull模式这些问题基本都解决了——服务端配置目标列表定期抓取如果抓不到就说明实例可能有问题告警逻辑非常清晰。Pull模式还有一个好处是服务发现。在容器化环境里实例的IP和端口经常变化Pull模式可以配合服务发现机制自动感知新实例不需要手动维护目标列表。当然Pull模式也有缺点比如短生命周期任务跑几秒就结束的Job可能来不及被抓取这时候需要用Pushgateway做中转。2.3 存储引擎的取舍Metrics数据是典型的时间序列数据每个数据点包含时间戳、指标名、标签和值。传统关系型数据库在这种场景下性能很差因为写入量大、查询模式固定按时间范围聚合。所以基本上都会选择专门的时间序列数据库TSDB。我实际用过的方案有三种Prometheus自带的本地TSDB、InfluxDB、以及基于对象存储的远程存储。Prometheus本地TSDB的优点是部署简单、查询语言强大PromQL缺点是单机存储容量有限长期数据需要做远程存储。InfluxDB在写入性能上表现不错但集群版是商业产品开源版只支持单机。远程存储方案适合数据量特别大的场景但架构复杂度高小团队不太建议一开始就上。我的建议是起步阶段直接用Prometheus本地存储保留15到30天数据。这个周期足够覆盖大部分故障回溯需求。等数据量真的上来了再考虑接远程存储。不要一上来就搞一套复杂的存储架构维护成本会吃掉你大量精力。2.4 指标类型的选择与语义Metrics有四种基本类型Counter计数器、Gauge仪表盘、Histogram直方图、Summary摘要。很多人会混用导致后期查询时发现数据没法用。Counter是只增不减的适合记录请求总数、错误总数这类累计值。Gauge可以增可以减适合记录当前内存使用量、在线用户数这类瞬时值。Histogram和Summary都用于记录分布数据比如请求延迟但Histogram可以在服务端做分位数计算Summary在客户端计算。我一般优先用Histogram因为它的分位数可以在查询时灵活调整而Summary的分位数在采集时就固定了。这里有个容易踩的坑不要用Gauge记录累计值。我见过有人用Gauge记录请求总数结果服务重启后数值归零导致增长率计算出错。累计值一定要用Counter配合rate()函数计算增长率。3. 核心组件部署与实操配置3.1 Prometheus服务端部署要点Prometheus的部署本身不复杂下载二进制包解压就能跑。但生产环境需要考虑几个关键配置。首先是数据保留时间通过--storage.tsdb.retention.time参数控制默认15天。如果磁盘空间有限可以调小到7天。其次是抓取间隔全局默认scrape_interval设为15秒比较均衡太短会增加存储压力太长会漏掉瞬时峰值。配置文件prometheus.yml是核心结构分为global、scrape_configs、alerting、rule_files几个部分。global里设置抓取间隔和超时时间scrape_configs定义抓取目标rule_files加载告警规则文件。我建议把告警规则单独放在rules/目录下按业务模块拆分文件方便管理。global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: node static_configs: - targets: [localhost:9100] - job_name: app metrics_path: /actuator/prometheus static_configs: - targets: [localhost:8080]注意evaluation_interval控制告警规则的评估频率不要设得比scrape_interval还小否则会出现数据还没采集到就开始评估的情况。3.2 主机指标采集Node ExporterNode Exporter是采集主机指标的标准组件部署在每台被监控的机器上。它暴露的指标非常全面包括CPU、内存、磁盘、网络、文件系统等。启动方式很简单下载二进制后直接运行默认监听9100端口。但默认配置下有些指标采集不到比如磁盘IO的详细数据需要挂载/proc和/sys。如果用Docker部署需要加上--path.procfs和--path.sysfs参数。另外Node Exporter默认会采集很多用不到的指标可以通过--collector.disable-defaults配合--collector.xxx按需开启减少数据量。我实际关注的主机指标有这几个node_cpu_seconds_totalCPU使用率、node_memory_MemAvailable_bytes可用内存、node_filesystem_avail_bytes磁盘剩余空间、node_network_receive_bytes_total网络接收流量。这几个指标基本能覆盖80%的主机异常场景。3.3 应用指标暴露埋点与SDK选择应用层的指标需要自己在代码里埋点。主流语言都有对应的客户端库比如Java的Micrometer、Go的prometheus/client_golang、Python的prometheus_client。这些库的使用方式大同小异注册指标、在关键路径上打点、通过HTTP端点暴露。以Java应用为例如果用的是Spring Boot引入Micrometer和Prometheus的依赖后很多指标会自动采集包括JVM内存、GC次数、HTTP请求延迟等。自定义指标只需要注入MeterRegistry然后创建Counter或Timer。Autowired private MeterRegistry registry; public void handleRequest() { Timer.Sample sample Timer.start(registry); try { // 业务逻辑 } finally { sample.stop(registry.timer(request.duration, method, handleRequest)); } }提示指标标签的基数Cardinality要严格控制。不要用用户ID、请求ID这种高基数标签否则时间序列数量会爆炸Prometheus内存会被吃光。标签值应该是有限的枚举集合比如状态码、方法名、实例名。3.4 可视化面板Grafana接入Prometheus自带的Web UI只能做简单查询真正好用的可视化要靠Grafana。Grafana接入Prometheus很简单在数据源配置里填上Prometheus地址即可。然后就是建Dashboard把关键指标用图表展示出来。我一般会建三个层次的Dashboard概览层展示核心健康指标请求量、错误率、延迟P99主机层展示CPU、内存、磁盘、网络应用层展示JVM、连接池、缓存命中率等。每个Dashboard控制在6到8个图表太多会让人抓不住重点。Grafana的变量功能很实用可以定义instance、job等变量在一个Dashboard里切换查看不同实例的数据。告警也可以直接在Grafana里配但我的习惯是告警规则统一放在Prometheus里管理Grafana只负责展示。4. 指标设计与告警规则实战4.1 黄金指标延迟、流量、错误、饱和度Google SRE书里提出的“四个黄金信号”是我设计指标体系的起点延迟Latency、流量Traffic、错误Errors、饱和度Saturation。这四个维度基本能覆盖一个服务的健康状态。延迟要区分成功请求和失败请求的延迟因为失败请求往往返回很快混在一起会拉低平均值掩盖真实问题。流量可以用QPS或每分钟请求数来衡量。错误要区分客户端错误4xx和服务端错误5xx告警主要关注5xx。饱和度是系统资源的使用比例比如CPU使用率、连接池使用率、队列长度。我在实际项目里会为每个服务定义一组标准指标命名规范是服务名_指标名_单位比如order_service_request_duration_seconds。标签包括method、status、instance。这样查询时可以灵活聚合。4.2 告警规则编写与阈值设定告警规则写在Prometheus的rule文件里用PromQL表达式定义触发条件。一个典型的告警规则包含alert名称、expr表达式、for持续时间、labels和annotations。groups: - name: service_alerts rules: - alert: HighErrorRate expr: sum(rate(http_requests_total{status~5..}[5m])) / sum(rate(http_requests_total[5m])) 0.05 for: 2m labels: severity: critical annotations: summary: 服务错误率超过5% description: 当前错误率为 {{ $value | humanizePercentage }}for参数很关键它表示条件持续多久才触发告警。设得太短容易误报设得太长会延迟发现。我的经验是核心服务的关键告警设2到5分钟非核心服务设5到10分钟。阈值设定没有万能公式需要根据历史数据来定。我一般会先观察一周的正常波动范围然后取P99值上浮20%作为初始阈值再根据实际告警情况调整。不要一开始就追求完美阈值先跑起来再迭代。4.3 告警降噪与分组策略告警太吵是很多团队放弃监控的原因。我经历过一次磁盘空间告警风暴一台机器的某个分区满了结果触发了十几条告警因为每个挂载点都报了警。后来我做了几件事来降噪。第一是告警分组。在Alertmanager里配置group_by把同一实例、同一类型的告警合并成一条通知。第二是抑制规则。当严重告警触发时抑制同一实例的次要告警。第三是静默规则。计划内的维护窗口提前设置静默避免无意义告警。实操心得告警通知里一定要包含足够的信息比如当前值、阈值、实例名、Dashboard链接。否则收到告警后还要手动去查响应时间会拉长。我习惯在annotations里加上runbook_url指向处理该告警的操作手册。4.4 指标基数控制与性能优化Prometheus的性能瓶颈通常不在采集而在查询和存储。高基数指标是最大的杀手。什么是高基数就是标签值的组合数量太多。比如用URL路径作为标签如果URL里包含用户ID那基数可能达到几十万甚至上百万。控制基数的方法有几个一是避免使用无界标签比如用户ID、请求ID、时间戳二是对URL做归一化把/user/123/profile变成/user/:id/profile三是定期清理不再使用的时间序列通过--storage.tsdb.retention.time自动过期。查询优化方面尽量使用rate()、increase()等函数而不是原始计数器值减少返回的数据点数量。Dashboard的时间范围不要设得太大查看一周数据时用step参数控制分辨率。5. 常见问题排查与避坑指南5.1 目标抓取失败排查Prometheus的Targets页面会显示每个抓取目标的状态。如果显示DOWN通常有几个原因网络不通、端口不对、metrics路径不对、目标端没有启动。排查顺序是先curl一下目标的metrics端点确认能返回数据然后检查Prometheus配置里的targets地址是否正确最后看Prometheus日志有没有报错。有一个容易忽略的情况是防火墙或安全组规则。我遇到过Prometheus服务器能ping通目标但抓取9100端口超时最后发现是安全组没放行。另外如果目标端用了HTTPS且证书是自签的需要在scrape_configs里配置tls_config跳过验证或指定CA证书。5.2 数据断点与时间对齐问题有时候Grafana图表上会出现断点数据不连续。常见原因是Prometheus重启导致内存中的数据丢失或者抓取间隔内目标端没有响应。如果是前者可以配置远程存储做持久化如果是后者检查目标端的负载是否过高。时间对齐问题也经常遇到。Prometheus的数据点时间戳是抓取时刻如果目标端的时间不准会导致数据错位。建议所有被监控主机开启NTP时间同步。另外Grafana的时区设置要和Prometheus一致否则图表上的时间会对不上。5.3 告警不触发或误触发告警不触发的原因可能是表达式写错了、for时间没到、或者Alertmanager配置有问题。排查时先在Prometheus的Alerts页面看规则状态如果是Inactive说明表达式没匹配到数据如果是Pending说明条件满足了但for时间没到如果是Firing但没收到通知检查Alertmanager的路由配置。误触发通常是指标波动导致的。比如CPU使用率偶尔冲到90%又马上降下来如果for设得太短就会报警。解决办法是加长for时间或者用avg_over_time()对指标做平滑处理。5.4 存储空间不足与数据清理Prometheus的存储空间增长速度和指标数量、采集频率、保留时间成正比。如果磁盘快满了可以调小retention.time或者用--storage.tsdb.retention.size限制最大存储量。但要注意删除数据是不可逆的调小保留时间后旧数据会被清理。长期方案是接入远程存储把冷数据转移到对象存储。但远程存储的查询性能不如本地所以通常只把超过30天的数据转过去。我目前的策略是本地保留15天远程保留90天基本能满足故障回溯和容量规划的需求。5.5 常见问题速查表问题现象可能原因排查方法解决方案Target显示DOWN网络不通/端口错误curl目标端点检查防火墙和配置图表有断点Prometheus重启/抓取超时查看日志和Target状态配置远程存储/调大超时告警不触发表达式错误/for未到查看Alerts页面状态修正表达式/调整for告警太频繁阈值过低/波动大查看历史数据分布调高阈值/加平滑函数存储增长过快指标基数高/保留时间长查看TSDB状态控制标签基数/调小保留时间查询很慢时间范围大/聚合复杂用explain分析缩小范围/预聚合最后分享一个我踩过的坑不要在生产环境用latest标签的Docker镜像。我有一次更新Prometheus拉了最新镜像结果配置格式变了服务起不来。后来所有监控组件都固定版本号升级前先在测试环境验证。6. 监控体系的迭代与个人经验监控不是一次性的项目而是需要持续迭代的过程。我刚开始搭监控时恨不得把所有能采集的指标都采下来结果Dashboard上几十个图表真正看的没几个。后来我做了减法只保留与业务健康直接相关的指标反而更容易发现问题。另一个体会是告警要有人负责。如果告警发出来没人处理那还不如不配。我们团队的做法是每个告警规则都指定负责人定期review告警记录把长期不处理的规则要么修要么删。这样告警列表始终是“活”的大家也愿意看。指标命名和标签规范也要尽早统一。我见过不同团队用不同的命名风格有的用驼峰有的用下划线查询时要记好几套名字。后来我们定了一个规范文档所有新指标必须按规范来老指标逐步迁移。虽然前期麻烦一点但长期看省了很多沟通成本。关于工具选型我的建议是不要追求大而全。Prometheus加Grafana加Alertmanager这套组合覆盖了采集、存储、可视化、告警四个环节对大多数团队来说足够了。等真的遇到瓶颈再考虑引入长期存储、分布式追踪等组件。监控体系应该是演进而非设计出来的先跑起来再根据实际痛点优化。最后说一个容易被忽视的点监控系统本身也需要被监控。Prometheus有没有挂、Alertmanager有没有正常发通知、Grafana能不能访问这些都要有独立的检查机制。我一般会用一个简单的脚本定期访问各个组件的健康端点异常时通过独立渠道通知。否则监控挂了都不知道等出事故时才发现两眼一抹黑。 
长河君 · 2026/10/14 1:20:21 · 阅读 1.2k 从零搭建Metrics监控体系：核心概念、选型与实战避坑指南
1. 从零搭建一套能用的Metrics监控我踩过的坑和最终方案监控这件事很多团队都是等到线上出了事故才开始重视。我经历过一次典型的场景某个服务响应时间突然从200ms飙到3s用户投诉涌进来但我们花了将近40分钟才定位到是数据库连接池被打满。那40分钟里我们只有零散的日志没有任何系统性的指标数据可以看。这件事之后我开始认真研究Metrics监控工具从最基础的计数器到完整的可视化告警链路前后折腾了大半年踩了不少坑也总结了一套还算靠谱的方案。这篇文章主要面向两类人一是刚接触Metrics监控、不知道从哪下手的开发者二是已经在用一些监控工具、但感觉数据不够用或者告警太吵的团队。我会从核心概念讲起把选型逻辑、部署实操、指标设计、告警配置、问题排查这几个环节都拆开说清楚。每个部分我都会解释“为什么这么做”而不只是“怎么做”。读完你至少能搭出一套覆盖主机、应用、中间件的监控体系并且知道哪些指标值得看、哪些告警该关掉。Metrics监控的本质就是把系统运行时的各种状态用数字记录下来再通过这些数字的变化趋势判断系统是否健康。听起来简单但实际操作中指标选多了噪音大选少了漏问题采集频率高了存储扛不住低了又看不到毛刺。这些取舍才是真正花时间的地方。下面我按自己的实践顺序一步步展开。2. 监控体系的核心设计与选型逻辑2.1 为什么是Metrics而不是Logs或Traces可观测性领域有三个支柱Metrics、Logs、Traces。很多人一开始会混淆它们的定位。我用一个生活化的类比来解释Metrics就像你家里的电表和水表每隔几秒记录一次读数告诉你“现在用了多少”Logs像日记本记录每一件具体发生的事Traces像快递追踪告诉你一个请求从下单到签收经过了哪些环节。Metrics最大的优势是聚合性和低成本。一条时间序列数据点通常只有几十字节即使每秒采集一万个指标一天的存储量也在可控范围内。而同样规模的日志存储成本可能是指标数据的几十倍。更重要的是Metrics天然适合做趋势分析和告警——你不需要逐条读日志只需要看一个数值是否超过了阈值。但这不意味着Metrics能替代Logs和Traces。我的经验是Metrics负责发现异常Logs负责定位原因Traces负责分析链路。三者配合使用效果最好但如果资源有限Metrics应该是第一个建的。2.2 拉模式与推模式的选择Metrics采集有两种基本模式Pull拉和Push推。Pull模式是监控服务端定期去目标端拉取指标Prometheus是典型代表Push模式是目标端主动把指标推送到服务端Graphite、InfluxDB的某些用法属于这一类。我最初用的是Push模式因为觉得“主动上报”更直观。但实际跑下来发现几个问题一是目标端需要知道服务端地址配置耦合度高二是网络抖动时容易丢数据三是很难判断一个实例是“挂了”还是“只是没数据上报”。后来切换到Pull模式这些问题基本都解决了——服务端配置目标列表定期抓取如果抓不到就说明实例可能有问题告警逻辑非常清晰。Pull模式还有一个好处是服务发现。在容器化环境里实例的IP和端口经常变化Pull模式可以配合服务发现机制自动感知新实例不需要手动维护目标列表。当然Pull模式也有缺点比如短生命周期任务跑几秒就结束的Job可能来不及被抓取这时候需要用Pushgateway做中转。2.3 存储引擎的取舍Metrics数据是典型的时间序列数据每个数据点包含时间戳、指标名、标签和值。传统关系型数据库在这种场景下性能很差因为写入量大、查询模式固定按时间范围聚合。所以基本上都会选择专门的时间序列数据库TSDB。我实际用过的方案有三种Prometheus自带的本地TSDB、InfluxDB、以及基于对象存储的远程存储。Prometheus本地TSDB的优点是部署简单、查询语言强大PromQL缺点是单机存储容量有限长期数据需要做远程存储。InfluxDB在写入性能上表现不错但集群版是商业产品开源版只支持单机。远程存储方案适合数据量特别大的场景但架构复杂度高小团队不太建议一开始就上。我的建议是起步阶段直接用Prometheus本地存储保留15到30天数据。这个周期足够覆盖大部分故障回溯需求。等数据量真的上来了再考虑接远程存储。不要一上来就搞一套复杂的存储架构维护成本会吃掉你大量精力。2.4 指标类型的选择与语义Metrics有四种基本类型Counter计数器、Gauge仪表盘、Histogram直方图、Summary摘要。很多人会混用导致后期查询时发现数据没法用。Counter是只增不减的适合记录请求总数、错误总数这类累计值。Gauge可以增可以减适合记录当前内存使用量、在线用户数这类瞬时值。Histogram和Summary都用于记录分布数据比如请求延迟但Histogram可以在服务端做分位数计算Summary在客户端计算。我一般优先用Histogram因为它的分位数可以在查询时灵活调整而Summary的分位数在采集时就固定了。这里有个容易踩的坑不要用Gauge记录累计值。我见过有人用Gauge记录请求总数结果服务重启后数值归零导致增长率计算出错。累计值一定要用Counter配合rate()函数计算增长率。3. 核心组件部署与实操配置3.1 Prometheus服务端部署要点Prometheus的部署本身不复杂下载二进制包解压就能跑。但生产环境需要考虑几个关键配置。首先是数据保留时间通过--storage.tsdb.retention.time参数控制默认15天。如果磁盘空间有限可以调小到7天。其次是抓取间隔全局默认scrape_interval设为15秒比较均衡太短会增加存储压力太长会漏掉瞬时峰值。配置文件prometheus.yml是核心结构分为global、scrape_configs、alerting、rule_files几个部分。global里设置抓取间隔和超时时间scrape_configs定义抓取目标rule_files加载告警规则文件。我建议把告警规则单独放在rules/目录下按业务模块拆分文件方便管理。global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: node static_configs: - targets: [localhost:9100] - job_name: app metrics_path: /actuator/prometheus static_configs: - targets: [localhost:8080]注意evaluation_interval控制告警规则的评估频率不要设得比scrape_interval还小否则会出现数据还没采集到就开始评估的情况。3.2 主机指标采集Node ExporterNode Exporter是采集主机指标的标准组件部署在每台被监控的机器上。它暴露的指标非常全面包括CPU、内存、磁盘、网络、文件系统等。启动方式很简单下载二进制后直接运行默认监听9100端口。但默认配置下有些指标采集不到比如磁盘IO的详细数据需要挂载/proc和/sys。如果用Docker部署需要加上--path.procfs和--path.sysfs参数。另外Node Exporter默认会采集很多用不到的指标可以通过--collector.disable-defaults配合--collector.xxx按需开启减少数据量。我实际关注的主机指标有这几个node_cpu_seconds_totalCPU使用率、node_memory_MemAvailable_bytes可用内存、node_filesystem_avail_bytes磁盘剩余空间、node_network_receive_bytes_total网络接收流量。这几个指标基本能覆盖80%的主机异常场景。3.3 应用指标暴露埋点与SDK选择应用层的指标需要自己在代码里埋点。主流语言都有对应的客户端库比如Java的Micrometer、Go的prometheus/client_golang、Python的prometheus_client。这些库的使用方式大同小异注册指标、在关键路径上打点、通过HTTP端点暴露。以Java应用为例如果用的是Spring Boot引入Micrometer和Prometheus的依赖后很多指标会自动采集包括JVM内存、GC次数、HTTP请求延迟等。自定义指标只需要注入MeterRegistry然后创建Counter或Timer。Autowired private MeterRegistry registry; public void handleRequest() { Timer.Sample sample Timer.start(registry); try { // 业务逻辑 } finally { sample.stop(registry.timer(request.duration, method, handleRequest)); } }提示指标标签的基数Cardinality要严格控制。不要用用户ID、请求ID这种高基数标签否则时间序列数量会爆炸Prometheus内存会被吃光。标签值应该是有限的枚举集合比如状态码、方法名、实例名。3.4 可视化面板Grafana接入Prometheus自带的Web UI只能做简单查询真正好用的可视化要靠Grafana。Grafana接入Prometheus很简单在数据源配置里填上Prometheus地址即可。然后就是建Dashboard把关键指标用图表展示出来。我一般会建三个层次的Dashboard概览层展示核心健康指标请求量、错误率、延迟P99主机层展示CPU、内存、磁盘、网络应用层展示JVM、连接池、缓存命中率等。每个Dashboard控制在6到8个图表太多会让人抓不住重点。Grafana的变量功能很实用可以定义instance、job等变量在一个Dashboard里切换查看不同实例的数据。告警也可以直接在Grafana里配但我的习惯是告警规则统一放在Prometheus里管理Grafana只负责展示。4. 指标设计与告警规则实战4.1 黄金指标延迟、流量、错误、饱和度Google SRE书里提出的“四个黄金信号”是我设计指标体系的起点延迟Latency、流量Traffic、错误Errors、饱和度Saturation。这四个维度基本能覆盖一个服务的健康状态。延迟要区分成功请求和失败请求的延迟因为失败请求往往返回很快混在一起会拉低平均值掩盖真实问题。流量可以用QPS或每分钟请求数来衡量。错误要区分客户端错误4xx和服务端错误5xx告警主要关注5xx。饱和度是系统资源的使用比例比如CPU使用率、连接池使用率、队列长度。我在实际项目里会为每个服务定义一组标准指标命名规范是服务名_指标名_单位比如order_service_request_duration_seconds。标签包括method、status、instance。这样查询时可以灵活聚合。4.2 告警规则编写与阈值设定告警规则写在Prometheus的rule文件里用PromQL表达式定义触发条件。一个典型的告警规则包含alert名称、expr表达式、for持续时间、labels和annotations。groups: - name: service_alerts rules: - alert: HighErrorRate expr: sum(rate(http_requests_total{status~5..}[5m])) / sum(rate(http_requests_total[5m])) 0.05 for: 2m labels: severity: critical annotations: summary: 服务错误率超过5% description: 当前错误率为 {{ $value | humanizePercentage }}for参数很关键它表示条件持续多久才触发告警。设得太短容易误报设得太长会延迟发现。我的经验是核心服务的关键告警设2到5分钟非核心服务设5到10分钟。阈值设定没有万能公式需要根据历史数据来定。我一般会先观察一周的正常波动范围然后取P99值上浮20%作为初始阈值再根据实际告警情况调整。不要一开始就追求完美阈值先跑起来再迭代。4.3 告警降噪与分组策略告警太吵是很多团队放弃监控的原因。我经历过一次磁盘空间告警风暴一台机器的某个分区满了结果触发了十几条告警因为每个挂载点都报了警。后来我做了几件事来降噪。第一是告警分组。在Alertmanager里配置group_by把同一实例、同一类型的告警合并成一条通知。第二是抑制规则。当严重告警触发时抑制同一实例的次要告警。第三是静默规则。计划内的维护窗口提前设置静默避免无意义告警。实操心得告警通知里一定要包含足够的信息比如当前值、阈值、实例名、Dashboard链接。否则收到告警后还要手动去查响应时间会拉长。我习惯在annotations里加上runbook_url指向处理该告警的操作手册。4.4 指标基数控制与性能优化Prometheus的性能瓶颈通常不在采集而在查询和存储。高基数指标是最大的杀手。什么是高基数就是标签值的组合数量太多。比如用URL路径作为标签如果URL里包含用户ID那基数可能达到几十万甚至上百万。控制基数的方法有几个一是避免使用无界标签比如用户ID、请求ID、时间戳二是对URL做归一化把/user/123/profile变成/user/:id/profile三是定期清理不再使用的时间序列通过--storage.tsdb.retention.time自动过期。查询优化方面尽量使用rate()、increase()等函数而不是原始计数器值减少返回的数据点数量。Dashboard的时间范围不要设得太大查看一周数据时用step参数控制分辨率。5. 常见问题排查与避坑指南5.1 目标抓取失败排查Prometheus的Targets页面会显示每个抓取目标的状态。如果显示DOWN通常有几个原因网络不通、端口不对、metrics路径不对、目标端没有启动。排查顺序是先curl一下目标的metrics端点确认能返回数据然后检查Prometheus配置里的targets地址是否正确最后看Prometheus日志有没有报错。有一个容易忽略的情况是防火墙或安全组规则。我遇到过Prometheus服务器能ping通目标但抓取9100端口超时最后发现是安全组没放行。另外如果目标端用了HTTPS且证书是自签的需要在scrape_configs里配置tls_config跳过验证或指定CA证书。5.2 数据断点与时间对齐问题有时候Grafana图表上会出现断点数据不连续。常见原因是Prometheus重启导致内存中的数据丢失或者抓取间隔内目标端没有响应。如果是前者可以配置远程存储做持久化如果是后者检查目标端的负载是否过高。时间对齐问题也经常遇到。Prometheus的数据点时间戳是抓取时刻如果目标端的时间不准会导致数据错位。建议所有被监控主机开启NTP时间同步。另外Grafana的时区设置要和Prometheus一致否则图表上的时间会对不上。5.3 告警不触发或误触发告警不触发的原因可能是表达式写错了、for时间没到、或者Alertmanager配置有问题。排查时先在Prometheus的Alerts页面看规则状态如果是Inactive说明表达式没匹配到数据如果是Pending说明条件满足了但for时间没到如果是Firing但没收到通知检查Alertmanager的路由配置。误触发通常是指标波动导致的。比如CPU使用率偶尔冲到90%又马上降下来如果for设得太短就会报警。解决办法是加长for时间或者用avg_over_time()对指标做平滑处理。5.4 存储空间不足与数据清理Prometheus的存储空间增长速度和指标数量、采集频率、保留时间成正比。如果磁盘快满了可以调小retention.time或者用--storage.tsdb.retention.size限制最大存储量。但要注意删除数据是不可逆的调小保留时间后旧数据会被清理。长期方案是接入远程存储把冷数据转移到对象存储。但远程存储的查询性能不如本地所以通常只把超过30天的数据转过去。我目前的策略是本地保留15天远程保留90天基本能满足故障回溯和容量规划的需求。5.5 常见问题速查表问题现象可能原因排查方法解决方案Target显示DOWN网络不通/端口错误curl目标端点检查防火墙和配置图表有断点Prometheus重启/抓取超时查看日志和Target状态配置远程存储/调大超时告警不触发表达式错误/for未到查看Alerts页面状态修正表达式/调整for告警太频繁阈值过低/波动大查看历史数据分布调高阈值/加平滑函数存储增长过快指标基数高/保留时间长查看TSDB状态控制标签基数/调小保留时间查询很慢时间范围大/聚合复杂用explain分析缩小范围/预聚合最后分享一个我踩过的坑不要在生产环境用latest标签的Docker镜像。我有一次更新Prometheus拉了最新镜像结果配置格式变了服务起不来。后来所有监控组件都固定版本号升级前先在测试环境验证。6. 监控体系的迭代与个人经验监控不是一次性的项目而是需要持续迭代的过程。我刚开始搭监控时恨不得把所有能采集的指标都采下来结果Dashboard上几十个图表真正看的没几个。后来我做了减法只保留与业务健康直接相关的指标反而更容易发现问题。另一个体会是告警要有人负责。如果告警发出来没人处理那还不如不配。我们团队的做法是每个告警规则都指定负责人定期review告警记录把长期不处理的规则要么修要么删。这样告警列表始终是“活”的大家也愿意看。指标命名和标签规范也要尽早统一。我见过不同团队用不同的命名风格有的用驼峰有的用下划线查询时要记好几套名字。后来我们定了一个规范文档所有新指标必须按规范来老指标逐步迁移。虽然前期麻烦一点但长期看省了很多沟通成本。关于工具选型我的建议是不要追求大而全。Prometheus加Grafana加Alertmanager这套组合覆盖了采集、存储、可视化、告警四个环节对大多数团队来说足够了。等真的遇到瓶颈再考虑引入长期存储、分布式追踪等组件。监控体系应该是演进而非设计出来的先跑起来再根据实际痛点优化。最后说一个容易被忽视的点监控系统本身也需要被监控。Prometheus有没有挂、Alertmanager有没有正常发通知、Grafana能不能访问这些都要有独立的检查机制。我一般会用一个简单的脚本定期访问各个组件的健康端点异常时通过独立渠道通知。否则监控挂了都不知道等出事故时才发现两眼一抹黑。