Prometheuses

Relabel 概述 如果你把 Prometheus 想象成一个正在收集信息的侦探，那么 Relabeling 就是这位侦探在收集信息（指标/Metrics）之前或之后，对这些信息的“身份标签”进行修改、添加或删除的操作。 简单来说，Relabeling 的核心目的就是控制和修改你的指标上的标签 (Labels)。 核心目的 控制抓取 (Service Discovery & Filtering)：决定哪些指标应该被抓取 (Scrape)，哪些应该被忽略。 标准化标签 (Normalization)：将那些混乱、不规范或冗余的标签转换成你想要的样子。 丰富信息 (Enrichment)：添加有用的元数据（如集群名、环境名）到指标上。 通俗比喻 想象你是一家大公司的邮件分拣员。 概念 邮件分拣的比喻 Prometheus Relabeling 原始地址 信封上写着“王小姐，住在 3 号楼 101 室” 服务发现（Service Discovery）提供的原始标签（如 __address__=10.1.1.5:8080, __meta_kubernetes_pod_name=myapp-7b4d-1234） Relabeling 规则 “把所有写着‘3 号楼 101 室’的，都改成‘A 区域研发部’，然后把所有发件人是‘老李’的邮件都扔掉。” 配置文件中的 relabel_config 块 新标签 邮件上贴了新标签：“区域: A 区域研发部” 最终抓取到的指标上的新标签（如 service=myapp, cluster=prod-asia） Relabel 流程 relabel_configs 和 metric_relabel_configs 是 Prometheus 配置中两个非常重要但作用阶段不同的配置块，它们的关系和先后顺序可以概括如下： 1. 它们的关系：作用于不同的阶段 配置块 作用对象 作用阶段 目的 relabel_configs 目标 (Targets) 服务发现 (Service Discovery) 之后，实际抓取 (Scrape) 之前。 用于修改目标的地址、端口，或为目标添加/删除/修改标签（例如 instance, job 等），以决定 是否抓取 该目标。 metric\_relabel\_configs 指标 (Metrics) 实际抓取 (Scrape) 之后，存储 (Storage) 之前。 用于修改抓取到的指标的名称或标签（例如 code, method 等），以决定 是否保留 该指标。 简单来说： ...

配置文件结构 参考文档：https://prometheus.io/docs/prometheus/latest/configuration/configuration/ # 全局配置段，包括抓取间隔和评估间隔等。 global: ... # 指定需要被抓取的目标，支持服务发现、静态配置等方式。 scrape_configs: ... # 告警规则定义 rule_files: ... # 定义报警发往何处 # 定义用于触发警报的规则。这些规则基于时间序列数据的评估，当满足特定条件时，将会触发相应的警报。 alerting: ... # 允许将时间序列数据远程写入其他存储后端，如 Cortex、Thanos 等。 remote_write: ... # 配置 Prometheus 实例以从其他存储后端读取时间序列数据。 remote_read: ... # 指定 Prometheus 的本地存储选项，例如数据的保存路径、保留策略等。 storage: ... global global: scrape_interval: 1m # 多久 Pull 一次 Targets 上的指标数据（向 /metrics 发送 GET） scrape_timeout: 10s # Pull Targets 的超时时间，超时则无法获得本次指标数据（Target 显示 DOWN） evaluation_interval: 1m # 告警规则和记录规则的评估间隔时间。 external_labels: # 所有由该 Prometheus 实例抓取和记录的时间序列都会自动带上这些标签。 # 这些标签来区分来自不同 Prometheus 实例的指标数据； # 使用 Thanos 或 Cortex 等系统将多个 Prometheus 实例的数据聚合到一个中心存储时，这些标签能确保所有数据点的来源是唯一且可识别的。 prometheus: kubesphere-monitoring-system/k8s prometheus_replica: prometheus-k8s-1 什么是告警规则和记录规则？ ...

