三大支柱与 Prometheus 指标系统

• agent mode 与 gateway mode 的差异
• agent mode 的部署形态
• 适用场景

OpenTelemetry Collector 以 agent mode 部署时，作为守护进程（DaemonSet）与工作负载同节点运行，每个节点一个 Collector 实例，采集本节点上应用/容器发出的 OTLP 遥测数据，经本地处理（过滤、批处理、采样）后转发到后端或上层 gateway。agent mode 的架构特点是"就近采集、本地处理、轻量转发"：agent 贴近数据源，降低网络传输与延迟，通过本地处理（如 tail-based sampling、batch、filter）先做降噪再转发，减少后端负载。适用场景：大规模集群中指标/日志/追踪从一个节点采集，agent 本地先压缩、采样、过滤，配合 gateway 做聚合与路由；也适合需要 tail-based sampling 的场景（agent 汇聚同节点调用链）。agent 与 gateway 常配合使用：agent 负责采集与预处理，gateway 负责聚合、去重、路由到多个后端。

agent mode 的核心价值是"采集与预处理前置"：把负载从后端平摊到节点，就近处理降低传输成本，并保留采样所需的本地上下文。适用于节点多、数据量大、需要本地降噪的场景。

• OTLP receiver 的作用
• 接收协议与解析
• 处理后进入 pipeline

OTLP（OpenTelemetry Protocol）receiver 是 Collector 的入口组件，负责接收 OTLP 格式的遥测数据（traces、metrics、logs）。它监听指定端口（默认 gRPC 4317、HTTP 4318），按 OTLP 协议解析数据并转换为 Collector 内部的数据模型（pdata），随后交付给 pipeline 中的 processors 与 exporters。OTLP receiver 支持 gRPC 与 HTTP 两种传输，支持压缩、TLS 与认证（如 mTLS）。处理上，receiver 只负责"接收与解析"，真正的处理（过滤、采样、批处理、重命名）由后续 processors 完成，处理后的数据由 exporters 发送到后端。OTLP 是 OpenTelemetry 生态的标准协议，因此 Collector 与 SDK、不同 Collector 之间都用 OTLP 互通，OTLP receiver 是统一接入的通用入口。

OTLP receiver 是"数据入口"，职责是接收与解析 OTLP 并转入内部模型，处理逻辑全在 processors。理解 OTLP receiver 的关键是"协议统一"——OTLP 让异构数据源经统一入口进入 pipeline。

• pipeline 的三个组件
• 配置与串联方式
• 数据流模型

OpenTelemetry Collector 的 pipeline 由 receivers、processors、exporters 三级组成，通过配置串联。配置中 receivers 定义数据入口（如 otlp、jaeger、prometheus），processors 定义数据处理（如 batch、filter、memory_limiter、tail_sampling），exporters 定义数据出口（如 otlp、prometheus、jaeger、loki）。service.pipelines 中声明 pipeline，把三者按路径串联：receivers: [otlp]、processors: [batch, memory_limiter]、exporters: [prometheus]，表示数据从 otlp 接收，经 batch 与 memory_limiter 处理，导出到 prometheus。pipeline 可按信号类型划分（traces/metrics/logs 各自独立 pipeline），同一 receiver 可被多个 pipeline 引用，同一 exporter 也可被多个 pipeline 复用。数据流是"receiver → processors（按序）→ exporter"，processors 顺序即配置顺序，可对数据做过滤、聚合、采样、重命名等。

pipeline 的本质是"数据流的声明式装配"：receivers 定义入口、processors 定义处理链、exporters 定义出口，service.pipelines 把它们串成一条条管道。配置清晰、可复用的关键是按信号类型拆分 pipeline 并复用组件。

• parent-child 关系
• span link 的语义
• 适用场景

