指标重标记的时机
指标重标记在抓取返回之后、写入存储之前处理样本：丢弃不需要的指标、删除高基数或敏感标签、把标签改名。它是控制序列数、保护存储的主要手段，也是唯一能在入库之前做取舍的位置。
丢弃是不可逆的
丢弃是单向操作：入库之后无法追溯被丢掉的数据。因此规则改动应先在测试环境验证，并检查告警与看板依赖的指标是否被误删，否则会出现看板空白、告警静默失效这类问题，而且很难第一眼看出原因。
基本信息
| 执行时机 | 抓取返回后、入库之前 |
|---|---|
| 作用对象 | 样本及其标签，而不是目标 |
| 常用动作 | 丢弃指标、删除标签、标签改名 |
| 主要风险 | 丢弃之后无法追溯原始数据 |
典型使用场景
- 控制基数：丢弃明细类指标或删除高基数标签
- 清理无用指标：去掉体积大且无人使用的指标
- 合规要求：删除包含敏感信息的标签
- 统一命名：把不同来源的同义指标改成统一名称
- 容量保护：在写入前削减样本量，避免存储压力过大
丢弃指标与清理标签
丢弃指标与清理标签
scrape_configs:
- job_name: app
static_configs:
- targets: ['10.0.1.21:8080']
metric_relabel_configs:
# 丢弃体积大且无人使用的指标
- source_labels: [__name__]
regex: 'go_(gc|memstats)_.*'
action: drop
# 删除敏感与高基数标签
- regex: '(token|session_id)'
action: labeldrop动作与场景
| 动作 | 作用 | 典型场景 |
|---|---|---|
| 丢弃指标 | 整条指标不再入库 | 清理无用或高基数指标 |
| 删除标签 | 保留指标但减少维度 | 移除敏感或高基数标签 |
| 标签改名 | 统一命名口径 | 合并同义指标 |
| 只保留白名单 | 仅留下指定指标 | 严格控制采集范围 |
改动前的检查
- 先列出目标指标被哪些看板与告警引用
- 规则的作用范围要明确，避免正则过宽导致误删
- 改完观察序列总数变化与关键告警是否仍在评估
在采集端做取舍比事后治理更省成本：规则生效后序列数与存储占用会立即改善。
丢弃不可逆：入库后无法追溯被丢弃的数据，规则上线前务必先在测试环境验证影响面。