首页/云/可观测性速查

可观测性速查

指标日志链路三支柱、Prometheus 与 PromQL、Grafana 面板、ELK/Loki 日志、OpenTelemetry 链路追踪、告警分级与收敛：监控体系速查。

共 282 条更新于 2026-10-12所属领域：云

共 282 条

监控体系与方法

可观测性三支柱、黄金指标与监控分层

可观测性三支柱：Metrics、Logs、Traces热门

指标、日志、链路追踪三类遥测数据的定位与分工：指标回答整体趋势，日志回答单次细节，链路回答请求跨服务的路径；三者靠统一标签与 trace_id 关联。

四大黄金指标：延迟、流量、错误、饱和度热门

Google SRE 归纳的四类通用监控指标：Latency 延迟、Traffic 流量、Errors 错误、Saturation 饱和度，适用于绝大多数在线服务的监控起步。

Prometheus 指标类型：Counter、Gauge、Histogram、Summary

Prometheus 客户端库提供四种指标类型：只增的 Counter、可增可减的 Gauge、分桶统计的 Histogram、客户端算分位的 Summary；类型决定可用函数与查询方式。

SLI、SLO 与 SLA：三个容易混用的概念

SLI 是可测量的服务质量指标（如成功率），SLO 是团队内部设定的目标值（如 99.9%），SLA 是对外合同承诺；SLO 应严于 SLA 留出缓冲。

RED 方法：Rate、Errors、Duration

面向请求型服务（微服务、API 网关、Web 应用）的三指标方法：请求速率、错误比例、耗时分布；少量面板即可覆盖服务健康与版本变更效果。

USE 方法：Utilization、Saturation、Errors

面向资源（CPU、内存、磁盘、网络、连接池等）的三维检查法：使用率、饱和度、错误数；适合排查机器变慢、服务变慢背后的资源瓶颈。

Histogram 与 Summary：分位统计怎么选

Histogram 在服务端按 le 分桶累计，分位用 histogram_quantile() 在查询时计算且可跨实例聚合；Summary 在客户端直接算出分位，但分位数值无法跨实例合并。

高基数：指标爆炸的成本与治理

序列数 = 指标名 × 标签值组合；把用户 ID、完整 URL、请求 ID 放进标签会让序列数快速膨胀，拖慢查询并推高存储与内存成本。

错误预算：用可量化的代价管理稳定性

错误预算 = 1 − SLO。以 30 天 99.9% 的 SLO 为例，每月允许约 43 分钟不可用；预算充足可加速发布，预算耗尽则优先修复稳定性。

标签设计：低基数、稳定、可聚合

标签是查询与聚合的维度；设计原则是取值有限且稳定（instance、job、env、route），避免把高动态数据（ID、时间戳）放进标签。

均值和分位数：延迟观测的正确姿势

平均延迟会被长尾掩盖：99 个快请求加 1 个超慢请求，均值依然好看。延迟观测应使用 P50/P95/P99 分位并明确统计窗口，同时可统计超阈值请求占比。

监控系统自身的可观测性

监控断点常被忽略：采集器挂了、告警通道静默、规则未加载，都会让系统看起来一切正常。应对监控链路各环节做自监控。

燃尽率（Burn Rate）：基于 SLO 的告警指标

燃尽率 = 当前错误率 ÷ 允许错误率，表示错误预算的消耗速度；多窗口多阈值组合（如 14.4×1 小时与 6×6 小时）兼顾快速发现与降低误报。

监控分层：从主机到业务的全景视图

常见监控分层：基础设施、中间件、应用、业务、端到端体验；不同层级的指标用途不同，看板与告警应分层组织，便于从现象逐级下钻。

症状告警与原因告警：先保用户体验

症状告警针对用户可感知的结果（错误率上升、延迟超标）；原因告警针对内部根因（磁盘将满、主从延迟）。前者保体验，后者争取处置时间。

指标命名与单位规范

Prometheus 社区约定：小写 snake_case、带单位后缀、Counter 以 _total 结尾、使用基本单位（秒、字节）；统一命名才能让查询与看板可复用。

拉取与推送：监控采集的两种模型

Prometheus 以拉取（pull）为主：周期请求目标的 /metrics 端点；推送（push）适合批处理任务或穿透网络限制的场景，通常经 Pushgateway 中转。

可用性等级与停机时长对照

几个 9 的可用性换算成停机时长更便于沟通：99% 每月允许约 7 小时，99.9% 约 43 分钟，99.99% 约 4 分钟；先定义口径再谈目标。

埋点方式：自动插桩、手动埋点与无侵入

三类埋点方式各有边界：自动插桩零代码改动覆盖通用框架，手动埋点补充业务语义，eBPF 等无侵入方式适合难以改造的存量系统。

看板设计原则：从总览到下钻

好用的看板按总览、分组、单实例三层组织：首屏给结论（可用性与错误），中间给分维度趋势，底部提供下钻入口；每个面板都应能回答一个具体问题。

容量水位与扩容提前量

容量类监控关注'还剩多少余量'与'还能撑多久'：用预测函数估算到达阈值的时间点，让扩容发生在故障之前，而不是告警之后。

白盒与黑盒监控：内因与外因

白盒监控采集系统内部数据（应用指标、日志、主机资源），用于解释为什么出问题；黑盒监控从外部探测（HTTP/TCP/DNS），回答服务当前是否可用。

MTTR、MTBF 与 MTTD：衡量应急能力

MTTD 是发现耗时、MTTR 是恢复耗时、MTBF 是平均无故障间隔；三者分别对应应急链路的不同环节，用于定位瓶颈在发现还是恢复。

遥测采样：指标、日志、链路各有策略

采样是针对量大且可丢弃数据的控制手段：指标按采集间隔天然降采样，日志可按级别或比例抽样，链路采样率直接影响成本与可观测性。

时间同步：监控数据对齐的前提