parent-child 关系描述 span 的调用层级：一个 span 由父 span 发起，形成树状调用链，父子关系通过 trace_id 相同、parent_span_id 关联确定，用于表达"请求的因果调用顺序"。span link 则用于关联"非父子、但有业务关联"的 span，它不建立树状层级，只是把两个 span 关联起来（link 指向另一个 span 的 trace_id+span_id），常见于消息队列解耦、异步任务、跨批次等"无法用父子关系表达"的场景。区别：parent-child 是严格层级（每个 span 一个父），表达调用栈；link 是扁平关联（一个 span 可有多个 link），表达业务关联。适用场景：parent-child 用于同步调用链（HTTP/RPC 请求）；span link 用于消息队列（生产与消费解耦）、并发 fan-out、批处理任务、跨 trace 关联等。例如生产一条消息的 span 与消费该消息的 span 之间用 link 关联，而非父子。

核心区别是"层级 vs 关联"：parent-child 表达树状的因果调用，link 表达扁平的业务关联。当调用关系无法用"一个父"表达时（MQ、异步、跨 trace），就用 link。

• semantic conventions 的作用
• 统一命名规范
• 跨信号的一致性

OpenTelemetry 的 semantic conventions（语义约定）定义了跨语言、跨信号（metrics、logs、traces）的统一属性命名规范。它规定了通用属性（如 service.name、service.namespace、deployment.environment）、HTTP 属性（http.request.method、http.response.status_code）、网络属性（server.address、server.port）、数据库属性等，统一命名以点分短横线格式（如 http.request.method）。其价值在于：一是可移植性——不同语言、不同 SDK 产生的数据属性名一致，便于统一查询与告警；二是跨信号关联——同一请求的 trace、metric、log 使用相同属性（如 service.name、trace_id），可打通三信号；三是可观测性工具（如仪表盘、告警规则）可以基于稳定命名复用。语义约定由社区维护、版本化，采用时遵循其命名与类型约定，避免各自为政导致数据不可互通。

semantic conventions 是"可观测性的共同语言"：统一命名让跨语言、跨信号的数据可聚合、可关联、可复用。核心是"约定优于配置"，用标准属性名换取互通性。

• tail-based sampling 的原理
• 保留完整调用链
• 成本控制

tail-based sampling（尾部采样）是"先采集、后采样"：采样器在 span 全部（或接近全部）结束后，根据整条 trace 的完整信息（时长、错误、状态码、业务属性）决定是否保留整条 trace。它通常在 Collector 的 agent/gateway 端实现（tail_sampling processor），先按 trace_id 聚合同一 trace 的 span，待 trace 结束（或超时窗口）后按策略判断：保留异常/慢请求/高价值 trace（如含错误、延迟超阈值、特定服务），丢弃低价值 trace。这样能"保留完整调用链"——因为采样在 trace 完成后进行，保留的是整条 trace 的所有 span，而非随机丢 span。成本控制上，通过采样策略（如只保留 1% 正常请求 + 100% 错误请求）大幅降低存储与后端负载，同时保证关键链路完整。代价是内存与延迟（等待 trace 结束），需配置等待窗口与内存上限。

tail-based sampling 的核心是"用完整信息换取采样质量"：基于 trace 全貌决定保留，保留完整链、丢弃低价值，兼顾"完整性与成本"。与 head-based（随机丢）不同，tail-based 能保证异常链完整。

• Histogram 与 Summary 的存储与聚合方式
• 分位数计算位置
• 误差与存储开销取舍

Histogram 与 Summary 都用于统计观测值的分布，但实现不同。Histogram 在客户端把观测值累积到预定义的 bucket 计数器，服务端（Prometheus）用 histogram_quantile 从 bucket 计算分位数；Summary 在客户端直接计算分位数（如 p50/p99）并上报，服务端无法再聚合。因此：Histogram 是服务端聚合（可跨实例聚合、分位数可再算），Summary 是客户端聚合（分位数就地计算、不可跨实例聚合）。误差上，Histogram 的分位数是估算（依赖 bucket 边界，bucket 越细越准），Summary 是精确计算（客户端真实分位数）。存储开销上，Histogram 每个 bucket 一个时间序列，bucket 越多开销越大；Summary 上报固定分位数，开销相对固定。取舍：需要跨实例聚合分位数（如聚合多个 Pod 的 p99）时选 Histogram；已在客户端精确计算且无需聚合时选 Summary。现代实践倾向 Histogram（可聚合、可调 bucket）。