Metric 类型 Prometheus 客户端库主要提供四种主要的 metric 类型： Counter 计数器 一种只能累加的 metric，其值从0开始只能增加，不会减少；重启进程后，会被重置 典型应用：http的请求数、下单数、结束的任务数、出现的错误数等等。 示例：查询 http_requests_total{method=”get”, job=”Prometheus”, handler=”query”} 返回 8，10 秒后，再次查询，则返回 14。 常见操作： 通常使用 rate() 或 irate() 函数来计算其变化率（例如，每秒的请求数）。 通常，Counter的总数并没有直接作用，而是需要借助于rate、topk、increase和irate等函数来生成样本数据的变化状况（增长率）； rate(http_requests_total[2h])，获取2小内，该指标下各时间序列上的http总请求数的增长速率； 增长速率是指单位时间内增长的数量 topk(3, http_requests_total)，获取该指标下http请求总数排名前3的时间序列； irate(http_requests_total[2h])，高灵敏度函数，用于计算指标的瞬时速率； 基于样本范围内的最后两个样本进行计算，相较于rate函数来说，irate更适用于短期时间范围内的 变化速率分析； Gauge 仪表盘 一个可增减的值，可以随时间增加或减少，用于存储有着起伏特征的指标数据。 典型应用：内存的使用量、CPU 的当前温度、队列中的消息数、当前并发请求数等、运行的 goroutines 的个数。 示例：go_goroutines{instance=”172.17.0.2”, job=”Prometheus”} 返回值 147，10 秒后返回 124。 Gauge用于存储其值可增可减的指标的样本数据，常用于进行求和、取平均值、最小值、最大值等聚合计算；也会经常结合PromQL的predict_linear和delta函数使用； predict_linear(v range-vector, t, scalar) 函数可以预测时间序列v在t秒后的值，它通过线性回归的方式来预测样本数据的Gauge变化趋势； delta(v range-vector) 函数计算范围向量中每个时间序列元素的第一个值与最后一个值之差，从而展示不同时间点上的样本值的差值； delta(cpu_temp_celsius{host="web01.xiangzheng.com"}[2h])，返回该服务器上的CPU温度与2小时之前的差异； Histogram 直方图 可以理解为柱状图，它会在一段时间范围内对数据进行采样，并将其计入可配置的 bucket 之中，用于分组及统计。 暴露三个指标：_bucket, _sum, _count。 Histogram 更适合监测一个一系列事件的持续时间或大小的分布情况； 典型应用：HTTP 请求延迟、数据库查询时间、响应体大小。 常见操作： 用于计算分位数（如 P95、P99），通常配合 histogram_quantile() 函数使用。 示例：API 请求处理延迟 ...

相关 Exporter 对于一个完整的 K8s 监控方案，通常会部署以下几个核心组件： 组件名称 监控目标 监控粒度 指标前缀 kube-state-metrics K8s 对象状态 (Pod, Deployment, Node 等) 集群状态 kube_ Node Exporter 节点操作系统和硬件 基础设施/节点 node_ cAdvisor (通过 Kubelet) 容器的资源使用 容器 container_ / pod_ 核心组件 /metrics K8s 控制平面 (API Server, Scheduler 等) 集群控制面 应用 Exporter 应用程序和中间件 (Redis, Kafka, etc.) 应用 许多人会使用 kube-prometheus-stack (一个 Helm Chart) 来部署一整套监控方案，它包含了 Prometheus Operator、Prometheus、Alertmanager、Node Exporter 和 kube-state-metrics 等所有必要的组件。 kube-state-metrics (KSM) 功能: 收集 Kubernetes 对象的健康和状态指标，例如 Pod、Node、Deployment、Service、Job 等的状态信息。 指标示例: Pod 的状态（Running, Pending, Failed）、Deployment 的可用副本数、资源请求和限制 (Request/Limit) 等。 特点: 不监控 Pod 或 Node 本身的资源使用情况，而是监控 K8s API Server 中对象的状态。 Node Exporter 功能: 收集 Kubernetes 集群中每个节点（Node）的底层操作系统和硬件指标。 指标示例: CPU 使用率、内存使用率、磁盘 I/O、网络带宽/延迟、文件系统健康状况等。 部署方式: 通常以 DaemonSet 的形式部署，确保每个节点上都有一个实例运行。 cAdvisor (Container Advisor) 功能: 容器资源使用情况和性能分析代理。它专门为容器构建，并收集机器上所有运行容器的系统指标。 特点: 在 K8s 中，cAdvisor 已经集成到 kubelet 二进制文件中，因此通常不需要单独部署。Prometheus 可以直接从 Kubelet 的 /metrics 或 /metrics/cadvisor 端点获取这些容器级别的指标。 各种中间件/应用 Exporter 例如：Redis Exporter、MySQL Exporter、Kafka Exporter、JMX Exporter（用于 JVM 应用）等。 功能: 收集特定应用或中间件的内部运行指标。 Blackbox Exporter 功能: 用于外部探测（External Probing）和黑盒监控，检查端点（如 HTTP/S、TCP、ICMP、DNS）的可用性和延迟。 用途: 监控 Service 或 Ingress 暴露的外部服务的健康状况。 Kubernetes Control Plane Metrics K8s 的核心组件（如 kube-apiserver、kube-controller-manager、kube-scheduler、etcd）本身会暴露符合 Prometheus 格式的 /metrics 端点。这些指标直接从组件暴露，不需要额外的 Exporter。