主机时间漂移会让指标、日志与链路的时序关系错乱：图表对不齐、关联查询落空、基于时间差的告警误报。全链路应统一 NTP 源并监控偏移量。

业务监控：技术指标之外的用户视角

技术指标正常不代表业务正常（例如支付渠道失败但接口仍返回 200）。业务监控直接度量成交、注册、活跃等结果，并按渠道、地域、版本等业务维度切分。

指标与告警的归属：每个信号都要有人负责

每条告警、每个关键指标都应有明确负责人与升级路径；无主告警会长期无人处理，是告警体系退化的起点。

合成监控与拨测：在用户之前发现问题

用脚本或探测服务模拟用户请求（登录、下单、API 调用），按周期从多个位置发起并校验响应内容，在真实用户受影响前捕捉故障。

SLI 选型示例：不同服务类型怎么定指标

SLI 要按服务形态挑选：请求型看成功率与延迟，任务型看完成率与时效，存储型看持久性与延迟；选错 SLI 会让 SLO 与用户感知脱节。

基线、同比与动态阈值

有节律的业务曲线（白天高、夜间低）用固定阈值会频繁误报；用上周同期（offset 1w）做基线对比，或对稳态指标做时间序列异常检测更稳。

指标保留、降采样与长期存储

原始指标的保留期决定磁盘占用与查询性能：本地 TSDB 保留原始数据（如 15-30 天），更长时间的历史用降采样或远程存储承载。

统一资源属性：让数据可关联、可下钻

跨信号关联的前提是统一标识：service.name、host、env、version 等资源属性在三类遥测数据中保持一致，看板与检索才能按同一维度切换。

可观测性常见反模式清单

一线常见反模式：只看均值、日志全量不裁剪、标签乱塞、告警只有原因没有症状、看板无人维护；对照自查比从零设计更快。

遥测流水线：采集、加工、存储、消费

可观测性数据链路的通用形态：agent 或采集器收集，网关统一加工（批处理、脱敏、采样、路由），写入时序库或日志/链路库，供看板、告警与查询消费。

监控覆盖盘点清单

定期盘点每个业务单元是否被监控覆盖：从入口、依赖、数据、任务四个方向核对，找出只有巡检没有告警的盲区。

排障四问：发现、定位、解释、预防

用四个问题检验可观测性是否够用：故障能否被及时发现、能否快速定位到组件、能否解释根因、能否留下防复发证据；答案缺失之处就是建设重点。

可观测性成本治理：先分层再压缩

遥测成本主要在存储与查询：先按信号分层（指标长期、日志短期、链路按需），再对高成本来源做采样、过滤与保留期收缩，避免全量长期保留成为默认。

可观测性建设的阶段演进

从有无监控到可观测性闭环通常经历几个阶段：基础资源监控、服务标准化指标、日志与链路补齐、SLO 驱动、成本与治理；不同阶段解决不同层次的问题。

故障演练：用受控实验验证可观测性

定期开展故障演练（注入延迟、杀掉实例、断开依赖），验证监控能否按预期发现、告警能否触达、预案是否可用；演练结果反哺告警与看板改进。

SLO 评审：定期校准目标与预算

SLO 定了不是就不动：随业务阶段与用户预期变化，需定期（如每季度）评审目标值、SLI 口径与预算策略，并用期间数据验证合理性。

Prometheus 与采集

抓取配置、Exporter 与 PromQL 查询

Prometheus 架构与组件概览热门

Prometheus 是拉取模型的时序监控系统：服务端按配置抓取目标、写入本地 TSDB，规则引擎持续评估记录与告警规则，通过 HTTP API 供 Grafana 等消费。

主机 CPU/内存/磁盘使用率的标准查询热门

主机使用率查询有两个固定要点：CPU 用 idle 模式反向计算，内存用 MemAvailable 口径；磁盘要过滤伪文件系统并按挂载点分组。

up 指标：抓取健康与目标存活热门

up 是 Prometheus 为每个抓取目标生成的合成指标：抓取成功为 1、失败为 0；配合实例标签可快速定位哪台目标失联，是常用的基础告警。

部署 node_exporter 采集主机指标

node_exporter 暴露 Linux/Unix 主机指标（CPU、内存、磁盘、网络、文件系统等）；以 systemd 服务方式运行，默认监听 9100 端口。

rate 与 irate：计数器变化率

rate() 用窗口内样本做外推，曲线平滑，适合告警与容量趋势；irate() 只用窗口内后两个样本，反应快但抖动大，适合观察瞬时突变。

histogram_quantile：分位计算实战

histogram_quantile(φ, bucket) 依据 le 分桶估算分位数；必须先 sum by (le)（必要时保留其他维度）聚合桶，再交给函数计算，才能得到整体分位。

告警规则：expr、for 与 annotations

告警规则由 alert 名称、expr 表达式、for 持续时长、labels 与 annotations 组成；expr 返回非空即进入 pending，持续超过 for 转为 firing。

prometheus.yml：配置结构总览

主配置由 global（全局默认）、rule_files（规则文件）、scrape_configs（抓取任务）、alerting（Alertmanager 地址）等段组成，支持运行期热加载。

PromQL 基础：瞬时向量与范围向量

PromQL 的查询对象是时间序列：瞬时向量取当前点，范围向量取一段窗口；区间选择器只能作为函数参数，不能直接出图。

sum by 与 without：聚合与维度裁剪

聚合运算符把多序列合并为少数序列：sum by (label) 按指定维度分组求和，sum without (label) 保留列出的维度之外的全部标签，用于控制曲线数量。

比率查询：错误率与占比的写法

比率的通用模式：分子分母都用 rate，且维度对齐；两侧的 sum by 列表保持一致，否则向量匹配失败或得到不符合预期的结果。

抓取任务（scrape_configs）基础写法

每个抓取任务定义一个 job：目标列表、抓取路径、协议、参数与超时；job 名会成为 job 标签，是查询与聚合的基础维度。

relabel_configs：抓取前的目标标签改写