核心差异是"聚合在哪"：Histogram 把分布信息传给服务端可再聚合，Summary 在客户端算好不可再聚合。分位数误差与存储开销是 bucket 数量的权衡，Histogram 更灵活。

• node-exporter 与 kube-state-metrics 的分工
• 典型指标用途
• 标签基数规避

node-exporter 采集节点层面的资源指标（CPU、内存、磁盘、网络），把节点视为"主机"监控，如 node_cpu_seconds_total（节点 CPU 使用累计）、node_filesystem_avail_bytes（文件系统可用字节）；kube-state-metrics 采集 Kubernetes 对象状态（Deployment、Pod、Service、Node 的期望/实际状态），把"资源的声明与运行状态"暴露为指标，如 kube_deployment_status_replicas_available（Deployment 可用副本数）、kube_pod_container_resource_requests（Pod 容器的资源请求量）。分工：node-exporter 面向"节点/资源层"，kube-state-metrics 面向"对象/编排层"，二者配合形成完整 K8s 监控。标签基数规避：kube-state-metrics 按对象生成指标，标签数量随对象数增长（如每个 Pod 一组），高基数标签（如 Pod 名、随机 ID、高基数 label）会导致指标爆炸。规避方法：限制暴露的 label（relabel 丢弃高基数标签）、只保留必要标签、用 --metric-labels-allowlist 控制聚合标签、避免纳入随机唯一标识、按需聚合到低基数维度。

分工的本质是"监控对象不同"：node-exporter 看节点资源，kube-state-metrics 看对象状态。标签基数规避的核心是"只保留有聚合价值的低基数标签"，高基数标签（Pod 名/随机 ID）要丢弃或聚合。

• transform processor 的作用
• 字段级转换能力
• 过滤与重命名

transform processor 是 OpenTelemetry Collector 中用于对遥测数据做字段级转换、过滤与重命名的处理器。它基于 OTTL（OpenTelemetry Transformation Language）编写规则，在 pipeline 中按上下文（context：resource、span、metric、log、attribute）对数据操作。可做的转换包括：重命名/删除/设置 attribute（如 set(attributes["env"], "prod")）、重命名 metric、过滤标签或数据点、类型转换与聚合、脱敏（如清空 URL 敏感字段）。过滤能力通过 where 条件选择符合条件的数据再操作，或用单独的 filter processor 丢弃数据。transform processor 常用于：统一属性命名、脱敏、增加归一化字段、清洗脏数据。它是 pipeline 中"数据整形"的通用工具，替代了过去需要写自定义 processor 的场景。

transform processor 用 OTTL 声明式地做数据转换，核心价值是"在不改代码的情况下灵活整形遥测数据"。字段级转换、过滤、脱敏都通过规则表达式完成，适合在 agent 侧就近清洗。

• Exemplar 的概念
• 指标与 Trace 关联
• 告警跳转调用链

Exemplar（示例）是挂在指标数据点上的"样本标签"，它把"某个具体观测值"与产生该值的 trace/span 关联起来。Exemplar 携带 trace_id、span_id 以及观测时间，附加在指标的某个数据点（如 histogram 的某个 bucket、counter 的某个采样）上。这样，当指标（如延迟 p99）出现异常时，Exemplar 记录了"其中最慢的请求"对应的 trace_id/span_id，结合 trace 后端即可快速定位到那条具体调用链。在告警场景，当指标告警触发时，可查询该指标数据点的 Exemplar，取出 trace_id，跳转到对应 trace 做深入分析（定位慢在哪个服务、哪个环节）。Exemplar 的价值是"把聚合指标与单个请求打通"，回答"指标异常时到底哪个请求有问题"。OTel 的 SDK 会自动在指标数据点附加 Exemplar，导出时需后端支持 Exemplar 存储。

