LabHub
学习 学习路径 课程

PCA — Prometheus 认证助理

状态全绿，指标却少了77次请求

在 LabHub 中继续学习

目标

在真实 Prometheus 中比较样本限制、删除标签、排除指标和修改源端埋点，并说明信息是否得到保留。

为什么重要

业务可能运行正常，采集却失败；也可能 up=1，但所需数据已经消失。 本实验仅使用个人 VM 中的 Prometheus 3.14.0、合成 exporter 和独立对照目标。 这是一个最多 13 个样本的小型实验，并非大规模负载、OOM 或性能测试。请勿放入真实个人信息。 服务只监听 loopback，并以 nobody 身份运行。不会修改生产 LabHub 或外部 Prometheus。 不同于既有 PCA Kubernetes 实验，本实验使用真实本地进程的 scraper 和 TSDB。 实验时长为 55 分钟，如有需要请在到期前延长。会话结束时，VM、TSDB 和学员文件将被回收。

已准备的环境

Prometheus 位于 http://127.0.0.1:9098, exporter 位于 http://127.0.0.1:9911, 对照目标使用 9912 端口。 配置文件是 /etc/pca-cardinality/prometheus.json，它是 Prometheus 所读取 YAML 的 JSON 表示。 exporter 模式位于 /etc/pca-cardinality/exporter.json，学员答案和观测结果位于 /root/pca-cardinality。 初始观测结果为 initial.json。请勿重启系统服务或删除 TSDB。 系统会将观测到的 MainPID 和 InvocationID 与基线比较，以确认没有通过重启掩盖问题。

python3 /opt/fixtures/pca_cardinality_lab.py observe 会读取当前配置、原始响应和查询。 complete N 会检查你编写的答案，并保留受限变更与实际观测结果。 2 表示增加合成用户，3 表示提高限制，4 表示删除区分标签，5 表示排除请求指标，6 表示在源端聚合并恢复限制。 1、7、8 是观测步骤。说明中的 key=value 是解释性文字，请按照 JSON 格式示例编写文件。 观测结果同时包含实际 loaded 配置和 config 声明。请并排阅读原始声明和当前应用结果。 solve N 相当于查看答案，并且只会创建尚不存在的答案。已有的错误或不完整答案必须自行修改。 prepare N 只准备之前的步骤，不会创建当前步骤的答案。grade N 只进行读取。

步骤

  1. 在 initial.json 的实际基线中确认原始响应含 5 个样本、请求时间序列为 4 条、业务 HTTP 状态为 200。在 baseline.json 中写入字符串 job=pca-cardinality，以及整数 raw_samples=5、current_series=4、business_http=200，然后执行 complete 1。独立 pca-sentinel 目标的值应为 7，up 应为 1。
  2. 在 overflow.json 中写入整数 sample_limit=8、raw_samples=13，以及布尔值 whole_scrape_failed=true、business_failed=false，然后执行 complete 2。辅助程序会把合成用户从 4 名增加到 12 名。观察一次新的抓取：原始 HTTP 状态仍为 200，但该 job 的 up=0，并出现 sample limit 错误。不要报告成仅有 8 个样本成功。
  3. 在 budget.json 中写入整数 sample_limit=16、current_series=12、total=78，以及布尔值 fixes_instrumentation=false，然后执行 complete 3。辅助程序会暂时提高 sample_limit，并执行 promtool 检查和 reload。比较实际应用的配置、13 个原始样本、当前 12 条请求时间序列以及总和 78。
  4. 在 collision.json 中写入字符串 dropped_label=user_id、布尔值 aggregates_values=false，以及整数 reported_total=1、up=1，然后执行 complete 4。查看 metric relabeling 仅删除区分标签后的三个样本。在本次固定输入中，原始总和为 78，而当前查询结果为 1。不要把 labeldrop 当成求和，也不要猜测 up 必然为 0。
  5. 在 drop.json 中写入字符串 dropped_metric=pca_checkout_requests_total，以及布尔值 requests_missing=true、up_implies_complete=false，然后执行 complete 5。读取排除请求指标 family 后的实际配置。在原始响应的 13 个样本中，只剩一个业务 gauge；虽然 up=1，但请求查询返回空向量。请将其与数值 0 区分开。
  6. 在 instrument.json 中写入字符串 mode=aggregate，整数 sample_limit=8、current_series=1、total=78，以及布尔值 user_id_removed_at_source=true，然后执行 complete 6。exporter 会在源端暴露 route 总和 78，并移除临时过滤器。从原始样本开始就只有 2 个样本；请确认三个样本中总和均得到保留。两个服务的执行标识符必须与初始值相同。
  7. 原样读取 observation-3.json 中的 result.snapshot.at 数值。在 history.json 中写入 historical_time=该数值，以及整数 historical_series=12、current_series=1 和布尔值 deletes_history=false，然后执行 complete 7。比较过去时刻实际查询的 count=12、sum=78 与当前的 count=1。不要仅凭 series 元数据列表证明过去的样本。
  8. 在 report.json 中写入整数 sample_limit=8、semantic_total=78，以及布尔值 unsafe_identifiers=false、zero_loss_from_up=false，然后执行 complete 8。确认当前的信息保留情况、独立对照组、服务未重启以及历史样本查询。不要把实验中的限制值 8 泛化为所有服务的推荐值，也不要声称个人信息已被自动删除。