relabel_configs 在抓取发生前处理目标元标签（__address__、__param_* 等），常用于改写端口、过滤目标、添加业务标签与生成实例标签。

node_exporter 关键指标速查

主机监控常用指标按 CPU、内存、磁盘、网络分类：理解每条指标的口径（累计、瞬时、可用量）才能写出正确的查询。

抓取间隔与超时的取值权衡

scrape_interval 决定数据分辨率，scrape_timeout 必须小于间隔；间隔越短数据越细但目标压力与存储成本越高，15-60 秒是常见区间。

metric_relabel_configs：抓取后的指标治理

metric_relabel_configs 在抓取返回后、入库前处理样本：丢弃高成本指标、删除敏感或高基数标签、做重命名；是控制序列数、保护 TSDB 的主要手段。

increase：窗口内的累计增量

increase() 计算计数器在窗口内的增长总量（rate 乘窗口秒数），适合回答'过去 1 小时处理了多少请求'；同样内置处理计数器重置。

标签匹配运算符：=、!=、=~、!~

四种匹配运算符：等于与不等于做精确匹配，=~ 与 !~ 做正则匹配（隐式锚定全串）；正则可合并多个状态码或排除内部路由。

mysqld_exporter：MySQL 指标采集

mysqld_exporter 连接 MySQL 暴露连接数、QPS、主从复制等指标；使用独立监控账号，默认端口 9104，常用指标 mysql_up 与 mysql_global_status_*。

kubernetes_sd：Kubernetes 服务发现

kubernetes_sd_configs 以集群 API 为数据源，按 role（node、pod、service、endpoints 等）生成目标候选，再用 relabel 筛选与改写；是采集 K8s 工作负载的标准方式。

promtool：配置与规则校验工具

promtool 随 Prometheus 发行包提供：check config、check rules 做静态校验，test rules 跑规则单元测试；建议纳入 CI，在部署前拦截错误。

topk 与 bottomk：找出靠前的序列

topk(n, v) 返回分组内数值靠前的 n 条序列，常用于找出错误数偏多的服务或实例；可先按维度分组再对每组取 topk。

absent 与 absent_over_time：检测指标缺失

当目标整体下线时，它的指标序列会消失，此时 up==0 也可能不存在；absent() 在序列不存在时返回 1，适合做无数据类告警。

比较运算符：过滤语义与 bool 修饰

向量与标量比较默认是过滤语义：只保留满足条件的样本；加 bool 则改为输出 0/1 且不丢样本。标量与标量比较必须加 bool。

时间聚合函数族：_over_time 系列

avg_over_time、max_over_time、sum_over_time 等把范围向量压缩成单点：用于平滑瞬时波动、计算窗口极值，或配合子查询做多层聚合。

记录规则：把高频查询预先算好

recording rules 周期性计算表达式并写成新指标（惯例命名 level:metric:operations），让看板与告警查询预计算结果，降低查询成本与复杂度。

redis_exporter：Redis 指标采集

redis_exporter 采集 Redis 内存、连接与命中率；默认端口 9121，常用指标包括 redis_up、redis_memory_used_bytes 与 keyspace hits/misses 计数。

cAdvisor：容器资源指标采集

cAdvisor 采集容器的 CPU、内存、网络与文件系统指标，Kubernetes 中作为内置组件集成；常用指标 container_cpu_usage_seconds_total、container_memory_working_set_bytes。

static_configs：静态目标列表

直接声明目标的方式：在任务下写 targets 列表并附加标签；适合目标数量少、或由配置管理工具统一生成的场景，规模变大后应替换为服务发现。

file_sd：用文件做服务发现

file_sd_configs 从 JSON/YAML 文件读取目标列表并支持自动重载（默认 5 分钟检测变更）；配合配置管理或脚本生成文件，适合无法动态发现的环境。

offset 与 @：时间平移查询

offset 把查询窗口整体前移（如 offset 1w 看上周同期），@ 把查询固定到某个时间点（如 @ end() 对齐查询区间结束）；两者常配合使用。

向量匹配：on、ignoring 与 group_left

两个向量做算术运算时按标签对齐：默认要求标签集完全一致；on/ignoring 控制参与匹配的标签，group_left/group_right 处理一对多或多对一场景。

向量匹配做指标关联（示例：成功率）

把两个来源的指标按业务键关联是常见需求：例如成功数与总数相除得到成功率；关键是让两侧标签通过 on() 对齐。

remote write：把数据写到长期存储

远程写让 Prometheus 边采集边把样本推送到远端（长期存储、联邦中心或云端服务），本地保留期照常工作，兼顾接入与查询便利。

HTTP API：query 与 query_range 实战

Prometheus 提供 HTTP 查询接口：/api/v1/query 查瞬时值、/api/v1/query_range 查区间序列、/api/v1/series 列举序列；脚本化取数与系统集成很常用。

nginx-prometheus-exporter：Nginx 指标采集

该 exporter 读取 Nginx 的 stub_status（或 Nginx Plus API）输出指标：连接数与请求统计；开源版需要开启 stub_status 端点。

kube-state-metrics：集群对象状态指标

kube-state-metrics 监听 APIServer，把 Deployment、Pod、Node 等对象状态转成指标（如期望副本与实际副本），补齐 cAdvisor 只覆盖资源用量的空白。

TSDB 存储结构与保留策略

Prometheus 自带时序存储：head 块在内存并同步写 WAL 保证崩溃恢复，默认每 2 小时落盘为持久块，后台压缩合并；保留期默认 15 天，可按时间或容量控制。

Prometheus Operator 与 ServiceMonitor

Kubernetes 上的 Operator 模式：用 CRD 声明式定义监控对象，Operator 监听变更自动生成并热加载 Prometheus 配置，取代手工维护配置文件。

deriv：指标变化斜率

deriv() 用线性回归计算 Gauge 在窗口内的每秒变化速率；用于观察'增长得多快'，比绝对值更能提前暴露趋势问题。

