OCP NVME SSD规范解读-12.Telemetry日志要求

本文主要是介绍OCP NVME SSD规范解读-12.Telemetry日志要求，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

以NVME SSD为例，通常大家想到的是观察SMAR-log定位异常，但是这个信息在多数情况下无法只能支撑完整的定位链路。

定位能力的缺失和低效是数据中心问题解决最大的障碍。

为了解决这个问题，Meta的做法是推进OCP组织加入延迟记录页面。同时NVME协议也增加了Telemetry盘片的故障定位能力。

4.9章节详述了主机和控制器触发的Telemetry日志功能，这是数据中心NVMe SSD规范的一部分，旨在增强客户和供应商对于设备监控和调试的可见性。这一功能通过对设备生成的数据进行分区和标准化格式化，使得快速定位和诊断故障成为可能。

设计原理是通过提供一种机制让主机能够主动请求或者控制器自身在发生关键事件时生成Telemetry日志数据，以便于实时或事后分析设备行为和性能问题。数据划分为影响I/O和不影响I/O两类：

无论是主机触发还是控制器触发的遥测日志中，数据区域1和2所使用的数据格式相同，并且两个来源的日志数据应当是相同的报告数据。

针对目前已有的一些NVMe日志已经被整合进Telemetry数据区域1中，以便在轮询Telemetry数据区域1时可以一次性收集所有监控信息。

4.9.7节专门讨论了Telemetry数据的要求，它在数据中心NVMe SSD规范中扮演着至关重要的角色，旨在提升设备故障快速诊断的能力。以下是该节内容的详细分析解读：

- TEL-4规定，在Telemetry控制器触发和主机触发的日志页面中，原因标识符字段应当始终记录最新的故障标识符，即便设备经历电源循环或复位，也不应清除这些标识符，以保持故障历史记录的一致性和连续性。

- 规定了Telemetry数据区域1和2的标准格式，适用于Telemetry Host-Initiated Log（日志标识符07h）和Telemetry Controller-Initiated Log（日志标识符08h）。这两个区域分别用于存储不影响当前I/O性能/延迟的数据和影响I/O性能/延迟的数据。

4.9.14.2节详细定义了一系列事件类别的信息，这些类别是为了协助调试设备问题而设计的。事件类别的目的是为数据中心NVMe SSD在运行过程中可能出现的各种异常情况或值得关注的行为提供详细的分类记录。以下是各事件类别的解读：

Timestamp Debug Class (01h)：此事件类别记录与时间戳相关的调试信息，可能包括设备操作的时间点、周期性任务的执行时间等，用于分析系统时序和响应时间问题。
PCIe Debug Class (02h)：此类别关注与PCI Express（PCIe）接口相关的事件，比如数据传输错误、链路层事件、电气信号异常等，有助于解决物理层通信问题。

NVMe Debug Class (03h)：这一类别的事件集中在NVMe协议层面，包括但不限于命令处理错误、队列溢出、资源冲突等，用于诊断NVMe控制器内部逻辑和功能异常。

Reset Debug Class (04h)：这类事件记录了与设备复位有关的情况，如意外复位、软件触发的复位、硬件故障引发的复位等，有助于查明导致复位的根本原因。

Boot Sequence Debug Class (05h)：此事件类别追踪设备启动序列中的问题，如固件加载失败、初始化过程中的异常等，对于优化启动过程和确定开机故障非常关键。
Firmware Assert Debug Class (06h)：记录固件内部assert异常事件，当固件检测到不应该发生的条件或状态时触发，用于开发和测试阶段的代码质量保证，以及生产环境中发现潜在软件缺陷。