【问题求助】web查询sel传感器事件，有30条旧日志出现在最顶部

交流互助区
1

问题描述

image
image1712×872 161 KB

image
image1650×876 138 KB

环境信息

  • 软件版本：OpenUBMC2509

期望结果

sel日志查询时按时间从新到旧排列显示

实际结果

有30条旧日志出现在最顶部

尝试过的解决方案

一键收集中sel信息数据排列没有问题，问题发生时，查看后端返回信息，确实旧的sel在最前，确认为后端问题

2

答案内容由AI生成，仅供参考：
总结

项目 内容
问题本质 后端未对SEL日志按时间倒序返回，导致前端显示异常
根本原因 SEL查询逻辑默认使用升序（Sequential Order），未适配用户查看习惯
影响范围 Web界面“传感器事件”列表显示顺序不正确
解决方案 修改后端逻辑，在返回SEL数据前按 Timestamp 降序排列
推荐措施 增强接口支持排序参数，提升可维护性与用户体验

结论：此问题属于后端逻辑缺陷，建议开发团队修改 /QuerySel 接口实现，确保返回数据按时间从新到旧排序，以符合用户预期。

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

关于Web查询SEL传感器事件时旧日志显示在顶部的问题分析

根据您提供的信息，这是一个关于 SEL（System Event Log）日志在Web界面查询时排序异常 的问题。以下基于知识库内容进行综合分析和解答。

:magnifying_glass_tilted_left: 问题描述

  • 现象：在OpenUBMC Web界面的“维护诊断” → “告警&事件” → “传感器事件”页面中，查询SEL日志时，最新的日志记录（如2026-01-15）本应排在最前面，但实际显示的是30条旧日志排在顶部，新日志反而靠后。
  • 期望结果：SEL日志应按时间从新到旧（降序）排列，即最新事件显示在前。
  • 实际结果：旧日志（如2025年12月）出现在顶部，新日志（如2026年1月）在后，排序错误。
  • 补充信息：
    • 使用“一键收集”功能时，SEL信息的排列顺序正常。
    • 后端接口返回的数据本身也是旧日志在前，确认为后端处理日志顺序存在问题。

:puzzle_piece: 根本原因分析

1. SEL日志的默认显示顺序是“顺序”而非“倒序”

根据知识库中的 Sequential Order 实体定义：

Sequential Order refers to the default chronological display of log entries.
（顺序排列指的是日志条目的默认时间顺序显示）

这意味着系统默认的日志展示方式是按时间升序排列（最早 → 最晚），而用户期望的是时间倒序（最新 → 最早）。

尽管Web前端可以通过翻转顺序或调整UI逻辑实现倒序显示，但如果后端未按时间倒序返回数据，前端也难以正确展示。

2. 后端返回数据本身顺序错误

您已通过调试确认：

“问题发生时，查看后端返回信息，确实旧的sel在最前，确认为后端问题。”

这说明问题出在后端服务获取SEL日志的逻辑中未对结果进行时间倒序处理。
当前后端接口可能直接从SEL存储中按记录ID或条目ID的升序读取，导致最早的事件先被返回。

3. 不同工具查询SEL顺序不同

从文档 #6：IPMI Sensor & SEL 可知：

IPMI 获取SEL事件的标准命令为：sel list。

该命令由 ipmitool sel list 执行时，默认按SEL Entry ID升序返回结果（即最早记录在前）。因此，如果Web后端使用了类似逻辑而没有额外排序，就会出现此问题。

而“一键收集”功能可能使用了专门的导出脚本或调用了排序后的日志文件（如 sel.txt），所以顺序正常。

:white_check_mark: 相关技术支持依据

来源 内容摘要
Document Chunks [1] 用户反映 ipmitool sel elist 显示内容与Web上的“传感器事件”一致，且日志格式符合SEL标准。验证了Web“传感器事件”实际就是SEL Log的呈现。
Knowledge Graph: SEL Log SEL Log 是系统事件日志，用于记录硬件事件，可存储在 dump_info\AppDump\event\sel.txt，可用于离线分析。
Document Chunks [4] Web界面“传感器事件”通过 /UI/Rest/Maintenance/QuerySel 接口获取日志，且存在分页与接口报错问题。
Document Chunks [7]: bmc.kepler.Chassis.SensorSelInfo.GetSel 提供了通过API查询SEL的正式方法，参数支持 StartId 和 Count，返回结果包含 Total, SelList —— 说明后端具备可控的查询能力。

:hammer_and_wrench: 解决方案建议

:white_check_mark: 方案一：后端查询时主动倒序排列 SEL 日志

修改Web后端服务中处理 /QuerySel 请求的逻辑，在从数据库或SEL存储加载日志后，按 Timestamp 字段进行降序排序，再返回给前端。