告警模板：$labels、$value 与 humanize

annotations 与 labels 支持 Go 模板：$labels 取告警标签、$value 取当前值；humanize 系列可格式化秒与百分比，让通知内容直接可读。

blackbox 探测模块：http、tcp、icmp、dns

blackbox_exporter 内置多种探测类型：http（状态码与内容断言）、tcp 连接、icmp ping、dns 解析；模块在配置文件中预定义，抓取时用参数选择。

Pushgateway 使用要点与清理

Pushgateway 保存推送的指标供 Prometheus 抓取；分组由 job 加任意标签组成，同分组重复推送会覆盖；任务结束或下线后要主动清理。

抓取限制：sample_limit 与标签上限保护

每个抓取任务可配置样本数与标签长度上限，防止单个目标的指标爆炸拖垮采集端；超限时该次抓取被整体判定为失败，而不是部分丢弃。

predict_linear：容量耗尽预测查询

predict_linear 对指定窗口做线性回归并外推未来某时刻的值；经典用法是预测磁盘何时耗尽，让容量告警从到达阈值提前到预计将到达。

changes 与 resets：变化次数与重置次数

changes() 统计窗口内值发生变化的次数；resets() 统计 Counter 重置次数，用于发现进程反复重启或计数器异常。

count_over_time：窗口内的样本数

count_over_time 统计窗口内实际存在的样本数量，用于判断数据完整性与采样间隙；样本数偏少会让 rate 类查询的误差放大。

promtool test rules：告警规则单元测试

用 YAML 描述测试：构造输入序列（input_series）、断言告警状态（alert_rule_test）与查询结果（promql_expr_test），在 CI 中防止规则回归。

内置 UI：Targets、Rules 与查询页

内置 Web UI 提供表达式浏览与绘图、Targets 目标状态、Service Discovery 元标签对照、Rules 与 Alerts 页面；排障先看 Targets 与 Alerts。

textfile 采集器：注入自定义静态指标

node_exporter 的 textfile 采集器读取指定目录下的 .prom 文件并暴露为指标；适合把脚本产出（备份时间、证书剩余天数）变成可监控指标。

dns_sd：基于 DNS SRV 记录发现目标

dns_sd_configs 通过 DNS SRV 记录动态发现目标地址与端口，适合目标以域名集中管理的环境；支持 SRV、A、AAAA 三种记录类型。

label_replace：查询期改写标签

label_replace(v, dst, replacement, src, regex) 用正则从源标签提取内容写入目标标签；常用于统一不同系统的标签命名或补齐维度。

keep_firing_for：减少抖动导致的漏看

keep_firing_for 让告警在条件不再满足后继续维持 firing 一段时间，防止抖动场景下告警刚触发就恢复、值班人还没看到。

联邦：从下级 Prometheus 拉取汇总数据

联邦让上级 Prometheus 通过 /federate 端点拉取下级实例的部分序列；适合分层架构，把跨集群的少量核心指标汇总到全局视图。

序列过期与 stale 标记（staleness）

查询默认只看近 5 分钟内的样本（lookback delta）；目标移除或序列消失时写入 stale 标记，让查询立即停止返回旧值，避免用陈旧数据做判断。

Exemplars：把指标关联到链路

Exemplar 是附加在样本上的标注元数据，典型做法是携带 trace_id：看到延迟毛刺时从指标直接跳到对应链路，把指标与追踪两支柱串起来。

consul_sd：Consul 服务目录发现

consul_sd_configs 从 Consul 服务目录读取实例列表；适合已有 Consul 体系复用服务注册信息，减少重复维护目标清单。

clamp 系列：数值截断与展示控制

clamp_max、clamp_min、clamp 把数值限制在区间内；多用于压制异常尖峰对图表坐标轴的影响，或把抖动产生的负值归零。

时间函数：time、timestamp 与日期判断

time() 返回查询时刻的 Unix 秒，timestamp() 返回样本自身时间戳；配合 day_of_week、hour 等函数可实现按时间段差异化的规则。

external_labels：给数据打上集群身份

external_labels 在通信场景（远程写、联邦、告警）附加到所有数据上，标识集群或区域；它不需要逐个目标配置，是分层部署的常用手段。

Agent 模式：只采集与远程写

通过特性开关让 Prometheus 以 agent 形态运行：不提供本地查询、不评估规则，只抓取并 remote_write，适合边缘节点或大规模分层汇聚场景。

AWS EC2 服务发现（ec2_sd_configs）

在 AWS 上用 ec2_sd_configs 自动发现实例：按区域与过滤条件选取目标，再经 relabel 生成 instance 与业务标签，免去维护静态目标清单。

sort 与 sort_desc：结果排序

sort()/sort_desc() 对瞬时向量按数值排序，影响的是行序而非数值；表格类面板中使用可让结论更直观，对图形面板没有意义。

honor_labels：标签冲突时听谁的

抓取样本带同名标签（如 job、instance）时，honor_labels 决定保留目标自带值还是改写成抓取配置的值；联邦与推送场景尤其重要。

Grafana 与看板

数据源、面板与变量配置

Query 变量：从指标里展开下拉选项热门

模板变量让同一看板适配多实例/多任务：绑定 Prometheus 数据源的 Query 变量常用 label_values 取标签值，也可用 query_result 跑任意 PromQL。

Time series 面板：趋势展示主力热门

默认面板类型：支持多序列折线/柱状/区域、图例统计表、单值或全部 tooltip、软范围坐标轴；绝大多数趋势看板从它开始。

添加 Prometheus 数据源

数据源是 Grafana 取数的入口：填对 URL 与访问方式后 Save & test 验证连通；抓取间隔要如实填写，供速率类查询推算窗口。

内置宏：$interval 与 $rate_interval

面板查询里的时间宏由 Grafana 按时间范围与面板宽度实时计算：$__interval 是步长，$__rate_interval 是自适应速率窗口，避免窗口过小。

Grafana 是什么：可视化与看板核心概念