Exemplar 是"指标→trace"的桥梁：聚合指标回答"整体如何"，Exemplar 回答"哪条请求最典型"。告警后借助 Exemplar 的 trace_id 直达调用链，大幅缩短排障路径。

• 各方案架构与定位
• 长期存储与全局查询
• 选型权衡

四者都是 Prometheus 的长期存储/全局查询扩展方案。Thanos 基于 sidecar/receiver 把 Prometheus 数据上传到对象存储，通过 Querier 提供跨集群全局查询与 downsampling，组件多、灵活但运维复杂；Cortex 是云原生多租户的 Prometheus 兼容方案，支持长期存储与全局查询，但已逐步演进为 Mimir；Mimir 是 Grafana 对 Cortex 的继任，功能完整、多租户、水平扩展、支持长期存储与全局查询，运维相对简单；VictoriaMetrics 是高性能、单二进制、资源占用低的方案，支持长期存储与全局查询（cluster 版），延迟低、易部署。选型权衡：需要多租户与成熟托管选 Mimir，需要极简高性价比与高性能选 VictoriaMetrics，需要与现有对象存储深度集成可用 Thanos，历史遗留 Cortex 可迁移到 Mimir。全局查询与长期存储是共同目标，差异在架构复杂度、多租户、性能与运维成本。

选型核心是"长期存储 + 全局查询 + 运维成本"的平衡：Mimir 功能全但重，VictoriaMetrics 轻量高性能，Thanos 灵活但组件多。多租户、性能、部署成本是主要考量。

• eBPF 可观测性的原理
• 无侵入采集能力
• 服务拓扑自动生成

eBPF 可观测性通过在内核挂载程序，无侵入地观测网络与系统调用，无需插桩应用代码。Pixie 与 Cilium Hubble 都基于 eBPF：Pixie 在节点上采集请求级数据（HTTP/gRPC/PGSQL 等协议解析、应用负载、网络流），无需 sidecar 或埋点；Hubble 基于 Cilium 的 eBPF 数据路径，采集网络流量、L3/L4 流与 DNS 请求，并生成服务依赖图。落地价值：一是无侵入——不修改应用、不注入 sidecar，即可观测 HTTP/gRPC/DNS 请求与内核指标（如网络丢包、重传、连接状态）；二是服务拓扑自动生成——eBPF 捕获流量，自动构建服务间依赖图（谁调用谁、调用频率、延迟、错误），无需人工维护依赖；三是低开销——eBPF 在内核层过滤，按需采集，性能开销低。应用场景：K8s 服务拓扑可视化、无侵入排障、网络路径与 DNS 问题定位。

eBPF 的落地价值是"无侵入 + 自动拓扑"：靠内核观测取代应用埋点，自动生成服务依赖图，降低插桩成本并覆盖无法埋点的场景。适合大规模、快速上手与网络层排障。

• 计数器与 rate/irate/increase 的用法
• 重启导致的计数归零
• 突刺规避

Prometheus 计数器（counter）是单调递增的累计值，查询时应使用 rate/irate/increase 计算速率而非直接读取原始值。rate 计算窗口内平均速率（平滑，适合长期趋势与告警），irate 计算窗口内最后两个样本的瞬时速率（对突刺敏感，适合实时尖峰展示），increase 计算窗口内增量。用法：rate(counter[5m]) 得到每秒速率，increase(counter[5m]) 得到增量。进程重启时计数器归零，导致 rate 出现"看起来下降"或突刺。规避方法：一是查询时用 increase(...) 的窗口内包含重启点的处理，或对计数器做 reset() 处理（一些查询工具支持）；二是用 rate 的窗口平均可平滑重启造成的瞬时跳变；三是在 exporter 侧用生命周期号标记（如 process_start_time_seconds）排除重启归零干扰；四是避免把计数器归零误判为"流量下降"，结合 rate 窗口与告警规则设定合理范围。实际中 rate 的窗口平均对重启归零已有一定容忍，irate 更易受重启影响。