参考与限制

修改仅在辅助程序审查过的声明范围内执行。如果仍有 pending 日志，不会自动重复同一请求。 如果声明变更和 reload 已完成、只有观测失败，请确认已保存的变更与声明一致，然后仅重试观测。 直接修改已完成的答案、观测结果或日志，会导致后续步骤也失败。哈希用于检测意外覆盖， 并不能作为防止同一 VM root 下所有伪造行为的安全保证。评分预算为 60 秒，准备前置步骤的预算为 90 秒。 删除标签后观察到的总和 1，是固定版本和固定输入下的结果，并非总会保留第一个值的通用契约。 空向量不同于数值 0。当前聚合不等于删除 TSDB 中的历史样本。本实验不会启用管理数据删除 API。 原始计数器值是合成的累计次数，而非每秒处理速率。还应记录降低指标维度后无法回答哪些细节问题。 三次短时观测无法保证长期性能或丢失率。8 和 16 是实验值，而非生产环境推荐限制。 配置官方文档 · HTTP API

读取原始样本与当前时间序列的基线

在 initial.json 的实际基线中确认原始响应含 5 个样本、请求时间序列为 4 条、业务 HTTP 状态为 200。在 baseline.json 中写入字符串 job=pca-cardinality，以及整数 raw_samples=5、current_series=4、business_http=200，然后执行 complete 1。独立 pca-sentinel 目标的值应为 7，up 应为 1。

一个指标名称可以对应多个标签集合。

制造业务正常但采集失败的状态

在 overflow.json 中写入整数 sample_limit=8、raw_samples=13，以及布尔值 whole_scrape_failed=true、business_failed=false，然后执行 complete 2。辅助程序会把合成用户从 4 名增加到 12 名。观察一次新的抓取：原始 HTTP 状态仍为 200，但该 job 的 up=0，并出现 sample limit 错误。不要报告成仅有 8 个样本成功。

请将业务 HTTP 与该 job 的抓取结果分开判断。

区分提高限制与改善埋点

在 budget.json 中写入整数 sample_limit=16、current_series=12、total=78，以及布尔值 fixes_instrumentation=false，然后执行 complete 3。辅助程序会暂时提高 sample_limit，并执行 promtool 检查和 reload。比较实际应用的配置、13 个原始样本、当前 12 条请求时间序列以及总和 78。

提高限制后，请检查当前时间序列数量是否有所减少。

删除区分标签后验证总和

在 collision.json 中写入字符串 dropped_label=user_id、布尔值 aggregates_values=false，以及整数 reported_total=1、up=1，然后执行 complete 4。查看 metric relabeling 仅删除区分标签后的三个样本。在本次固定输入中，原始总和为 78，而当前查询结果为 1。不要把 labeldrop 当成求和，也不要猜测 up 必然为 0。

删除标签与对数值求和是两种不同的操作。

诊断通过丢弃指标换来的绿灯

在 drop.json 中写入字符串 dropped_metric=pca_checkout_requests_total，以及布尔值 requests_missing=true、up_implies_complete=false，然后执行 complete 5。读取排除请求指标 family 后的实际配置。在原始响应的 13 个样本中，只剩一个业务 gauge；虽然 up=1，但请求查询返回空向量。请将其与数值 0 区分开。

请区分空向量与值为 0 的样本。

在源端埋点中保留语义并降低基数

在 instrument.json 中写入字符串 mode=aggregate，整数 sample_limit=8、current_series=1、total=78，以及布尔值 user_id_removed_at_source=true，然后执行 complete 6。exporter 会在源端暴露 route 总和 78，并移除临时过滤器。从原始样本开始就只有 2 个样本；请确认三个样本中总和均得到保留。两个服务的执行标识符必须与初始值相同。

不要只比较过滤后的数字，也要从 exporter 的原始响应开始比较。

区分当前查询与历史样本

原样读取 observation-3.json 中的 result.snapshot.at 数值。在 history.json 中写入 historical_time=该数值，以及整数 historical_series=12、current_series=1 和布尔值 deletes_history=false，然后执行 complete 7。比较过去时刻实际查询的 count=12、sum=78 与当前的 count=1。不要仅凭 series 元数据列表证明过去的样本。

需要使用 time 参数指定当时评估时刻的查询。

报告采集预算与信息保留的边界

在 report.json 中写入整数 sample_limit=8、semantic_total=78，以及布尔值 unsafe_identifiers=false、zero_loss_from_up=false，然后执行 complete 8。确认当前的信息保留情况、独立对照组、服务未重启以及历史样本查询。不要把实验中的限制值 8 泛化为所有服务的推荐值，也不要声称个人信息已被自动删除。

up 并不能保证所有所需指标的语义都得到保留。