Grafana 是开源可视化平台：接入 Prometheus/Loki/Elasticsearch 等数据源，按组织-文件夹-看板-面板四级组织，承载展示、分享与统一告警入口。

用 Docker 运行 Grafana

容器方式启动 Grafana：映射 3000 端口、挂载数据卷保存看板与配置，通过环境变量注入初始密码，适合快速验证与小型部署。

看板 JSON 的结构要点

看板以 JSON 为真源：uid/title/时间范围/变量/面板数组构成骨架；面板含 gridPos 栅格、targets 查询与 fieldConfig 字段配置，可整体导入导出。

阈值与阈值线：颜色随数值变化

阈值把数值区间映射成颜色：阈值 steps 从基准色开始逐级提升；Time series 还可显示虚线/区域阈值线，让异常区间一眼可见。

Explore：临时探索与对比

Explore 是不落盘的探索区：临时敲 PromQL/LogQL 验证思路、Split 并排对比两个环境、回看查询历史；验证稳定后再固化到看板。

grafana.ini 常用配置项

配置文件按节组织：server 管监听与外部地址，database 管控库，security 管密钥，users 与 auth.anonymous 管控用户接入；环境变量可逐项覆盖。

Stat 面板：关键数字与迷你趋势

Stat 把序列归约成单个大数字：适合 SLO 达成率、当前错误数、在线实例数；可叠加 sparkline 看短趋势，文字模式控制显示内容。

Table 面板：清单与明细

表格适合展示实例清单、版本分布、TopN 明细：Prometheus 查询选项把 Format 切到 Table，配合整理字段与表内过滤完成巡检视图。

Transformations：可视化前的数据加工

转换对查询结果做二次加工：合并、过滤、聚合、排序、重命名；按列表顺序依次执行，是拼装自定义视图的关键环节。

Query Inspector：面板排障入口

查看面板真实发出的请求、返回的原始数据与查询耗时：出现“无数据”或数值不符时，先用它把问题定位到查询层还是展示层。

看板性能优化清单

看板慢的根因集中在查询量与渲染量：先聚合再展示、给变量查询加范围、重查询交给记录规则、控制刷新与时间窗，逐项都能见效。

Loki 数据源接入

Loki 数据源以标签选择器检索日志并附带日志量直方图；派生字段能把 trace_id 变成可点击链接，联动追踪系统做下钻。

数据源 provisioning 化

用 YAML 声明数据源并随启动自动加载：配置即代码，适合容器化与多环境复制；默认每 10 秒检查一次文件变更并生效。

Gauge 与 Bar gauge：表盘与条形

两种进度型可视化：Gauge 用弧形表盘显示单值占比，Bar gauge 用横向/纵向条并列比较多个对象；都依赖阈值着色与 min/max 设定。

单位与数值格式

单位设置决定坐标轴刻度与 tooltip 的呈现：字节用 bytes(IEC) 或 decbytes，比例小数用 percentunit，比例整数用 percent，时长用 s/ms。

Data links：数据点下钻跳转

给数据点或表格行挂可点击链接：从异常点跳到日志检索、追踪详情或工单页面；URL 用内置变量携带上下文与时间范围。

分享、嵌入与 Kiosk 模式

链接分享自带时间范围与变量；iframe 嵌入需开启 allow_embedding；kiosk 模式隐藏导航边框，是大屏与工单系统集成的常规手段。

看板 provisioning 与 sidecar 模式

把看板 JSON 放进统一目录自动导入：providers 声明路径与刷新周期；Kubernetes 里可让 sidecar 监听带标签的 ConfigMap 自动同步。

用 HTTP API 管理看板

看板可通过 API 读写：GET /api/dashboards/uid/<uid> 导出，POST /api/dashboards/db 创建或覆盖；配合服务账号令牌可进 CI 流水线。

Heatmap 面板：时延分布热力图

热力图用颜色表示密度：X 轴时间、Y 轴分桶；配合 Prometheus 直方图的 le 桶，可观察长尾分布随时间的形态变化。

图例格式化：让序列名可读

Legend format 用标签模板给序列起人名：{{job}} - {{instance}} 比整串指标名可读得多；Table 图例还能附加统计列辅助扫读。

Field overrides：字段级显示覆盖

覆盖规则按字段名、正则或查询号选中字段，单独调整单位、阈值、颜色、列宽；常用来给表格的关键列标红或隐藏无关列。

Annotations 注释：把事件画到图上

注释把发布、重启、告警触发画成时间竖线：Prometheus 数据源可用查询自动生成，也可手工标注发布窗口，便于对照“动作与曲线”。

Max data points 与步长控制

Max data points 与 Min interval 共同决定查询步长：步长过大趋势变粗、速率窗口失真；两者是精度与后端负载的平衡旋钮。

Tempo 数据源接入

Tempo 存储链路数据，Grafana 提供 TraceQL 检索与 trace 详情：按服务、时长筛选链路，与指标、日志互相跳转。

Custom / Interval / Constant 变量

除查询型变量外还有四类：Custom 手写候选集，Interval 提供时间粒度，Constant 隐藏常量，Textbox 临时输入；按场景选择可减少查询开销。

State timeline：状态条带

把离散状态画成时间条带：哪些实例在哪些时段处于异常状态一目了然；适合 up 状态、主从角色、发布阶段等场景。

Logs 面板：把日志嵌进看板

看板里直接展示日志行（数据源用 Loki 或 Elasticsearch），实现“指标异常 → 原始日志”的同屏排查，减少窗口切换。

Reduce 转换：序列归约成表

把多条时间序列压缩成每个序列一行：指定统计量（Last non-null/Mean/Max 等）与 Series to rows 模式，是 TopN 表与巡检表的常用起点。

Library panels：可复用面板

把面板保存为组织级资产：多处看板引用同一面板，修改一处全部同步；适合黄金指标行、依赖组件概览这类复用单元。

时间范围与时区设置