计数器必须用 rate/irate/increase 读取，rate 平滑、irate 敏感、increase 给增量。重启归零的规避核心是"用窗口平均 + 生命周期标记 + 合理告警"，避免把归零/突刺误判为业务异常。

• 事件数据的定位
• 与指标/日志/追踪的关系
• 工程价值

事件（events）数据是"系统在某个时刻发生了什么"的结构化记录，是可观测性四支柱（指标、日志、追踪、事件）之一。事件与日志相似但更结构化：它有时间戳、类型、来源与关键字段，用于描述离散的、可枚举的业务或系统事件（如部署、配置变更、故障、扩容、安全告警）。定位上，事件是"离散事实"：指标是聚合的连续量，日志是运行的详细记录，追踪是请求链路，事件则是"发生了什么"的时序快照。工程价值：一是提供上下文——把部署、配置、告警等事件与指标/日志关联，解释"为什么指标突然变化"（如部署释放导致延迟上升）；二是复盘与审计——事件时间线可追溯系统变更；三是立即可观测——事件驱动告警与联动。实践中把事件与指标用时间对齐、用标签关联，形成"指标异常 + 事件解释"的排障闭环。

事件的价值在于"解释变化"：指标告诉你"变了"，事件告诉你"为什么变了"（部署、配置、故障）。把事件与指标、日志、追踪对齐，能显著提升排障效率与复盘质量。

• pprof extension 的作用
• 性能剖析方法
• 排查流程

pprof extension 是 OpenTelemetry Collector 内置的性能剖析端点，用于暴露 Go 的 pprof 数据（CPU、内存、goroutine、堆等），帮助排查 collector 自身性能问题。启用后，pprof extension 暴露 HTTP 端点（默认 1777 端口），通过 curl http://collector:1777/debug/pprof/ 访问，可抓取 CPU profile（/debug/pprof/profile）、heap（/debug/pprof/heap）、goroutine（/debug/pprof/goroutine）等。排查流程：当 collector 出现高 CPU、高内存或高延迟时，启用 pprof，抓取 CPU profile 分析热点函数（判断是否某 processor 或解析器耗 CPU），抓取 heap 分析内存分配（判断 buffer 是否累积、是否内存泄漏），抓取 goroutine 分析协程堆积（判断是否阻塞）。结合 pprof 的火焰图与 top 函数定位瓶颈，再针对性调优（如调整 batch 大小、memory_limiter、processor 配置）。生产环境应控制 pprof 端点暴露，避免未授权访问。

pprof extension 是"诊断 collector 自身的探针"，把 Go 的 pprof 能力暴露给运维。CPU/heap/goroutine 三类 profile 分别对应 CPU、内存、阻塞问题，配合火焰图定位热点。

• continuous profiling 的概念
• 各类剖析的作用
• 告警联动与资源优化

continuous profiling（持续剖析）是不间断地对线上进程做性能剖析，将函数级 CPU/内存/goroutine 占用持续采集并存储，用于资源优化与性能排障。Pyroscope 与 Parca 是常见实现。CPU 剖析：持续采集函数级 CPU 占用，定位"CPU 花在哪个函数"，识别热点与无谓计算；内存剖析：采集堆分配与对象占用，定位内存热点与潜在泄漏；goroutine 剖析：采集 goroutine 数量与堆栈，定位协程泄漏与阻塞。资源优化作用：通过持续剖析发现低效代码、内存泄漏、协程堆积，结合优化后对比前后占用，量化资源收益（如降 CPU 核数、降内存）。告警联动：持续剖析可与指标告警联动——当 CPU/内存/延迟指标触发告警时，自动关联该时间段的 profile，快速定位到导致问题的函数；甚至对 goroutine 数、内存增长设基线告警。价值是"把资源问题从'知道有'推进到'知道在哪'"。

