hostmetrics CPU 报错

OpenTelemetry Collector 的 CPU scraper 反复报 cannot find TimesStat for cpu，缺失的 CPU 已经从容器或主机的当前集合中消失。若报错发生在 CPU 下线、热插拔或虚拟机 CPU 分配变化后，应检查利用率计算器是否还在等待旧 CPU 的时间记录。

这不能只归因于升级到 contrib 0.161.0。相同的 CPU 集合变化在 0.160.0 也能触发，已核对的稳定版 0.162.0 仍保留相关处理路径。仅仅看到 CPU 编号不连续，或 /proc/cpuinfo 与 /proc/stat 编号不同，还不足以判断这项问题。

旧 CPU 消失后，历史样本没有推进

利用率计算需要连续的 CPU 时间样本。受影响实现拿上一轮保存的 CPU 名称，逐个到当前样本中寻找；找不到其中一个时立即返回错误，没有把历史记录更新为当前 CPU 集合。

下一轮仍查找相同的旧 CPU，于是错误持续出现。采集器未必整体退出，但 CPU 指标会受到影响；不能仅凭进程仍在运行就判断采集正常。

在报错所在的容器或主机读取当前 CPU 名称，例如下面的只读查询：

awk '/^cpu[0-9]+ / {print $1}' /proc/stat

它只列出当前时间统计中的 CPU 名称。结合此前日志、CPU 分配修改记录与前后采样，判断报错中的 CPU 是否曾经存在、后来消失。不能拿宿主机的集合替代容器实际看到的集合。

稳定的非连续编号本身可以正常采集。若 CPU 集合没有变化，应继续检查数据获取、运行环境和具体版本，不要为“补齐编号”修改主机 CPU 分配。

重启可以重建历史，但只是临时恢复

确认 CPU 集合已经稳定后，可以按当前部署批准的生命周期安排 Collector 进程重启。新的采集器会建立新的内存历史，缺失的旧 CPU 不再被沿用；之后仍需至少两个连续样本，才能计算新一轮利用率。

这不是永久修复。CPU 集合再次变化时，受影响实现仍可能重新陷入同样的状态。不要把 Collector 重启安排成频繁的定时动作来掩盖问题。

重启还会影响其他接收器的内存状态与在途遥测。保留配置，按现有队列、优雅停止和部署流程处理，确认其他信号的接收与导出恢复。不要删除持久队列文件，也不要为了恢复一个 scraper 直接重启整台宿主机。

如果需要暂时减少指标，仍要核对当前版本的实际计算路径。已核对的旧实现会调用利用率计算器，不能只关闭利用率指标开关就保证避开此错误。

等待真正包含修正的版本

截至 2026 年 10 月 14 日，处理缺失 CPU、继续更新历史样本的修复仍在等待合入，不能把它写成 0.162.0 已提供的功能。后续版本应以正式产物和对应实现为准，再安排升级。

验收当前存在的 CPU 能够连续产生利用率，原来的缺失 CPU 错误不再重复；同时核对其他采集与导出链路。以后发生 CPU 集合变化时，继续观察是否复发，保留变化与报错时间。

重启或升级不能恢复此前没有采到的时间样本。若调整了配置或应用构建，回退时保留原部署约定，并单独记录监控缺口，不把错误日志消失写成历史数据已经补齐。