时间选择器控制数据窗口，时区可选跟随浏览器或固定 UTC；跨区域协作与日志对齐时，固定时区能减少“对不上时间”的争议。

Elasticsearch 数据源接入

Elasticsearch 数据源按索引模式与时间字段取数：查询支持 Lucene 语法，指标可用聚合下拉（Date Histogram、Terms 等）拼装。

面板与行重复（Repeat）

按变量为每个取值生成一份面板或整行：多实例、多环境同构展示不再手工复制；重复块内自动带入对应变量值。

变量级联：先选上层再展开下层

下级变量的候选由上级变量决定：把上级值写进下级的查询里（如 {job="$job"}），实现按任务过滤实例的逐级筛选。

Pie chart 面板：占比构成

饼图展示少数分类的占比：按系列取归约值画扇区；查询常用即时聚合（sum by (status)），类别太多时换用条形更易读。

Value mappings：数值到文案的映射

把底层数值翻译成业务语言：0/1 映射成状态文案、状态码映射成描述、空值显示“无数据”；巡检表不必背数字含义。

Dashboard links：看板间导航

在看板顶部放置导航链接：可链接到其他看板并携带变量与时间范围，形成总览到详情的逐层结构。

文件夹与权限：按团队授权

文件夹是权限与归类的基本单位：看板按团队/系统归入文件夹，用角色控制可见与可编辑范围；看板权限继承自所在文件夹。

URL 参数：受控打开看板

URL 参数完全控制初始状态：时间范围、刷新率、变量、kiosk；聊天机器人、runbook、自动化巡检都靠拼链接直达现场。

Ad hoc filters：看板级标签过滤条

Ad hoc filters 在看板顶部提供键值过滤条，选中的标签过滤会自动叠加到绑定数据源上的全部查询，用于临时缩小排查范围。

Text 面板：把说明固化在页面里

Text 面板支持 Markdown/HTML：写看板说明、指标口径、值班流程与导航链接；变量可在文本中插值，随看板环境切换。

Join by field：横向拼接多查询

按公共列（典型是 Time）把多个查询的结果拼到同一张表：指标与日志统计、不同数据源的序列都能合并，便于同表对照。

看板导出图片渲染

把看板导出 PNG 用于通知与报告：OSS 版需单独部署 grafana-image-renderer，并在配置里指向渲染服务地址。

看板版本历史与回滚

每次保存生成版本：可对比差异并回滚；保存时写变更说明，复盘时能还原当时的指标口径与展示方式。

服务账号与令牌（自动化凭据）

Grafana 9.3+ 用服务账号替代旧 API Key：为自动化创建固定角色账号并签发令牌，令牌只在创建时展示一次，按需轮换。

Filter data by query：只看指定查询

只保留指定查询的结果交给后续转换与面板：同一面板内不同查询分工（一条画图、一条进表）时，用它做分流。

匿名访问：只读展示大屏

匿名访问允许未登录用户以只读角色浏览：用于值班大屏与内网展示；开启前先界定数据边界，避免内部指标对外可见。

Playlist：看板轮播

把多个看板编成轮播：每屏设定停留时长自动循环，适合值班大屏的巡检墙；支持 kiosk 全屏播放。

插件管理与安装

插件扩展数据源与可视化：用 grafana-cli 或容器环境变量安装，带签名校验；内网环境可离线放置插件包。

日志平台

ELK/Loki 架构与常用查询

ELK 技术栈分工与数据流

日志平台经典组合：采集端（Beats/Filebeat）→ 缓冲与加工（Logstash 可选）→ 存储检索（Elasticsearch）→ 展示分析（Kibana），各环节可独立扩展。

LogQL 指标查询：把日志变成时间序列

对日志流做范围聚合即得指标：rate 看速率、count_over_time 看数量；配合 by 分组可直接在 Grafana 里画日志趋势。

Mapping 与字段类型选择

映射定义字段如何索引：keyword 用于精确匹配与聚合，text 会分词用于全文检索；字段类型选错会让查询与聚合都出问题。

聚合：从日志里做统计

聚合把原始日志变成趋势与分布：date_histogram 出时间序列，terms 出分组 TopN，cardinality 近似去重；指标聚合嵌套在桶聚合里。

LogQL 流选择器基础

查询从流选择器开始：用标签匹配定位数据流，=、!=、=~、!~ 四种匹配；选择器至少要有一个非空匹配条件。

LogQL unwrap：对数值字段做统计

unwrap 把行内解析出的数值字段当成样本值：从此可以对日志里的耗时、字节数求平均值、分位数，而不再只统计条数。

索引、分片与副本基础

索引由分片组成：主分片数量建索引时确定，副本数可动态调整；副本提供高可用并能分担读流量，但要占用额外存储与写入成本。

Bool 查询：组合检索条件

bool 查询是 DSL 组合器：must 计分、filter 不计分且可缓存、should 提权、must_not 排除；日志查询把过滤条件放 filter 性能更好。

ILM 索引生命周期管理

生命周期策略把索引按时间划入 hot/warm/cold/delete 阶段：滚动、合并、冻结、删除自动执行，控制存储成本与查询性能。

Logstash Pipeline：input/filter/output

管道三段式：input 收数据、filter 改数据、output 发数据；配置文件描述一条流水线，多管道可在 pipelines.yml 中分别声明。

Grok 解析非结构化日志

grok 用模式库把文本拆成字段：%{TIMESTAMP_ISO8601:ts} 这类“模式:字段名”的写法即取即用，自定义模式可放 patterns 目录。

Filebeat 采集配置入门

Filebeat 按输入声明要采集的文件路径：字段富化、多行合并、输出目标都在同一份配置里；先 test config 再启动是稳定运行的基本功。

Loki 标签设计原则

标签决定数据分片与索引体积：用低基数、稳定的维度（集群/环境/服务/级别），高基数内容放日志正文；标签爆炸是 Loki 故障的常见源头。

LogQL 解析器：json / logfmt / regexp / pattern