持续剖析的价值是"函数级、持续、可回溯"：比指标更细粒度（到函数），比临时剖析更完整（持续），并与告警联动把"指标异常"定位到"具体函数"。这是资源优化的关键工具。

• 各支柱的粒度与角色
• profiling 的补充价值
• 联合分析

三大支柱（指标、日志、追踪）回答"发生了什么、何时、哪条链路"，而持续剖析（profiling）回答"为什么资源被消耗、代码怎么执行"——它在函数粒度上补充了三大支柱的空白。指标是聚合的连续量（整体状态），日志是事件记录（细节），追踪是请求链路（贯穿服务），三者都回答"现象"；profiling 提供"代码执行路径与资源占用"的"原因"维度。互补方式：指标告警（如 CPU 高）→ 由 profiling 定位哪个函数耗 CPU；追踪展示慢请求跨服务耗时 → profiling 显示该服务内哪个函数耗时；日志记录异常 → profiling 关联该时间段的热点。联合分析时，把指标、trace、profile 按时间对齐，用 trace 定位服务、用 profile 定位函数、用指标确认范围，形成"现象→链路→函数"的完整下钻链。profiling 是"第四支柱"（可观测性四支柱含 profiling），它与三支柱互补，补齐"代码执行"的视角。

互补的本质是"粒度从整体到函数"：指标看整体、日志看事件、追踪看链路、profiling 看函数。profiling 把"哪有问题"深化到"哪段代码有问题"，与三支柱联合形成完整下钻。

• 高基数 label 识别与治理
• 指标降采样
• 日志采样与存储分层

遥测成本控制的核心是"基数治理 + 采样 + 分层"。高基数 label 识别：用 PromQL（如 count by (label) (metric)）或分析工具找出高基数标签（值数量巨大、增长快），如 Pod 名、随机 ID、trace_id 误入 label；治理方法是在 relabel 中丢弃/聚合高基数标签，只保留低基数且有聚合价值的标签。指标降采样：对低价值指标降低采集频率、用 recording rules 聚合预计算、对历史数据 downsampling（如 Thanos/Mimir 的 5m/1h 降采样）。日志采样策略：对高吞吐日志按比例/按规则采样（保留错误日志、丢弃 debug 日志），在采集端用 tail 采样或按级别过滤。存储分层：热数据用高性能存储（短期、高精度）、冷数据用低成本对象存储/归档（长期、降采样），按保留周期分层。综合策略是"按价值分级"：高价值数据全量、低价值降采样，热冷分层控制成本，并持续监控基数与容量。

成本控制的核心是"按价值分级存储与采集"：高基数标签是成本主要来源，需识别并治理；降采样与日志采样降低量与精度；存储分层按热冷分配成本。三者结合把成本与价值匹配。

• PromQL 常用函数
• recording rules 的作用
• 预计算降低查询开销

PromQL 常用函数包括 rate/irate（计数速率）、increase（增量）、histogram_quantile（从 histogram bucket 计算分位数）、sum/avg/max/min（聚合）、label_replace、topk 等。recording rules 是把复杂查询结果预计算并存储为新的指标，从而降低查询开销。用法：对高频/复杂查询（如 histogram_quantile(0.99, sum(rate(http_requests_bucket[5m])) by (le))）定义 recording rule，在采集端预计算并保存为新指标（如 job:http_requests_p99），查询时直接读取预计算指标，避免每次实时计算。rate 适合平滑速率与告警，histogram_quantile 用于分位数，聚合级计算（如跨 label 的 sum）也适合放 recording rule。预计算的价值：降低查询延迟与 Prometheus 计算负载，把复杂表达式提前算好，仪表盘与告警直接引用。需注意 recording rule 的存储开销与命名规范。