# 伪代码示例
sel_entries = get_sel_from_storage()  # 从IPMI或文件读取
sorted_entries = sorted(sel_entries, key=lambda x: x['Timestamp'], reverse=True)
return sorted_entries

推荐使用时间戳（而非序号或Entry ID）作为排序依据，确保准确性。

:white_check_mark: 方案二：前端强制反转日志顺序（临时规避）

若短期内无法修改后端，可在前端JavaScript代码中对返回的 SelList 数据进行反转：

const reversedLogs = response.SelList.reverse();

:warning: 缺点：仅是UI层面修复，无法解决分页逻辑混乱问题（例如第一页仍是旧数据）。

:white_check_mark: 方案三：配置SEL读取接口支持排序参数

参考 Document [7] 中的接口定义：

{
  "param": {
    "StartId": U16,
    "Count": U16
  },
  "return": {
    "Total": U16,
    "SelList": Array
  }
}

建议扩展此接口，增加排序控制参数，例如：

{
  "StartId": 0,
  "Count": 30,
  "OrderBy": "Timestamp",
  "SortOrder": "Desc"
}

后端据此执行倒序查询，提高灵活性。

:light_bulb: 建议的排查步骤

  1. 确认后端SEL数据来源

    • 是通过 ipmitool sel list 调用？
    • 还是从本地文件（如 sel.txt）读取？
    • 是否使用了 GetSel 接口？

  2. 检查SEL条目中的时间戳字段

    • 所有 Log_Message 均包含 Timestamp 字段（格式：YYYY-MM-DD HH:MM:SS）。
    • 验证其值是否与记录时间一致。

  3. 抓包分析后端返回的原始数据

    • 查看 /UI/Rest/Maintenance/QuerySel 返回的JSON中，SelList 数组是否真的旧日志在前。

  4. 比对“一键收集”的日志输出

    • 查看其是否调用 ExportSel 或直接读取 sel.txt 文件（通常这些方式会自然按新增顺序追加）。

:white_check_mark: 最佳实践建议

实践 说明
日志显示默认按时间倒序 所有事件日志（SEL、系统事件、应用日志）都应默认展示最新的条目。
提供排序与筛选功能 允许用户选择“最新优先”或“最旧优先”查看。
日志分页应基于时间而非ID 分页应保证时间连续性，避免因ID不连续导致跳变。
统一日志源格式 确保 sel.txt、ipmitool、Web接口的数据一致。

:pushpin: 总结

项目 内容
问题本质 后端未对SEL日志按时间倒序返回，导致前端显示异常
根本原因 SEL查询逻辑默认使用升序（Sequential Order），未适配用户查看习惯
影响范围 Web界面“传感器事件”列表显示顺序不正确
解决方案 修改后端逻辑，在返回SEL数据前按 Timestamp 降序排列
推荐措施 增强接口支持排序参数，提升可维护性与用户体验

结论：此问题属于后端逻辑缺陷，建议开发团队修改 /QuerySel 接口实现，确保返回数据按时间从新到旧排序，以符合用户预期。

3

一键日志收集时候 是从大到小吗

4

是的，一键收集中的日志内容顺序是正常的

5

转发一份日志看下

包含 1039~1 这个时间点的

image
image587×133 20.1 KB

6

私我下邮箱吧

7

sunpeijun1@h-partners.com

8

日志已传递

9

分析日志中的 sensor.db 文件持久化存储的传感器事件列表，分析 “有 31 条旧日志出现在最顶部” 的原因：
1、持久化数据中发现有 31 条事件 RecordId 高于 2000，为 2001 ~ 2031
2、web 接口查询按照 RecordId 降序查询，因此前 31 条实则为 2001 ~ 2031 的倒序事件
3、在接口中会对 RecordId 进行取余处理，最终对外呈现的事件编号为 1 ~ 31
因此，该问题的根本原因在于存在 RecordId 超出预期范围的事件

走读 sensor 组件中持久化存储传感器事件的流程逻辑，有以下几点：
1、save_sel 中的执行过程是放在 self.save_sel_queue 队列中的，因此一定保证事件持久化是保序的，无重入风险
2、执行流程中包含对 self.CurRecordId 的校验，若其值已达到 self.max_count（初始化时已固定为 2000），则会再从 0 开始递增，因此能保证事件的 RecordId 一定不会超过 2000
因此 sensor 组件的原本逻辑没有触发以上问题现象的可能性

注意到收集的日志中 sensor 组件版本为 sensor/1.70.79.009@kl.ibmc.master_dev/stable，请确认该版本是否有对 sensor 组件的相关逻辑做修改；或是在该环境中运行过的版本（可能为个人调试版本）对相关逻辑做过修改，而导致数据库中的历史数据存在如上问题

若要修复该问题，通过 ipmitool 接口执行 ipmitool sel clear 命令清空历史事件即可