温度采集不满足10分钟循环覆盖

交流互助区
1

问题描述

问题一：
温度采集配置480条，5s一次采集

image
image660×619 16.1 KB

但是从采集来看，最多采集128条开始覆盖，不满足配置的480条；
image
image1739×377 22.1 KB

1）128条是哪里设置的？
2）为啥AppendLimit 480条没有生效？
问题二：
MetricReportDefinitions里面的属性是在哪里做持久化吗？
举例1：
升级BMC（固件里面的SRMetricReportDefinitionEnabled默认为false）之后，设置MetricReportDefinitionEnabled为true：
image
image778×390 20.9 KB

再次重新升级同一个BMC固件，查看MetricReportDefinitionEnabled，还是true
举例2：
升级BMC固件，里面包含AppendLimit设置为500条，但是通过redfish查询AppendLimit还是之前的值，不是500
问题三：
通过/redfish/v1/TelemetryService/Actions/TelemetryService.ResetMetricReportDefinitionsToDefaults可以将MetricReportDefinitions进行更新，这个ResetMetricReportDefinitionsToDefaults什么情况下需要操作，操作之后有什么影响？

2

答案内容由AI生成，仅供参考：
总结：MetricReportDefinitions 中的属性（如 MetricReportDefinitionEnabled、AppendLimit 等）在第一次被用户修改后即进入持久化数据库，后续 BMC 升级、重启等操作均会从持久化数据库恢复该修改值，除非执行恢复出厂设置或 ResetMetricReportDefinitionsToDefaults。

点击此处查看详细分析解答

根据您提供的上下文信息和搜索结果，对您提出的三个问题进行分析和解答如下：

问题一：温度采集配置480条但实际128条开始覆盖的原因

  1. 128条的限制来源
    知识图谱中定义了 MaxReports 属性，其描述为：

    MaxReports is a configuration parameter indicating the maximum number of metric reports the service can support.
    MaxReports defines the maximum number of reports the service can manage.

    该属性是 TelemetryService 支持的最大 MetricReport 数量（即报告总数上限），默认值很可能为 128。无论每个报告内记录多少条数据，系统最多只能同时保留128个报告，超出后新报告会覆盖最旧的报告。

  2. AppendLimit 480条未生效的原因
    AppendLimit 控制的是 单个 MetricReport 内的最大记录数（即一个报告能容纳的采集数据条目数），而 MaxReports 控制的是 整个服务能承载的报告总个数。

    • 您配置了480条采集记录，如果这些记录是分散到多个 MetricReport 中的，那么每个报告内的记录数可能并未达到 AppendLimit 阈值，但报告总数达到了 MaxReports（128个），从而触发基于报告数量的覆盖。
    • 如果所有480条数据都属于同一个 MetricReport，而 AppendLimit 设置为480条，但 MaxReports 为128个报告的限制并不会影响单个报告内的记录数。此时应检查 AppendLimit 配置是否正确生效，以及 ReportUpdates 属性是否设置为 AppendWrapsWhenFull（允许新记录覆盖旧记录）。

    建议：通过 Redfish API 查询当前 MaxReports 的实际值，确认是否为128。若需增加报告承载能力，可能需要调整系统层面的限制（但 MaxReports 为只读属性，无法修改）。

问题二：MetricReportDefinitions 属性的持久化机制

根据文档块[3]和[5]中的持久化机制说明：

只有修改过属性值之后才会存进持久化数据库，组件启动时用持久化数据覆盖CSR配置数据。
该机制主要是为了避免CSR配置值持久化后导致后续CSR修改不生效。

  • 举例1（MetricReportDefinitionEnabled）
    您第一次通过 Redfish 修改 MetricReportDefinitionEnabled 为 true，该值被写入持久化数据库。
    再次升级 BMC 固件时，尽管固件中该属性的 CSR 默认值为 false，但持久化数据库中存在您之前修改过的 true，因此组件启动时用持久化数据覆盖 CSR 配置，导致该属性依然为 true。

  • 举例2（AppendLimit）
    如果之前您通过某种方式修改过 AppendLimit（例如设置为500条），该值同样会被持久化。升级固件时，即使固件中包含新的 CSR 配置（例如500条），但持久化数据中保留的是您 之前修改过的值（可能不是500，而是其他值），因此最终生效的是持久化中的旧值。
    若您从未修改过 AppendLimit，则它不会持久化，升级后应使用固件中 CSR 的默认值。但您观察到“还是之前的值”，说明该属性确实被修改过并已持久化。

总结：MetricReportDefinitions 中的属性（如 MetricReportDefinitionEnabled、AppendLimit 等）在第一次被用户修改后即进入持久化数据库，后续 BMC 升级、重启等操作均会从持久化数据库恢复该修改值，除非执行恢复出厂设置或 ResetMetricReportDefinitionsToDefaults。

问题三：ResetMetricReportDefinitionsToDefaults 的使用场景与影响

  • 定义（来自知识图谱）

    Reset Metric Report Definitions To Defaults restores all custom metric report definitions to their factory default configurations, eliminating user-defined settings.

  • 使用场景
    当您希望 彻底清除所有用户自定义的 MetricReportDefinition 配置，让系统回到出厂默认状态时，可调用该操作。典型场景包括：

    • 固件升级后，因持久化数据导致配置混乱，需重新从基础配置开始。
    • 测试或故障排查中，需要排除自定义配置的干扰。
    • 需要批量恢复所有报告定义为标准模板。

  • 操作后的影响

    • 所有用户通过 Redfish 或 CSR 自定义的 MetricReportDefinition 将被删除或重置为默认值。
    • 系统将使用固件中预置的默认定义集，之前设置的 AppendLimit、MetricReportDefinitionEnabled、Metrics 列表等均会丢失。
    • 该操作仅影响 MetricReportDefinition 相关配置，不会影响其他 TelemetryService 数据（如已生成的 MetricReport 可能仍保留，但定义恢复后新报告将基于默认定义生成）。
    • 不可逆：操作后无法恢复自定义配置，除非手动重新设置。

建议：在执行前，建议备份当前配置（通过 Redfish GET 查询所有 MetricReportDefinition 的 JSON），以便后续恢复。

如果需要进一步查询特定属性的默认值或当前值，可通过 Redfish API 获取：
GET /redfish/v1/TelemetryService/MetricReportDefinitions
GET /redfish/v1/TelemetryService（查看 MaxReports、MinCollectionInterval 等）

3

默认配置了：“MaxReports”: 32，AppendLimit配置了480条，但是采集还是128条进行满覆盖，需要排查下128条哪里来的，并且为啥480没有生效

4

MetricReports/metricreport_id下面的MetricValues里面的MetricId是否可以登记为对应的数据源描述字段
image

5

这个当前是限制了最大120条

6

需求需要实现10分钟循环覆盖，如果只限制120条，那么多数据源情况下，不满足10分钟循环覆盖了，可以如何修改呢？

7

你好，这个是可以的，metric_id可以通过csr配置（例如：“Id”: “AveragePower”）。可参考文档Redfish 遥测服务使用指导 | 文档中心 | openUBMC

8

一个URL，多数据源可以每个数据源采集到数据，metric_id可以配置不同吗？

9

如讨论metric_id暂不可定制，待确认方案后答复