recording rules 的核心理念是"把计算移到采集端、把结果存下来"：对高频复杂查询预计算，查询端直接读结果，显著降低开销。rate/histogram_quantile 是构建预计算指标的基础函数。

• TSDB 的 block 结构
• chunk 压缩
• 查询性能调优

Prometheus TSDB 以 block 为存储单元，每个 block 包含一段时间（默认 2 小时）的数据，block 内含 index（标签索引）、chunks（样本数据）、meta.json（时间范围）等。数据按时间分块，block 不可变，超出保留期的 block 会被删除，查询时跨 block 合并。chunk 压缩：同一 series 的样本在内存中累积为 chunk，写入时按格式压缩（如 XOR、Snappy），减少存储占用；chunk 大小与压缩率影响 IO 与查询。查询性能调优要点：一是查询范围与 block 对齐，避免跨大量 block 的聚合；二是用 recording rules 预计算降低实时计算；三是限制查询时间范围与 series 数量，避免全量扫描；四是控制标签基数（高基数拖慢索引与查询）；五是合理设置 block 大小与压缩率、使用 SSD、监控磁盘 IO。查询优化优先级：先降基数与预计算，再优化 block/chunk 与存储。

TSDB 的 block+chunk 结构是"时间分块 + 压缩"：block 支撑时间范围查询与删除，chunk 压缩降存储。查询调优核心是"减少扫描与计算"（预计算、降基数、限范围）。

• remote_write 与联邦的机制
• 长期存储与多集群聚合
• 数据丢失风险

remote_write 是把 Prometheus 数据实时推送到远程存储（如 Thanos receiver、Mimir、VictoriaMetrics、云监控），实现长期存储与全局查询；联邦（federation）是 Prometheus 从另一 Prometheus 拉取指标，按层级聚合（如从中心 Prometheus 拉取各集群的聚合指标）。取舍：remote_write 适合"长期存储 + 全局查询 + 多后端"，数据在远端聚合，但依赖网络推送，网络故障或后端不可用时有数据丢失/缓冲风险；联邦适合"多集群聚合 + 跨集群查询"，中心 Prometheus 拉取子集群数据，但联邦只适合聚合少量低基数指标，且层级加深会增加复杂度。数据丢失风险：remote_write 依赖推送，需配置缓冲（write-ahead log、queue）与重试，故障时可能丢样本；联邦依赖拉取，目标不可达时同样丢数据。权衡：长期存储选 remote_write（配合 WAL/缓冲），多集群聚合选联邦（聚合少量指标），两者也可结合（子集群 remote_write 到多集群存储，联邦做聚合查询）。核心是权衡"实时性、聚合能力、数据完整性与运维复杂度"。

remote_write 是"推送式长期存储"，联邦是"拉取式聚合"：前者解长期存储，后者解多集群聚合。数据丢失风险都源于网络与缓冲，需按场景权衡并配置缓冲与重试。

• 服务发现的类型
• relabel 与 target 生成
• target 丢失排查

Prometheus 支持多种服务发现：kubernetes_sd 从 K8s API 发现 Pod/Service/Endpoint/Node 等目标，consul_sd 从 Consul 发现服务，file_sd 从文件读取静态目标列表（文件动态更新）。服务发现返回带有大量元数据标签（如 __meta_kubernetes_pod_label_*、__meta_consul_service）的目标，relabel 用于把这些元数据转换为最终的目标标签（__address__、job、instance 等），并决定是否保留目标（drop/keep）。配合：scrape_configs 中配置 kubernetes_sd_configs 声明发现类型，relabel_configs 按规则筛选与设置标签。target 丢失排查思路：检查 prometheus/targets 页面看目标是否被拉取或为 down；检查 relabel 规则是否误 drop（keep/drop 条件不匹配）；检查服务发现选择器（namespace/selector）是否匹配到资源；检查元数据标签是否缺失导致 __address__ 无效；查看 Prometheus 日志与 up 指标。常见丢失原因：relabel 误过滤、SD 选择器不匹配、端口/协议错误、标签冲突。

