Where SMART runs out
SMART exposes a set of scalars: life remaining, bytes written, temperature, uncorrectable error counts. It can say a drive looks unhealthy. It cannot say why P99 for one batch of requests climbed into double-digit milliseconds inside a particular window. Telemetry covers exactly that gap, exporting controller state snapshots, event ring buffers and internal statistics as a binary log that vendor-side tooling reconstructs into firmware behaviour. It is not written for humans to read; it is written for an analysis pipeline to consume.
Two trigger modes, two collection postures
Host-initiated collection is driven from the host side for routine sampling and targeted evidence capture. The controller freezes a snapshot when the request arrives, so every subsequent chunked read reflects the same instant and no self-contradictory picture is assembled. Controller-initiated logs are produced by firmware when it detects an internal anomaly, with the host learning of them through asynchronous event notification. The first serves proactive inspection; the second ensures a rare, hard-to-reproduce fault does not lose its evidence simply because nobody was watching. When designing for fleet scale, the second usually carries more weight.
Partitioning exists because bandwidth is finite
The log is organised into data areas: earlier blocks carry the most critical information in the smallest volume, later blocks progressively more detail. Under bandwidth constraints the first areas alone are enough for triage, and the full dump is pulled only when deep analysis is warranted. At scale this is entirely practical, since dumping full logs from several dozen drives in a rack at once carries real bandwidth and storage cost, so the planned collection policy is first area from every drive and full log only from flagged drives. Log contents are vendor-private and must match the firmware version exactly; pairing version management with the parsing toolchain is a precondition for the mechanism working at all, not an optional extra.
For now its first consumer is firmware itself
With the products at product-definition/EVT stage, the first users of Telemetry are not operators but the firmware team. Logs exported while engineering samples run stress and fault-injection cases on the JH-E4U-C platform are used to check whether firmware assumptions hold: whether GC trigger frequency drifts from the design model, whether read-retry distributions match how the media was tuned, whether thermal curves have throttled without the layer above noticing. The enterprise feature baseline plans Telemetry alongside NVMe-MI out-of-band management and online update/rollback so that detect, localise, fix and staged regression can one day complete without pulling drives from the chassis. The parser, the version map and the log archiving convention therefore have to grow with the firmware; bolted on afterwards, the first logs that actually matter would already be unreadable.