在前三篇文章中我们建立了可观测性的理论框架理解了 LGTM 栈的整体架构并掌握了 OpenTelemetry 的统一插桩标准。但指标监控的“最后一公里”仍然需要深入 Prometheus——它是云原生指标监控的事实标准也是 LGTM 栈中 Mimir 的数据来源。本文从 Prometheus 的核心架构出发系统讲解四种指标类型的设计与使用场景、Exporter 开发实战、以及 Kubernetes 服务发现配置帮你掌握从“指标设计”到“指标采集”的完整技能。一、Prometheus 核心架构Prometheus 是一个基于 Pull 模型 的监控系统——它主动从目标服务拉取指标数据而非等待服务推送。这种设计让服务发现和健康检查变得简单。核心组件Prometheus Server核心服务负责抓取、存储和查询指标数据Exporters暴露指标的程序Node Exporter 暴露主机指标应用自身暴露业务指标Alertmanager处理告警规则的分组、抑制和通知服务发现Service Discovery 动态发现监控目标Kubernetes、Consul、文件等Pull 模型的优势服务无需感知 Prometheus 的存在Prometheus 可以通过健康检查判断目标是否可用便于水平扩展和联邦部署。二、四种指标类型的设计与使用场景Prometheus 提供了四种指标类型每种类型服务于不同的监控目的Counter计数器 只增不减的累计值。用于统计请求总数、错误总数、处理的任务数等。必须单调递增不能用于递减或归零的场景。典型用法http_requests_total。Gauge仪表盘 可增可减的瞬时值。用于测量当前并发数、内存使用量、温度、队列长度等。典型用法go_goroutines、http_requests_in_flight。Histogram直方图 对观测值进行采样和分桶统计。用于测量请求延迟分布、响应大小等。Histogram 自动生成 _count、_sum 和 _bucket 三个指标。典型用法http_request_duration_seconds。Summary摘要 类似 Histogram可计算分位数。与 Histogram 的主要区别在于分位数在客户端计算。建议优先使用 Histogram因为它更灵活且支持聚合。指标命名规范推荐采用 _ 格式。例如 order_service_http_requests_total、api_gateway_request_duration_seconds。三、自定义 Exporter 开发实战当需要监控的应用本身不暴露 /metrics 端点时可以编写自定义 Exporter。Go 语言是 Exporter 开发的首选。3.1 项目初始化mkdircustom-exportercdcustom-exporter go mod init custom-exporter go get github.com/prometheus/client_golang/prometheus go get github.com/prometheus/client_golang/prometheus/promhttp3.2 定义和注册指标packagemainimport(net/httpgithub.com/prometheus/client_golang/prometheusgithub.com/prometheus/client_golang/prometheus/promautogithub.com/prometheus/client_golang/prometheus/promhttp)var(// Counter累计指标ordersCreatedpromauto.NewCounter(prometheus.CounterOpts{Name:orders_created_total,Help:Total number of orders created,},)// Gauge瞬时指标ordersInFlightpromauto.NewGauge(prometheus.GaugeOpts{Name:orders_in_flight,Help:Current number of orders being processed,},)// Histogram分布指标orderDurationpromauto.NewHistogram(prometheus.HistogramOpts{Name:order_duration_seconds,Help:Order processing duration in seconds,Buckets:[]float64{0.01,0.05,0.1,0.5,1,2,5},},)// CounterVec带标签的指标ordersByStatuspromauto.NewCounterVec(prometheus.CounterOpts{Name:orders_by_status_total,Help:Total number of orders by status,},[]string{status},))funcmain(){// 暴露 /metrics 端点http.Handle(/metrics,promhttp.Handler())http.ListenAndServe(:9090,nil)}3.3 采集业务数据并更新指标funcprocessOrder(){ordersInFlight.Inc()// 增加并发计数deferordersInFlight.Dec()// 处理完成后减少start:time.Now()// 业务逻辑...duration:time.Since(start).Seconds()ordersCreated.Inc()// 累计订单数orderDuration.Observe(duration)// 记录耗时ordersByStatus.WithLabelValues(completed).Inc()// 按状态统计}四、Kubernetes 服务发现配置在 Kubernetes 环境中Pod 动态创建和销毁静态配置无法应对这种变化。Prometheus 的 Kubernetes 服务发现 机制可以自动发现集群中的 Pod、Service、Node 等资源。4.1 基本配置prometheus.ymlscrape_configs:# 自动发现所有 Pod-job_name:kubernetes-podskubernetes_sd_configs:-role:podrelabel_configs:# 只采集带有 prometheus.io/scrape: true 注解的 Pod-source_labels:[__meta_kubernetes_pod_annotation_prometheus_io_scrape]action:keepregex:true# 从注解中读取指标路径和端口-source_labels:[__meta_kubernetes_pod_annotation_prometheus_io_path]action:replacetarget_label:__metrics_path__regex:(.)-source_labels:[__address__,__meta_kubernetes_pod_annotation_prometheus_io_port]action:replaceregex:([^:])(?::\d)?;(\d)replacement:$1:$2target_label:__address__4.2 ServiceMonitor推荐方式在 Prometheus Operator 生态中ServiceMonitor 是更声明式的配置方式apiVersion:monitoring.coreos.com/v1kind:ServiceMonitormetadata:name:order-servicespec:selector:matchLabels:app:order-serviceendpoints:-port:metricspath:/metricsinterval:15sServiceMonitor 将监控目标声明为 Kubernetes 资源与 Prometheus 的配置解耦更适合 GitOps 工作流。五、小结Prometheus 核心架构基于 Pull 模型通过服务发现动态发现目标四种指标类型Counter累计值、Gauge瞬时值、Histogram分布统计、Summary客户端分位数指标命名规范_Exporter 开发使用 prometheus/client_golang 定义和注册指标暴露 /metrics 端点Kubernetes 服务发现通过 kubernetes_sd_configs 自动发现 Pod结合 relabel 进行精细控制ServiceMonitorPrometheus Operator 中的声明式监控目标配置