解析器把行内结构化：json 与 logfmt 直接提取字段用于过滤与聚合，regexp/pattern 面向自定义格式；提取的字段可继续参与条件。

Promtail 采集配置：目标与推送

Promtail 按 scrape_configs 声明要读取的文件与附加标签，然后推送到 Loki 的 push 接口；路径通过 __path__ 特殊标签传入。

结构化日志：字段化与规范

JSON 结构化日志让机器可解析：固定字段名（ts/level/service/trace_id）+ 稳定取值，过滤、聚合、关联都更简单。

索引模板与自动应用

模板为匹配模式的索引预设分片、映射与生命周期：新索引创建时自动套用，日志类“每天一个索引”的场景靠它统一配置。

Bulk 批量写入

批量接口用 NDJSON 格式一行动作一行文档；批量大小直接影响写入效率，过大反而增加协调开销与失败重试成本。

集群健康与红色分片处置

绿黄红分别对应分片分配状态：黄=副本未分配，红=主分片未分配；红色先查未分配原因再决定处置，不要急着重启节点。

Kibana Query Language（KQL）

KQL 是 Kibana 检索框里的过滤语法：字段:值、and/or/not 组合、通配与数值比较；比 Lucene 更直观，是 Discovery 默认语法。

Discover：日志检索工作台

Discover 提供文档级检索：选数据视图与时间范围、KQL 过滤、字段列表筛选、行内展开；满意的检索可存为 Saved Search 分享复用。

Date 过滤器：统一时间戳

把日志里的时间字符串解析成 @timestamp：格式串数组按序尝试，带时区信息才不漂移；解析失败会标记 _dateparsefailure。

输出到 Elasticsearch

output 阶段把事件写入 ES：index/data_stream 决定落点，批量参数与重试影响吞吐与可靠性；配合 ILM 由写入别名接收。

Loki 架构与组件分工

Loki 只索引标签、内容压缩存块：distributor 校验分发、ingester 攒块下传、querier 查询、compactor 压缩清理；存储走对象存储。

LogQL 行过滤：|=、!=、|~、!~

在流选择器后串接内容过滤：|= 包含、!= 不包含、|~ 正则匹配、!~ 正则排除；多个过滤按序叠加进一步收敛结果。

LogQL 的 topk 与分组聚合

在指标查询之上再套聚合运算符：topk 取前列、sum/avg by 做分组；适合“哪个服务错误多、哪个路由耗时长”的即时答案。

Term 与 Range：精确值与范围查询

term 匹配不分词的精确值（keyword 字段），range 匹配数值与时间区间；两者是日志过滤中使用频率很高的原子条件。

排序与深分页

普通分页用 from/size 但有窗口上限；翻深页改 search_after 游标，导出类场景用 PIT 保持一致性视图，避免越翻越慢。

Cat API：集群巡检常用接口

cat 系列接口以表格形式输出集群状态：索引容量、节点负载、分片分布、线程池队列；加 ?v 显示表头、加 format=json 便于脚本消费。

多行日志合并（堆栈跟踪）

Java 堆栈、Python Traceback 天然多行：用 multiline 规则把续行并进首行，否则每行都会变成独立事件。

Filebeat 模块：开箱配置与管线

模块为常见软件（Nginx、System、MySQL 等）预设采集与解析：启用模块 + 加载 ingest pipeline 与看板，采集侧不用写 grok。

Promtail Pipeline：解析与标签加工

pipeline_stages 按序处理每一行：多行合并 → 正则解析 → 打标签 → 时间戳识别；把解析留在采集端可减少重复加工。

日志级别选择与噪声控制

级别是预算：ERROR 喊人、WARN 预警、INFO 记录状态变化、DEBUG 排障细节；级别用错不是信息少了就是噪声爆炸。

ES 节点角色与部署形态

节点按角色分工：master 管集群状态、data 存数据、ingest 做写入前处理、coordinating 负责分发请求；生产通常拆开角色以隔离故障与负载。

快照备份与恢复

快照是集群级备份手段：先注册仓库（文件系统或对象存储），再按索引粒度创建与恢复；跨集群迁移也常用同一套流程。

Kibana 看板：日志可视化组合

把检索结果固化为可视化再组合成看板：错误趋势、Top 服务、错误分布常用直方图、表格、饼图拼装，支持按时间联动与下钻过滤。

Mutate：字段改名、删减与类型转换

mutate 做字段级微调：rename/remove/add_field/convert/gsub；同一块内按书写顺序执行，出错时后续操作可能被跳过。

Processors：轻量字段处理

处理器在发送前处理事件：加字段、丢弃噪声、解析 JSON、丰富主机元数据；比让 Logstash 兜底更省一跳。

Loki 写入与查询限额

限额保护集群不被单租户拖垮：写入速率、突发、流数量、查询序列数与查询时长上限都在 limits_config；命中限额会收到明确报错。

journalctl：systemd 日志速查

systemd 服务日志集中在 journal：按服务/时间/级别过滤、跟看实时输出、查看磁盘占用与清理，是系统层排障的起点。

ELK 与 Loki 的选型对照

两者取舍围绕“索引什么”：ES 全文索引换来检索能力与资源开销，Loki 只索引标签换来低成本与运维简单；按查询深度与预算选择。

Multi-field：text 附带 keyword 子字段

同一内容索引两份视图：text 供全文检索，keyword 子字段供排序聚合；日志平台里 service、level 这类字段常用这个组合。

Refresh 与近实时可见性

ES 索引是近实时：默认每秒 refresh 一次后新文档才可被检索；即时可见要显式 refresh=wait_for/true，代价是合并压力与性能。

ES 堆内存与文件缓存

JVM 堆用于索引结构与查询协调，其余内存留给文件系统缓存；堆过大反而削弱缓存命中，容量规划要两头看。

Kibana Data View（数据视图）

数据视图告诉 Kibana 查哪些索引、用哪个时间字段：支持通配符匹配多个索引，Discovery 与可视化都基于它取数。

