1. 从“开箱即用”到“量身定制”为什么我们需要自定义指标在运维和开发领域Prometheus 早已不是个陌生的名字。它那套基于拉取的模型、多维数据模型和强大的查询语言 PromQL让系统监控变得前所未有的直观和强大。很多朋友在初次部署 Prometheus 后看着它自动抓取的node_exporter提供的 CPU、内存、磁盘等主机指标或者kube-state-metrics提供的 Pod、Deployment 状态都会觉得“监控已经搞定了”。但用不了多久你就会遇到一个瓶颈这些默认的、通用的指标无法回答你业务特有的问题。比如你的在线商城应用每秒成功创建的订单数是多少订单处理流水线中处于“待支付”状态的订单积压了多少缓存命中率是否健康又或者一个批处理任务当前处理到文件队列的第几个了这些才是真正决定你业务健康度、影响用户体验和营收的核心指标。Prometheus 自带的那些基础指标就像医院里的体温计和血压仪能告诉你病人是否还活着但无法诊断他得的是什么病病情严重到什么程度。自定义指标就是为你业务量身定制的“专项化验单”。这也是为什么在相关热搜和讨论中Prometheus总是和自定义指标、grafana安装部署、监控k8s或特定进程如前台进程、druid监控紧密联系在一起。大家的核心诉求已经从“把监控搭起来”进阶到了“监控我真正关心的东西”。本文将从一个实践者的角度彻底拆解在 Prometheus 生态中实现自定义指标监控的完整路径涵盖从指标设计、暴露、抓取到可视化的全流程并分享那些官方文档里不会写的“踩坑”经验。2. 自定义指标的四大核心实现模式实现自定义指标本质是让 Prometheus 能够采集到你应用内部的状态数据。根据应用的技术栈和部署环境主要有四种主流模式每种都有其适用的场景和“脾气”。2.1 模式一客户端库集成最直接、最强大这是最经典、最推荐的方式。Prometheus 官方提供了多种语言的客户端库如 Go、Java/JVM、Python、Ruby 等。它的工作原理是在你的应用程序代码中引入对应的库使用它提供的 API 来定义和更新指标同时启动一个独立的 HTTP 服务端通常是一个/metrics端点来暴露这些指标数据。为什么选择它功能完整支持 Prometheus 全部的指标类型Counter、Gauge、Histogram、Summary。维度自由可以轻松地为指标添加任意标签Label实现多维度的聚合与切片分析。性能内聚指标采集逻辑与业务代码在同一进程内没有额外的网络开销时效性最高。实操步骤与核心代码片段以 Go 语言为例首先引入客户端库go get github.com/prometheus/client_golang。package main import ( net/http github.com/prometheus/client_golang/prometheus github.com/prometheus/client_golang/prometheus/promhttp ) // 定义自定义指标 var ( // 定义一个计数器Counter用于统计订单创建总数 ordersCreated prometheus.NewCounter( prometheus.CounterOpts{ Name: shop_orders_created_total, Help: The total number of created orders., }, ) // 定义一个仪表盘Gauge用于记录当前购物车中的商品数量并添加用户标签 cartItems prometheus.NewGaugeVec( prometheus.GaugeOpts{ Name: shop_cart_items_current, Help: Current number of items in shopping cart., }, []string{user_id}, // 标签名称 ) ) func init() { // 在 init 函数中注册指标 prometheus.MustRegister(ordersCreated) prometheus.MustRegister(cartItems) } func main() { // 业务逻辑中更新指标 http.HandleFunc(/order/create, func(w http.ResponseWriter, r *http.Request) { // ... 创建订单的业务逻辑 ... ordersCreated.Inc() // 计数器加1 }) http.HandleFunc(/cart/add, func(w http.ResponseWriter, r *http.Request) { userId : r.URL.Query().Get(user_id) // ... 添加商品到购物车 ... cartItems.WithLabelValues(userId).Inc() // 针对特定用户的指标加1 }) // 暴露指标给 Prometheus 的端点 http.Handle(/metrics, promhttp.Handler()) http.ListenAndServe(:8080, nil) }注意指标命名应遵循[a-zA-Z_:][a-zA-Z0-9_:]*的规范通常使用_连接单词并以_total、_current、_seconds等后缀明确单位或类型。Help字符串务必清晰这是你未来理解这个指标含义的唯一文档。2.2 模式二独立导出器Exporter监控“黑盒”系统当你需要监控那些无法或不便修改源码的系统时导出器是唯一的桥梁。比如监控 MySQL、Redis、Kafka、硬件设备如通过 IPMI甚至是像wazuh监控文件删除、ftp监控、串口监控工具这类特定场景。导出器是一个独立的进程它主动去查询目标系统的状态通过 SQL、API、命令行等然后将查询结果“翻译”成 Prometheus 能够理解的指标格式并通过/metrics端点暴露出来。为什么选择它无侵入性不需要改动被监控系统的任何代码。生态丰富Prometheus 社区有海量的第三方导出器几乎覆盖了所有常见软件和中间件。自定义灵活你可以自己编写导出器将任何能获取到的数据转化为指标。以监控一个 Windows 目录的文件变更为例模拟 wazuh 场景虽然我们可以用wazuh这样的安全工具但理解其原理很重要。一个简单的自定义导出器思路是用 Python 的watchdog库监听D:\public目录然后使用 Prometheus 的 Python 客户端库暴露指标。# file_monitor_exporter.py from prometheus_client import start_http_server, Gauge import time from watchdog.observers import Observer from watchdog.events import FileSystemEventHandler # 定义指标 files_deleted Gauge(windows_public_files_deleted_total, Total files deleted in D:\public) files_renamed Gauge(windows_public_files_renamed_total, Total files renamed in D:\public) class FileChangeHandler(FileSystemEventHandler): def on_deleted(self, event): if not event.is_directory: files_deleted.inc() def on_moved(self, event): # 文件移动或重命名这里简单处理为改名 if not event.is_directory: files_renamed.inc() if __name__ __main__: # 在 8000 端口启动指标暴露服务 start_http_server(8000) path rD:\public event_handler FileChangeHandler() observer Observer() observer.schedule(event_handler, path, recursiveTrue) observer.start() try: while True: time.sleep(1) except KeyboardInterrupt: observer.stop() observer.join()运行这个脚本它就会在http://localhost:8000/metrics提供指标。然后在 Prometheus 的配置文件中添加一个针对localhost:8000的抓取任务即可。2.3 模式三Pushgateway用于短生命周期任务Prometheus 默认是拉取Pull模型但对于那些运行完就立即退出的批处理作业、定时脚本Cron Job或一次性任务它们没有常驻的 HTTP 服务让 Prometheus 来拉取。这时就需要 Pushgateway 作为中间桥梁。任务在结束时将指标推送到 PushgatewayPrometheus 再从 Pushgateway 拉取数据。为什么选择它解决拉取模型盲点是监控短生命周期任务的唯一标准方案。数据暂存在 Prometheus 抓取周期内数据由 Pushgateway 保管。重要注意事项这是最大的坑Pushgateway 的设计初衷不是用于监控长期运行的服务。如果你把一个常驻服务的指标也推送到 Pushgateway会导致指标过期无法感知服务挂了但 Pushgateway 里上次推送的指标还在Prometheus 会认为服务依然健康。失去 UP 状态Prometheus 无法判断数据源真实服务本身是否存活。混淆数据来源所有推到同一个 Pushgateway 的任务数据混杂在一起难以通过实例标签区分。正确使用姿势假设有一个每日运行的报表生成脚本daily_report.py#!/bin/bash # daily_report.py 内部逻辑 # ... 执行报表生成 ... REPORT_LINES1000 REPORT_DURATION120 # 使用 curl 将指标推送到 Pushgateway cat EOF | curl --data-binary - http://pushgateway.example.com:9091/metrics/job/daily_report/instance/$(hostname) # TYPE report_lines_total counter report_lines_total{typegenerated} $REPORT_LINES # TYPE report_duration_seconds gauge report_duration_seconds $REPORT_DURATION EOF在 Prometheus 中看到的指标将会自动附加上jobdaily_report和instancehostname的标签。2.4 模式四服务发现与动态抓取云原生环境必备在 Kubernetes、Docker Swarm 或云服务器自动伸缩组里服务的 IP 和端口是动态变化的。手动修改 Prometheus 配置来添加抓取目标是不现实的。这时就需要服务发现Service Discovery。为什么需要它实现自动化、动态的监控目标管理是云原生监控的基石。Kubernetes 下的配置示例Prometheus 通过kubernetes_sd_configs配置块可以自动发现 Kubernetes 中的 Node、Service、Pod、Endpoint 等资源。最常见的场景是监控 Pod。# prometheus.yml 片段 scrape_configs: - job_name: kubernetes-pods kubernetes_sd_configs: - role: pod # 发现所有 Pod relabel_configs: # 关键步骤只抓取那些有注解annotation声明了端口的 Pod - 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__ - action: labelmap regex: __meta_kubernetes_pod_label_(.)在你的应用 Pod 定义中只需要添加相应的注解Prometheus 就会自动发现并抓取apiVersion: v1 kind: Pod metadata: name: my-app annotations: prometheus.io/scrape: true prometheus.io/port: 8080 prometheus.io/path: /metrics spec: containers: - name: app image: my-app:latest ports: - containerPort: 8080这套机制完美解决了k8s部署prometheus监控和监控前台进程在K8s里就是Pod的动态发现问题。3. 指标类型深度解析选对类型事半功倍Prometheus 定义了四种核心指标类型理解它们的语义差异是设计出有效监控的关键。用错了类型不仅查询困难还可能得出错误结论。3.1 Counter计数器只增不减的累积值是什么一个单调递增的计数器。重启服务会被重置为0。典型用途请求总数、任务完成数、错误发生总数。核心操作.Inc()增加1或.Add(float64)增加指定值。PromQL 常用函数rate()increase()。永远不要直接使用 Counter 的裸值因为它一直在增长。我们关心的是增长率如QPS或一段时间内的增量。# 计算过去5分钟内每秒的平均订单创建速率 rate(shop_orders_created_total[5m]) # 计算过去1小时内创建的订单总数 increase(shop_orders_created_total[1h])3.2 Gauge仪表盘可任意变化的瞬时值是什么表示一个可以任意上下变化的数值。典型用途当前内存使用量、CPU温度、活跃连接数、队列长度如“待支付订单数”。核心操作.Set(float64)设置值.Inc().Dec().Add().Sub()。PromQL 常用函数直接查询、delta()变化量、predict_linear()预测。# 查看当前所有购物车的商品总数 sum(shop_cart_items_current) # 计算CPU温度在过去一小时的波动范围 max(node_hwmon_temp_celsius) - min(node_hwmon_temp_celsius)3.3 Histogram直方图与 Summary摘要统计分布两者都用于观察数据的分布情况特别是延迟、响应大小等。Histogram直方图客户端行为在代码中预定义好一组桶Bucket例如[0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10]秒。当记录一个观测值时如请求耗时0.12秒它会在这个值所属的桶及其之后所有更大的桶的计数器上加1。服务端输出会生成多个时间序列basename_bucket{leupper inclusive bound}小于等于该上界的观测值数量。basename_sum所有观测值的总和。basename_count观测值的总个数与_bucket{leInf}相等。优势可以在服务端通过PromQL灵活地聚合和计算分位数如P90P99。PromQL 计算分位数# 计算最近5分钟请求延迟的90分位数 histogram_quantile(0.90, rate(http_request_duration_seconds_bucket[5m]))Summary摘要客户端行为在客户端内存中计算流式分位数如P50 P90 P99和总和、总数。服务端输出直接输出预先计算好的分位数时间序列basename{quantileφ}以及_sum和_count。劣势无法在服务端聚合。如果你有10个服务实例你无法通过PromQL计算这10个实例整体的P99延迟只能分别看每个实例的。因此在可聚合性要求高的场景如监控分布式服务Histogram 是更优选择。如何选择需要跨实例、跨维度聚合计算分位数 →选择 Histogram。非常精确地控制客户端计算的分位数且不需要服务端聚合 →可以选择 Summary。监控资源使用如Go的GC暂停时间 →Summary 更常见。监控网络请求延迟 →Histogram 是行业标准。4. Prometheus 抓取配置实战与避坑指南定义和暴露了指标下一步是让 Prometheus 来抓取。prometheus.yml配置文件是核心。4.1 基础静态配置这是最简单的形式直接列出目标。scrape_configs: - job_name: custom-app static_configs: - targets: [app-server-1:8080, app-server-2:8080] labels: environment: production team: e-commercejob_name会成为所有从该任务抓取的指标的一个标签jobcustom-app。在static_configs下的labels会作为这些目标的通用标签附加到所有指标上。4.2 动态配置文件服务发现当目标列表经常变化但又没有成熟的服务发现系统时可以让目标列表来自一个外部文件Prometheus 会定期重载这个文件。scrape_configs: - job_name: file-sd-apps file_sd_configs: - files: - /etc/prometheus/targets/apps*.yaml refresh_interval: 5m # 每5分钟重新加载文件/etc/prometheus/targets/apps.yaml文件内容- targets: - 10.0.1.15:9090 - 10.0.1.16:9090 labels: env: staging修改这个 YAML 文件Prometheus 会自动更新抓取目标无需重启。这对于管理一批云服务器监控或物理机非常有用。4.3 抓取生命周期与 relabel_configs 魔法relabel_configs是 Prometheus 配置中最强大也最容易出错的部分。它在抓取动作发生前、后对标签进行操作。抓取生命周期简述服务发现生成一组“目标”每个目标有一组以__meta_开头的“元标签”。Relabeling抓取前对目标的元标签进行过滤、重命名、修改决定最终抓取谁__address__以及如何抓取__scheme__,__metrics_path__。抓取向目标发起 HTTP 请求获取指标数据。Metric Relabeling抓取后对抓取到的指标本身的标签进行二次处理可以用于删除不必要的标签、重命名等。一个经典避坑案例过滤特定指标假设你使用一个第三方导出器它暴露了上百个指标但你只关心其中几个全抓过来会造成存储浪费。可以在metric_relabel_configs中使用drop动作。scrape_configs: - job_name: node static_configs: - targets: [node-exporter:9100] metric_relabel_configs: # 丢弃所有以 node_network_ 开头的指标如果不关心网络详情 - source_labels: [__name__] regex: node_network_.* action: drop # 只保留 CPU 和内存相关的指标 - source_labels: [__name__] regex: node_cpu_.*|node_memory_.* action: keep regex: node_cpu_.*|node_memory_.*__name__是一个特殊的标签它代表指标名称本身。4.4 抓取间隔与超时设置scrape_interval和scrape_timeout是全局或 job 级别的配置。global: scrape_interval: 15s # 默认15秒抓取一次 evaluation_interval: 15s # 规则评估间隔 scrape_configs: - job_name: fast-app scrape_interval: 5s # 对这个job每5秒抓取一次 scrape_timeout: 4s # 抓取超时时间必须小于scrape_interval static_configs: [...]经验之谈scrape_timeout必须显著小于scrape_interval否则一次超时的抓取可能会“占用”下一次抓取的时间窗口导致数据点丢失。对于关键应用可以适当调短scrape_interval如5s但要做好 Prometheus 服务器存储和性能的评估。5. 数据可视化与告警从指标到洞察采集到的数据需要通过 Grafana 变成直观的图表并通过 Alertmanager 在异常时发出告警。5.1 使用 Grafana 创建仪表盘Grafana 连接 Prometheus 数据源后核心就是编写 PromQL 查询。一个复杂的业务监控面板示例假设我们要监控订单系统。QPS 图表rate(shop_orders_created_total[5m])当前待处理订单堆积量Gaugeshop_orders_pending_current订单创建成功率rate(shop_orders_created_total{statussuccess}[5m]) / rate(shop_orders_created_total[5m]) * 100订单处理延迟分布P99histogram_quantile(0.99, rate(shop_order_process_duration_seconds_bucket[5m]))Grafana 使用技巧变量Variables创建如$environment、$service之类的变量实现仪表盘动态过滤。重复面板Repeating Panels如果一个面板需要为每个服务实例复制一份可以使用基于标签值的重复功能。注释Annotations将部署、重启等事件作为注释标记在图表上便于关联分析。5.2 配置 Prometheus 告警规则告警规则定义在独立的*.rules.yml文件中并在prometheus.yml中通过rule_files加载。# prometheus.yml rule_files: - /etc/prometheus/rules/*.rules.yml # /etc/prometheus/rules/order.rules.yml groups: - name: order-service rules: # 规则1订单创建QPS骤降 - alert: OrderCreationRateDropped expr: rate(shop_orders_created_total[5m]) 10 for: 2m # 持续2分钟低于阈值才触发 labels: severity: critical service: order annotations: summary: 订单创建速率过低 (实例 {{ $labels.instance }}) description: 订单创建速率已降至 {{ $value }} 个/秒持续2分钟以上。 runbook: http://wiki.internal/runbooks/order-creation-drop # 规则2订单处理延迟过高 - alert: OrderProcessLatencyHigh expr: histogram_quantile(0.99, rate(shop_order_process_duration_seconds_bucket[5m])) 5 for: 5m labels: severity: warning service: order annotations: summary: 订单处理P99延迟过高 description: 订单处理P99延迟为 {{ $value }} 秒超过5秒阈值。expr是 PromQL 表达式结果为布尔值True/False。for子句用于避免抖动导致的误告。labels会附加到告警上用于在 Alertmanager 中做路由和分组。annotations包含更详细的信息会出现在告警通知中。5.3 Alertmanager 配置与告警去噪Prometheus 负责“触发”告警Alertmanager 负责“管理”告警去重、分组、静默、抑制并通过不同渠道邮件、钉钉、Slack、Webhook等发送。关键概念分组Grouping将同一时间段内、相似性质的告警合并成一条通知。例如同一个微服务的10个实例同时宕机你希望收到一条“XX服务10个实例不可用”的通知而不是10条。抑制Inhibition如果发生了更严重的告警就忽略相关的次要告警。例如整个机房断电严重告警那么该机房内所有服务器宕机次要告警的通知就应该被抑制。静默Silence临时关闭特定标签的告警通知用于计划内的维护。一个实用的邮件路由配置片段# alertmanager.yml route: group_by: [alertname, cluster, service] # 按告警名、集群、服务分组 group_wait: 30s # 同一组告警等待30s看是否有更多告警进来一起发送 group_interval: 5m # 同一组告警如果持续未解决每5分钟重发一次通知 repeat_interval: 12h # 同一个告警如果持续未解决每12小时重复通知一次 receiver: default-email routes: - match: severity: critical receiver: critical-pagerduty # 严重告警走PagerDuty continue: false # 匹配后不再继续向下路由 - match: severity: warning receiver: warning-slack # 警告告警发Slack receivers: - name: default-email email_configs: - to: team-alertsexample.com from: alertmanagerexample.com smarthost: smtp.example.com:587 auth_username: user auth_password: password headers: Subject: [ALERT] {{ .GroupLabels.alertname }} on {{ .GroupLabels.instance }}合理的分组和路由配置是避免“告警风暴”淹没团队的关键。