服务发现负责"找到目标"，relabel 负责"筛选与打标签"，两者配合。target 丢失多为 relabel 误过滤、选择器不匹配或元数据标签缺失，排查从 targets 页面与 relabel 规则入手。

• relabel 的动作与机制
• 元数据标签处理
• 高级用法

relabel_configs 是在服务发现后、抓取前对目标的元数据标签进行变换的机制，高级用法包括：一是标签筛选——用 keep/drop 基于 __meta_ 标签的布尔/正则条件保留或丢弃目标，实现按标签、命名空间、环境过滤；二是标签重写——用 replace 把 __meta_ 标签复制/改写为最终标签（如把 __meta_kubernetes_pod_label_app 改为 app），并用 labelmap 批量映射一类标签；三是合并与拼接——用 target_label、regex 与 replacement 拼接地址、job 名或 instance；四是标签删改——labeldrop/labelkeep 删除或保留指定标签，控制标签基数。高级用法常用场景：把 K8s 元数据标签标准化为业务标签、按 __meta_kubernetes_pod_container_port_name 过滤端口、把 Pod 标签映射为告警使用的标签、用 __address__ 改写抓取地址。template 与正则配合可实现灵活的目标变换。

relabel 的高级用法核心是"用正则 + 动作对元数据标签做筛选、重写、映射与删改"，把服务发现的原始元数据转化为可用的清晰标签，并控制标签基数。它发生在抓取前，是"第一个标签处理层"。

• 高可用架构
• 分片与水平扩展
• 采集成本控制

Prometheus 高可用通常采用"双实例 + 去重"：两个 Prometheus 同时采集相同数据，通过 Thanos/HAProxy 的 dedup 去重对外提供一致查询，避免单点故障。采集成本控制上，垂直方向限制单实例的 series 数量与标签基数，水平方向用分片（sharding）把不同 target 分给多个 Prometheus 实例，降低单实例负载。分片方案：按规则分片（如按环境/集群/namespace 分配 target）、用 hashmod 均匀分片、或用 Thanos/Cortex 的分布式采集。采集成本控制要点：控制抓取频率（长周期 target 用低频率）、过滤低价值 target、relabel 降标签基数、用 recording rules 预计算、限制历史保留。高可用 + 分片结合：多实例采集 + 分片降负载 + 去重提一致性，配合长期存储（remote_write/Thanos）实现可扩展。核心是平衡"可用性、性能与成本"。

高可用是"双实例去重"，分片是"水平扩展降负载"，成本控制是"频率、标签、保留"的调优。三者结合让 Prometheus 在规模增长下保持可用、稳定与低成本。

• 指标命名规范
• 标签基数控制
• textfile collector 适用场景

自定义 exporter 开发要点：一是指标命名遵循规范——用 namespace_subsystem_name_unit 结构（如 myapp_http_requests_total），计数器用 _total 后缀，使用 _seconds/_bytes 等单位后缀，Helm 味道的命名便于理解与复用；二是标签基数控制——只暴露低基数、有聚合价值的标签，避免高基数标签（如随机 ID、请求路径、trace_id），否则导致指标爆炸；用 _info 或常量标签承载静态信息而非作为 series 维度；三是提供 up 与 scrape_duration_seconds 等标准指标，正确处理 expose 错误。textfile collector 适用场景：对于无法/不适合用标准 exporter 采集的指标（如 cron 任务结果、配置文件状态、第三方脚本输出），用脚本把指标写入文本文件，node_exporter 的 textfile collector 定期读取并暴露这些指标，适合"间歇性、非请求驱动"的指标采集，避免为每个小指标开发完整 exporter。

开发要点是"命名规范 + 低基数 + 标准指标"。textfile collector 适合"脚本/批处理产生的低频指标"，用文件桥接，无需完整 exporter。核心是避免高基数与命名混乱。