Logstash 持久化队列与死信队列

持久化队列把事件先落盘再消费：进程重启不丢在途数据，磁盘写满前还会施加背压；解析失败的毒丸事件进死信队列便于事后分析。

Loki 保留策略配置

保留策略决定日志保存多久：compactor 执行删除，retention_period 设定全局期限；对象存储上的删除需要显式开启并指定删除存储。

日志成本估算与采样策略

日志成本 = 写入量 × 保留期：先估算再治理；健康检查与重复噪声降采样，错误与慢请求保持全量，是较常见的平衡点。

慢查询日志配置

慢日志把超过阈值的查询与写入记入日志文件：先看“谁在慢、慢在什么条件”，再谈优化；阈值可按 warn/info/debug 三档设置。

Filebeat 注册表与文件状态

注册表记录每个文件的读取偏移，是“重启后从哪里继续”的依据；轮转、inode 复用、清理策略都围绕它工作。

日志轮转与清理

轮转控制单文件大小与历史份数：logrotate 按天/大小切分并压缩，保留 N 份；采集器与轮转策略要配合，避免丢行或重复。

Promtail positions 文件管理

positions 文件记录每个文件的读取位置：容器要把它放持久卷，多实例共享会冲突；误删/丢失会让历史日志被重新推送。

链路追踪

Tracing 概念与 OpenTelemetry 基础

链路追踪基础：Trace 与 Span

一次请求的完整路径叫 trace，由若干 span 组成树状结构：每个 span 表示一个工作单元（一次 RPC、一条 SQL、一段计算），带起止时间与父子关系。

OpenTelemetry：项目结构与定位

OpenTelemetry 是厂商中立的遥测标准与工具集：提供 API（埋点接口）、SDK（实现与导出）、Collector（统一收发管道）与语义约定。

W3C Trace Context：跨服务传播标准

traceparent 头承载 trace_id、parent span_id 与采样标志，tracestate 携带厂商额外状态；是跨语言跨厂商链路能连起来的关键标准。

头部采样：在起点决定是否记录

头部采样在 trace 开始时决定：parent-based 尊重上游决定，ratio 采样按 trace_id 哈希确定且全链路一致；成本可控但采不到“事后才重要”的链路。

自动埋点：零代码接入

主流语言提供自动埋点：Java agent 挂载、Python 包装命令、Node 预加载钩子，自动覆盖 HTTP/DB/消息等通用组件调用。

Trace ID 与 Span ID 的格式

标识规范固定：trace_id 为 16 字节（32 位十六进制），span_id 为 8 字节（16 位十六进制）；全链路靠 trace_id 关联，span_id 定位具体节点。

上下文传播：让跨进程调用不断链

进程内用上下文对象传递当前 span，跨进程靠协议头：HTTP 用 traceparent，gRPC 用 metadata，消息用消息头；传播断了链路就断。

尾部采样：先收全再决定

尾部采样在 Collector 里缓存完整 trace 后再决策：错误、慢请求全保留，其余按比例丢弃；代价是需要等待与缓存资源。

手动埋点：业务关键路径补 span

自动埋点覆盖框架层，业务语义（下单、扣库存、对账）要手动补：显式命名、设属性、标记状态，才能让链路对业务可读。

Collector：遥测数据的中转站

Collector 统一收口应用侧遥测：receivers 接收、processors 加工、exporters 输送，service 段把三者组装成管道；部署上常分 agent 与 gateway 两层。

Span 属性与事件

属性（attributes）是键值元数据，用于过滤与聚合；事件（events）是带时间戳的节点记录，典型用途是记录异常堆栈与关键里程碑。

按比例采样的配置实践

traceidratio 采样率的选取是成本与可见性的平衡：高流量服务调低、低频关键路径调高；改采样率需要重启或热更新配置。

Resource：描述数据来源的身份

Resource 是一组进程级属性，描述“谁在产出遥测”：service.name、service.version、deployment.environment 是筛选与聚合的核心字段。

Python SDK 初始化示例

Python 手动接入：创建 Resource 与 TracerProvider、挂批处理导出器、注册全局 provider，之后即可用 tracer 埋点。

Collector 配置文件示例

一份可读的 Collector 配置：OTLP 接收（gRPC 4317 / HTTP 4318）、内存保护与批处理、转发到后端；service 段声明 traces 管道。

OTLP 端口与端点约定

OTLP 默认端口成对使用：gRPC 4317、HTTP 4318；接入时按协议选端口，证书与超时按环境配置。

Span 状态与错误标记

状态取值 Unset / Ok / Error：错误要显式标记，配合属性（错误类型、状态码）让筛选“只看失败链路”可用。

Go SDK 初始化示例

Go 接入：构建 OTLP gRPC 导出器、注册 TracerProvider 并 defer Shutdown 保证缓冲数据发出；服务名通过环境变量或 Resource 注入。

语义约定：字段名统一口径

Semantic Conventions 规定属性命名：HTTP 用 http.request.method 与 http.response.status_code，数据库用 db.system、db.operation；跨服务分析靠统一字段。

Span Kind：调用方向标注

Kind 描述 span 在调用中的角色：server/client 成对接跨进程调用，producer/consumer 对接消息流，internal 表示进程内逻辑。

常用 Processor：批处理与属性加工

批处理攒批降开销，属性处理器增删改字段，过滤处理器丢弃噪声；先在 Collector 层做统一治理比每个服务各自改配置省力。

Collector 部署形态：agent 与 gateway

两种部署：每主机/每 Pod 一个 agent 就近接数据，中心一个 gateway 统一加工与出海；规模上来后分层能同时保住可靠性与治理效率。

Baggage：随链路传播的业务上下文

Baggage 携带跨服务共享的键值（如租户、灰度标记），随请求一路传递；数据量小、无敏感信息是使用底线。

告警与响应

告警规则、分级收敛与值班处理流程

‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