监控栈选型这件事我为什么最后停在 Prometheus Grafana监控系统这东西有个很尴尬的特性不出事的时候没人记得它存在一旦线上抖一下全公司几十号人的目光瞬间集中到你那块看板上。我从早期用 shell 脚本加 cron 定时探测端口到后来折腾过几套商业方案再到现在大部分项目里把监控栈固定成Prometheus Grafana这套组合中间踩的坑够写一本小册子。这篇文章想干的事情很朴素把 Prometheus 和 Grafana 这两个东西到底解决什么问题、数据是怎么流动的、从零搭起来要注意哪些细节、告警怎么闭环、K8s 和 OTel Collector 这类进阶场景怎么接进来一次性讲清楚。先给完全没接触过的朋友一句话定位Prometheus 负责采集和存储时序指标数据Grafana 负责把这些数据画成人能看懂的图。前者是数据库加采集器后者是可视化层两者之间通过 HTTP 查询接口通信耦合度很低。你完全可以用 Grafana 去接别的数据源也可以用 Prometheus 自带的 Web UI 查表达式但把这两个凑一起是因为它们对指标数据的心智模型天然吻合。这篇内容适合三类人一是刚开始接触监控、准备给自建服务加一套可观测能力的后端或运维同学二是已经在用但只用了个皮毛、想补上告警和 K8s 场景的工程师三是需要在团队里推动监控落地、想知道选型和成本权衡的技术负责人。我会尽量把为什么这么配讲透而不只是贴一段能跑的 YAML 就完事——因为配置这东西抄错了最多报个错理解错了可能半年后才发现数据根本不准。1. 拆解这套组合的设计思路与选型逻辑1.1 监控系统真正要回答的三个问题很多人上来就问用什么监控工具其实应该先问我要监控什么。一套监控体系归根到底要回答三个层次的问题现在系统健康吗实时状态、过去一小时发生了什么趋势回溯、出问题时该叫醒谁告警触达。这三个问题对存储和查询的要求完全不同——实时状态要求低延迟写入趋势回溯要求能高效做区间聚合告警触达要求有独立的规则引擎和通知通道。Prometheus 的设计恰好把这三块拆开了采集和存储走 TSDB时序数据库查询走 PromQL 表达式引擎告警走独立的 Alertmanager 组件。这种关注点分离让每一层都能单独扩展、单独重启不会因为告警模块挂了就影响数据采集。我见过不少团队把告警逻辑写进采集脚本里结果脚本一崩溃连脚本崩了这件事本身都没人知道这就是没做分离的代价。1.2 Pull 模型一个反直觉但很关键的选择Prometheus 最容易被新手质疑的地方就是它采用Pull拉取模型——由 Prometheus 主动去各个目标上抓数据而不是让被监控的服务主动上报。习惯了自己写埋点上报的同学第一反应都是这样不对吧服务怎么知道 Prometheus 的地址。这个设计背后的逻辑其实很硬核。首先是健康判断天然成立如果 Prometheus 抓不到某个目标的/metrics那这个目标要么挂了要么网络不通up指标直接变成 0不需要额外的心跳机制。其次是采集端可控抓取频率、超时时间、并发数全在 Prometheus 侧配置改配置重启一下就生效不用去每个被监控机器上改代码。第三是避免上报风暴几百个实例同时往上推数据接收端的写入压力是不可控的Pull 模式下采集节奏由中心控制天然削峰。当然 Pull 也有代价。短生命周期任务比如跑完就退出的批处理 Job根本来不及被抓取这时候就得用Pushgateway做个中转让任务把结果推到网关Prometheus 再去抓网关。还有一个常见痛点是被监控目标在防火墙后面、Prometheus 进不去这种场景要么做网络打通要么同样走 Pushgateway。我的经验是长期运行的服务一律走 Pull生命周期短于一个采集周期的任务才考虑 Pushgateway不要因为省事把所有东西都推给网关那样网关会变成单点和瓶颈。1.3 和主流方案的横向对比到底选哪套得看你的场景。我整理了一张对比表这几套方案我在不同项目里都用过维度Prometheus GrafanaZabbixELK 类方案数据模型多维标签时序主机为中心日志全文索引采集方式以 Pull 为主Agent 上报为主日志采集器查询语言PromQL内置函数检索语法适合场景云原生、容器、指标传统主机、网络设备日志检索、审计长期存储需接远程存储自带数据库自带索引学习曲线中PromQL 需练低界面化中高我的实际结论是指标类监控优先 Prometheus日志类分析走 ELK两者不是替代关系而是互补。Zabbix 在传统物理机和网络设备监控上依然有优势尤其是 SNMP 采集这块积累很深。但如果你的服务跑在容器里、实例频繁扩缩容Prometheus 基于标签的发现机制会让你舒服很多——IP 变了没关系只要标签能对上数据自动接续。还有一点值得说Prometheus 是Apache 2.0 协议的开源项目并且是 CNCF 的毕业项目社区活跃度和生态成熟度都很高。围绕它衍生出的 exporter 生态几乎覆盖了你能想到的所有中间件MySQL、Redis、Kafka、Nginx、JVM 应用全都有现成的 exporter 可以接这也是我倾向它的重要原因——不用自己写采集逻辑装个 exporter 配一行抓取配置就完事。2. 动手前必须吃透的几个核心概念2.1 指标、标签与时间序列的真实关系Prometheus 里所有的数据最终都落到一个叫时间序列time series的结构上。一条时间序列由三部分组成指标名metric name 一组标签键值对labels 按时间排列的样本值。比如http_requests_total{methodGET, status200, instance10.0.0.1:8080}就是一条完整的时间序列标识后面跟着一串(时间戳, 数值)的点。这里的核心理解是标签的每一种取值组合都会生成一条独立的时间序列。这跟关系型数据库里加个 WHERE 条件完全不是一个概念。举个例子如果你的instance标签里塞了用户 ID 这种高基数high cardinality的值一个十万用户的服务瞬间就会产生十万条时间序列Prometheus 的内存会被吃干净。这是我见过最多的翻车场景没有之一。所以标签设计的铁律是只放取值有限的维度服务名、接口名、状态码、机房、集群绝对不要放用户 ID、订单号、请求 ID、时间戳这类无限增长的字段。这类信息应该写进日志交给日志系统去查不要塞进指标。2.2 四种指标类型的适用场景Prometheus 客户端库只暴露四种指标类型很多人用了一两年也说不清区别我这里把它们和真实场景对应起来Counter计数器是只增不减的累计值比如请求总数、错误总数、处理的字节数。它永远是往上爬的除非进程重启归零。你几乎不会直接看它的原始值而是用rate()或increase()函数算出增长率才有意义。Gauge仪表盘是随时可增可减的瞬时值比如当前内存占用、当前连接数、队列长度、CPU 使用率。这种可以直接拿来画图看的就是那一刻的值。Histogram直方图用来统计分布最典型的场景是接口耗时。它会把采样值按预设的桶bucket分档计数同时给出总和和总次数。你常用它算 P95、P99 延迟也就是histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))这类表达式。Summary摘要同样统计分布但分位数是在客户端算好直接暴露的没法做跨实例聚合。因为没法聚合这个硬伤我在实际项目里基本不用 Summary一律用 Histogram——分位数可以后期在服务端算可聚合性不能后期补。桶bucket的设置在 Histogram 里极其关键。默认桶对 HTTP 请求来说往往不合适我一般会按业务预期延迟重新划分比如接口目标是 200ms 内返回那桶就设成[0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5]。桶设置太稀会导致分位数误差大Prometheus 的分位数是插值估算的不是精确值桶设太密又会撑大时间序列数量这个平衡点需要按实际延迟分布调。2.3 PromQL 和 Grafana 的分工边界新手经常混淆这两者的职责。简单说PromQL 负责把原始数据算成你要的那个数Grafana 负责把这个数画出来和展示出来。Grafana 本身不做复杂计算它把你写的 PromQL 查询发给 Prometheus拿到结果后做渲染、做阈值着色、做变量联动。理解这条边界能省很多事。比如你想看过去 5 分钟的请求速率正确做法是在 Grafana 面板里写rate(http_requests_total[5m])让 Prometheus 去算而不是拉原始数据到 Grafana 里自己算。再比如告警规则里的表达式和 Grafana 面板里写的表达式本质是同一套 PromQL你可以在 Prometheus 的 Web UI 里先调试好再分别贴到两个地方去用。补充一个热词相关的点Prometheus 自带 Web UI 本身就挺好用。访问http://prometheus:9090后/graph页面可以交互式跑 PromQL、看图表/targets页面能直接看到所有采集目标是否健康、上次抓取耗时多少、报了什么错。调采集问题的时候/targets是我第一个打开的地方比翻日志快得多。3. 从零搭建完整部署流程与关键配置3.1 用 Docker Compose 把整套拉起来生产环境当然可以用二进制或者 Helm 部署但用来学习、做本地验证、搭小型环境Docker Compose 是最快的方式一个文件把 Prometheus、Grafana、node_exporter、Alertmanager 全带起来。镜像直接从官方仓库拉取即可prom/prometheus、grafana/grafana、prom/node-exporter、prom/alertmanager都是官方维护的版本号建议明确写死不要用latest否则某天自动升级可能带来配置不兼容。version: 3.8 services: prometheus: image: prom/prometheus:v2.53.0 container_name: prometheus restart: unless-stopped volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml - ./rules:/etc/prometheus/rules - prom_data:/prometheus command: - --config.file/etc/prometheus/prometheus.yml - --storage.tsdb.path/prometheus - --storage.tsdb.retention.time15d - --web.enable-lifecycle - --web.enable-admin-api ports: - 9090:9090 networks: - monitor grafana: image: grafana/grafana:11.1.0 container_name: grafana restart: unless-stopped volumes: - grafana_data:/var/lib/grafana environment: - GF_SECURITY_ADMIN_PASSWORDchange_me_now - GF_USERS_ALLOW_SIGN_UPfalse ports: - 3000:3000 networks: - monitor node-exporter: image: prom/node-exporter:v1.8.1 container_name: node-exporter restart: unless-stopped pid: host volumes: - /proc:/host/proc:ro - /sys:/host/sys:ro - /:/rootfs:ro command: - --path.procfs/host/proc - --path.sysfs/host/sys - --path.rootfs/rootfs - --collector.filesystem.mount-points-exclude^/(sys|proc|dev|host|etc)($$|/) ports: - 9100:9100 networks: - monitor alertmanager: image: prom/alertmanager:v0.27.0 container_name: alertmanager restart: unless-stopped volumes: - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml ports: - 9093:9093 networks: - monitor volumes: prom_data: grafana_data: networks: monitor: driver: bridge这里有几个参数值得单独拎出来说。--storage.tsdb.retention.time15d控制本地数据保留时长默认是 15 天如果磁盘够大又想留更久可以调成 30d但要留意本地磁盘容量指标数据的膨胀速度往往超出预估。--web.enable-lifecycle打开后可以通过curl -X POST http://localhost:9090/-/reload热加载配置改完配置不用重启进程这在迭代告警规则的时候能省大量时间。--web.enable-admin-api是管理接口做快照备份和删除时间序列时会用到但因为它有删除能力生产环境暴露时要配合访问控制不要直接对公网开放。node-exporter 那里有个pid: host和挂载/proc、/sys的设置这是为了让容器里的 exporter 能看到宿主机的真实指标。如果不这么配你采集到的其实是容器自身的资源数据图上显示的内存永远是几百兆会把人误导得很惨。--collector.filesystem.mount-points-exclude这个参数用来排除掉一堆无意义的挂载点比如 docker overlay、tmpfs否则文件系统指标会多出几十条噪声序列。3.2 prometheus.yml 逐行拆解prometheus.yml是整个系统的入口配置结构上分四块全局配置、告警配置、抓取配置、规则文件。下面是一份带注释的完整示例global: scrape_interval: 15s # 默认抓取间隔 evaluation_interval: 15s # 告警规则评估间隔 scrape_timeout: 10s # 单次抓取超时必须小于 scrape_interval external_labels: # 联邦或远程写时携带的标签 cluster: prod-shanghai replica: A alerting: alertmanagers: - static_configs: - targets: [alertmanager:9093] rule_files: - /etc/prometheus/rules/*.yml scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090] - job_name: node static_configs: - targets: - node-exporter:9100 labels: env: prod role: app-server - job_name: app-metrics metrics_path: /metrics scrape_interval: 30s static_configs: - targets: - 10.0.1.11:8080 - 10.0.1.12:8080关于scrape_interval的取值我这里说个实际经验15s 是大多数场景的甜点区。设成 1s 看起来实时但采集压力、存储增长、PromQL 查询成本都会成倍上涨设成 60s 又会让告警延迟很难看短促的故障可能直接漏掉。如果某类业务特别敏感可以针对单个 job 覆盖全局配置就像上面app-metrics那样单独设成 30s——按 job 差异化设置而不是全局调小这是控制成本的关键。scrape_timeout必须小于scrape_interval否则上一轮还没抓完下一轮就开始了会累积出一堆超时错误。一般设成间隔的 2/3 比较稳妥。external_labels在多集群或多副本场景下很重要它能让你在数据里区分数据来自哪个集群做联邦federation汇聚时尤其关键不加的话多集群数据会混在一起分不清来源。3.3 服务发现的几种姿势静态配置static_configs只适合目标数量固定、IP 不变的环境。一旦上了容器平台实例 IP 天天变静态配置就彻底没法维护了这时候需要服务发现。Prometheus 原生支持多种发现机制基于文件file_sd、基于 DNS、基于 K8s API、基于 Consul 等等。其中最通用的是file_sd它从一个 JSON 或 YAML 文件里读取目标列表你只需要用脚本或定时任务去更新这个文件Prometheus 会自动感知变更。这种方式的解耦性很好——采集侧不需要懂你的 CMDB只管读文件非常适合自研平台或者混合环境。scrape_configs: - job_name: file-discovered file_sd_configs: - files: - /etc/prometheus/targets/*.json refresh_interval: 30s对应的 JSON 文件长这样每次新增机器改这个文件就行[ { targets: [10.0.2.21:9100, 10.0.2.22:9100], labels: { env: prod, service: payment } } ]还有relabel_configs这个机制功能非常强但初学容易劝退。它的作用是在抓取前对目标的标签做增删改最常用的场景是从服务发现返回的一堆元数据标签里挑出你需要的转成正式标签或者基于标签条件过滤掉不需要抓的目标。记住一个规律relabel_configs作用在抓取之前操作的是目标标签metric_relabel_configs作用在抓取之后操作的是样本标签后者常用来丢弃高基数或没必要的指标是控制存储增长的一把利器。3.4 Grafana 接入数据源与看板导入Grafana 容器起来后访问http://localhost:3000默认账号密码都是admin首次登录会强制改密码如果你在环境变量里设了GF_SECURITY_ADMIN_PASSWORD就用你设的那个。登录后第一步是加数据源左侧菜单进Connections → Data sources → Add data source选 PrometheusURL 填http://prometheus:9090容器内通信用服务名保存后点Save Test出现绿色提示就说明通了。下一步是导入现成的看板。Grafana 官方看板库里有大量社区维护的面板node_exporter 的经典看板 ID 是1860容器相关的有193、893等。导入方式是Dashboards → New → Import输入 ID 点 Load选好数据源就能用。这套流程能让你在十分钟内看到一张像模像样的主机监控大盘对新手建立起正反馈很重要。不过我要提醒一句社区看板是通用模板不要直接当作生产告警依据。这些面板往往把所有能画的指标都画上了信息密度极高但重点不突出而且不同人的 node_exporter 版本、标签命名不一样导入后经常出现部分面板空白。我的习惯是导入后先删掉用不上的行再按业务关注点重排最后把自己团队的标签命名统一替换掉做成一份内部模板复用。有个高频报错值得一提导入一些老看板时Grafana 会弹failed to upgrade legacy queries datasource xxx was not found。这个报错的根源是看板 JSON 里保存的是旧版数据源的数字 ID 引用而新版本 Grafana 用的是数据源 UID两者对不上就报错了。解决办法有三种一是导入时在数据源选择框里手动指定一次让 Grafana 重新绑定二是把数据源 UID 改成看板里引用的那个值三是直接编辑看板 JSON把datasource字段里的旧 ID 替换成新数据源的 UID 对象。我一般用第一种最省事实在不行才去动 JSON。4. 告警闭环Alertmanager 接入与规则调优4.1 告警规则怎么写才不误报Prometheus 自身只负责评估规则并产生告警真正的去重、分组、路由、静默全在 Alertmanager 里做。规则文件用 YAML 写放在rule_files指定的目录下groups: - name: host-alerts interval: 30s rules: - alert: HostHighCpuLoad expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100) 85 for: 5m labels: severity: warning team: infra annotations: summary: 主机 CPU 使用率过高 ({{ $labels.instance }}) description: 实例 {{ $labels.instance }} CPU 使用率已持续 5 分钟高于 85%当前值 {{ $value | printf \%.2f\ }}%。 - alert: HostMemoryLow expr: (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 90 for: 10m labels: severity: critical team: infra annotations: summary: 主机内存紧张 ({{ $labels.instance }}) description: 可用内存低于 10%已持续 10 分钟。写规则有几个原则都是被生产环境教育出来的。第一一定要有for字段。没有它瞬时的毛刺就会触发告警半夜手机响个不停久而久之大家都把告警静音了那监控就形同虚设。CPU 这类容易抖动的指标我一般设 5 到 10 分钟业务性的错误率可以短一点2 到 3 分钟。第二注释里带上当前值和实例信息。告警收到的人往往是半夜被叫起来的还要自己去翻看板找哪台机器、现在多少值体验极差。用{{ $labels.xxx }}和{{ $value }}把关键信息直接写进消息里能大幅缩短定位时间。第三阈值要基于历史数据定不要拍脑袋。我见过阈值设成 CPU 高于 50% 就告警的结果生产环境从来没低于 60%告警天天响。正确做法是先把指标采集跑一两个月看看 P95、P99 的分布把阈值设在高位区间只告警真正的异常。4.2 路由、分组、抑制与静默的配合Alertmanager 的配置文件核心是三块路由树、接收器、抑制规则。route: receiver: default-webhook group_by: [alertname, cluster, service] group_wait: 30s group_interval: 5m repeat_interval: 4h routes: - match: severity: critical receiver: oncall-webhook group_wait: 10s repeat_interval: 1h receivers: - name: default-webhook webhook_configs: - url: http://internal-alert-bridge:8080/warning - name: oncall-webhook webhook_configs: - url: http://internal-alert-bridge:8080/critical inhibit_rules: - source_match: severity: critical target_match: severity: warning equal: [alertname, instance]group_by决定哪些告警会被合并成一条通知这里把告警名、集群、服务作为分组键意味着一台机器上同一类问题的多个实例会被打包成一条消息发出来而不是炸出几十条。group_wait是首次通知前的等待时间给同一批告警一点聚齐的时间group_interval是同一分组内新增告警后再次通知的间隔repeat_interval则是告警一直没恢复时重复提醒的周期。抑制规则inhibit_rules是最容易被忽略但价值极高的一块。典型场景是一台机器磁盘满了导致 MySQL 挂掉此时你会同时收到磁盘空间不足MySQL 进程不在应用连接数据库失败三条告警但它们本质上是同一个根因。抑制规则可以配置成——当critical级别的告警存在时同实例上的warning级别告警自动静默。这样一来值班同学看到的就是一条清晰的根因告警而不是被淹没在衍生告警里。静默silence则是在 Alertmanager 的 Web 界面默认 9093 端口上临时操作的用于计划内的维护窗口。做变更前先建一条静默规则覆盖变更对象避免维护操作触发一堆告警这是基本素养。4.3 告警链路怎么验证才放心规则写完部署下去最忌讳的就是配完就不管了。我每次上线新告警规则都会做三步验证第一步在 Prometheus 的/rules页面确认规则已加载表达式有没有语法错误、当前评估结果是什么一目了然。如果表达式写错这里会直接显示解析错误。第二步看/alerts页面。如果有人为构造的测试数据触发了规则这里能看到告警从inactive变成pending再变成firing的状态流转。pending就是for还没走完的中间态这一步能验证for时长是否合理。第三步也是最容易被跳过的一步确认通知真的送到了人手里。很多问题都出在这一环规则触发了Alertmanager 收到了但 webhook 地址填错、接收端没做鉴权、消息格式解析失败最后人压根没收到。我一般会临时把某条规则的阈值调到一个必然触发的值走一遍完整链路确认消息格式正确、接收方正常处理再把阈值改回去。提示验证告警时优先用调低阈值的方式人为触发而不是去改业务代码制造真实故障。前者安全可控后者风险不可控。5. 进阶场景K8s 采集、OTel 接入与远程存储5.1 K8s 集群里的采集姿势在 K8s 里跑 Prometheus最大的变化是目标发现从静态列表变成了 API 自动发现。K8s 提供了多种发现角色pod、service、endpoints、ingress、node其中endpoints和pod最常用。通过给 Pod 或 Service 打上注解就能让 Prometheus 自动识别哪些该抓、从哪个端口抓。scrape_configs: - job_name: kubernetes-pods kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] action: keep regex: true - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path] action: replace target_label: __metrics_path__ regex: (.) - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port] action: replace regex: ([^:])(?::\\d)?;(\\d) replacement: $1:$2 target_label: __address__ - source_labels: [__meta_kubernetes_namespace] target_label: namespace - source_labels: [__meta_kubernetes_pod_name] target_label: pod这段 relabel 的逻辑值得拆开讲。第一条keep表示只保留带prometheus.io/scrape: true注解的 Pod相当于一个开关第二条把注解里指定的路径覆盖到__metrics_path__这个内部标签上第三条最关键它把 Pod 的地址和注解里声明的端口拼成最终的抓取地址——因为 Pod 内部可能暴露多个端口必须靠注解指定抓哪个。后面两条则是把 K8s 的元数据转成正式标签方便你在 Grafana 里按命名空间或 Pod 名过滤。生产环境我不建议自己手写这一大坨用kube-prometheus-stack这个 Helm Chart 更省事它把 Prometheus、Alertmanager、Grafana、node-exporter、kube-state-metrics 打包在一起还带了大量 K8s 场景的默认告警规则和看板。自己搭一套完整的 K8s 监控再调优工作量比用这个 Chart 大一个数量级。5.2 OTel Collector 的数据怎么进 Prometheus现在很多团队在推 OpenTelemetryOTel统一采集标准日志、指标、链路都用一套 SDK 和 Collector 处理。那 OTel 的指标数据怎么进 Prometheus答案是通过Prometheus Receiver或者Prometheus Exporter两种模式。比较常见的做法是OTel Collector 配置一个prometheusreceiver去抓各个 exporter 的端点做统一处理比如过滤、加标签、重命名之后再通过prometheusexporter暴露一个新的/metrics端点让 Prometheus 来抓或者用prometheusremotewrite把数据直接远程写到 Prometheus 兼容的接收端。这里有个前提要说清楚Prometheus 本身不是被动接收写入的它原生不提供你推给我我收下的接口除了实验性的 remote write receiver需要显式开启。所以 OTel 想往里送数据要么让 Collector 暴露 endpoint 让 Prometheus 来拉要么启用接收端然后走 remote write 协议。理解了这个前提就不会被为什么推不进去这类问题卡住。5.3 远程存储与本地保留策略的权衡Prometheus 本地 TSDB 的设计目标是短期存储 快速查询官方建议单实例保留不要超过一个月规模的数据超大规模要么做分片要么接远程存储。常见的远程存储方案有 Thanos、Mimir、VictoriaMetrics 等它们通过**远程写remote write**把数据同步出去实现长期保留和跨集群聚合查询。配置方式很简单在prometheus.yml里加一段remote_write: - url: http://remote-storage:9201/api/v1/write queue_config: max_samples_per_send: 5000 max_shards: 200 capacity: 25000 write_relabel_configs: - source_labels: [__name__] regex: go_gc_.*|prometheus_tsdb_.* action: dropwrite_relabel_configs这段的作用是在写出前丢弃掉一些没必要的指标比如 Go 运行时的 GC 指标和 Prometheus 自身的 TSDB 指标这类数据本地排查用得上但长期存储价值不大丢掉能显著降低远程存储的成本。这个优化我强烈建议做很多团队远程存储账单飙升就是因为把一堆低价值指标也全量写了过去。关于分片max_shards控制并发写出的分片数queue_config里的capacity是每个分片缓冲的样本数。如果远程端写入变慢队列会积压Prometheus 日志里会报remote storage queue full之类的告警这时候要么扩容远程端要么调大队列参数但要留意内存消耗队列是吃内存的。6. 踩坑实录与排查速查表6.1 高频报错和定位思路这几年排过的问题太多了我把最高频的几类整理成一张速查表遇到问题可以对照着先定位方向现象可能原因排查入口target 状态为 DOWN网络不通、端口错、路径错/targets看具体 error抓取超时 timeoutscrape_timeout太小或目标响应慢看抓取耗时直方图图表出现数据断点进程重启、采集中断、时间不同步检查up指标内存持续增长高基数标签、序列数暴涨看 TSDB 状态页序列数告警不触发表达式错、for未走完、规则未加载/rules页面告警发出但没收到webhook 配置错、接收端异常Alertmanager 日志看板导入报数据源找不到旧看板引用旧数据源 ID重新绑定数据源数据断点这个问题特别值得展开说。图上有断点第一反应往往是采集出问题了但其实有个更隐蔽的原因服务器时间不同步。Prometheus 是时间戳强依赖的系统如果被监控机器和 Prometheus 服务器的时间差超过抓取间隔样本会因为时间戳乱序被丢弃表现就是图上断断续续。所以部署监控时时间同步NTP是必须先做的前置工作这一点经常被忽略。内存持续增长则基本可以确定是高基数问题。Prometheus 有自带的状态页/tsdb-status能看到当前活跃的时间序列总数。这个数字如果持续飙升就要去查是哪个指标贡献的通常是某个标签放了动态值。定位方法是按指标名做count by (__name__)统计找出序列数最多的指标再逐一检查它的标签。6.2 性能与成本上的几个反直觉结论最后分享几个跟直觉相反的经验都是从坑里爬出来才明白的。第一采集频率不是越高越好。我一开始把全局间隔设成 5s觉得这样才够精细结果存储增长是三倍查询一个月的图卡到转圈。后来想清楚了告警的灵敏度靠的是for时长和表达式设计不是靠采集频率。15s 的间隔配合合理的for完全能覆盖绝大多数故障的发现需求。第二指标不是采集得越多越安全。新手总想先把所有指标都收上来以后再说结果采集了上万条序列其中 80% 从来没被任何看板或告警用到。这些沉默的数据占着磁盘、吃着内存、拖慢查询。定期做一次指标盘点把没用的 drop 掉收益非常直观。用metric_relabel_configs做这个事最方便不用改被监控端。第三告警数量少比多好。团队里常见的一种状态是告警规则写了一百多条真正响应的只有几条其余全被静音或忽略。这种告警疲劳比没有告警更危险因为它会让人对告警系统失去信任。我的做法是定期审查告警历史把过去一个月从未触发或者触发了但没人处理的规则删掉或降级保持告警列表的每一行都是真正值得半夜叫人的。第四Grafana 看板的价值在于一眼看懂不在于信息量大。一张面板塞了二十条曲线颜色还都很接近这种图除了让人头晕没有任何作用。好的看板应该是分层的最上面三个核心指标可用性、延迟、错误率中间是资源水位最下面才是细分维度。我之前接手过一套几十个面板的大盘后来砍到五个面板值班同学的反馈反而是终于看得懂了。注意所有这些优化动作都建议先在测试环境验证再上生产。尤其是metric_relabel_configs的 drop 规则一旦正则写错把关键指标丢了是没法补回来的只能等新数据重新累积。我个人在实际搭这套东西的过程中最深的一点体会是监控系统的价值不在于装了多少组件而在于它产生的每一个告警都有人信、都有人处理。Prometheus 和 Grafana 提供了很好的工具底座但真正决定效果的是标签设计、阈值设定和告警治理这些人的部分。后面如果你有余力可以往两个方向继续深入一是把链路追踪Tracing和日志接进来形成指标、日志、链路三位一体的可观测体系二是研究远程存储和分片方案为数据量上量做准备。这两个方向的具体实践等我把手上的项目跑稳了再单独整理一篇。