Redfish Telemetry: A Recent Report Is Not the Same as a Current Reading

Read the two timestamps at their own boundaries

DMTF's MetricReport v1.5.2 defines the report-level Timestamp as generation time. Each MetricValue has its own Timestamp for when that value was obtained, which can differ from instance creation. Here, observation time means that obtained time, interpreted with the value's time scope; it does not certify a physical sensor's sampling instant.

A report assembled recently can therefore contain older observations. Using its generation time for every entry would erase information needed to compare the offers.

Both timestamp fields allow null, and neither is required by this base schema. An absent or null value leaves that time unresolved. It is not zero age, nor permission to copy the report time into the missing entry.

References: [RF01]

Identify the source property before comparing readings

Where supplied in a returned MetricValue, MetricProperty identifies the source property by URI and JSON pointer notation. MetricId identifies the applicable MetricDefinition by its Id. Keep those associations with the actual equipment identity; an attractive display label is insufficient to establish that two offers describe the same quantity.

MetricDefinition v1.3.6 places the measurement unit in Units, using case-sensitive Unified Code for Units of Measure conventions, while acknowledging that UCUM does not cover every unit. Preserve the reported unit and definition. A numerical string alone does not establish what was measured or how to compare it.

This matters across a fleet: a repeated label can conceal different component boundaries or quantities. Resolve identity and meaning before comparing the times, so that a recent value for one property cannot stand in for a required observation of another.

References: [RF01][RF03]

Read an interval result as an interval result

MetricReportDefinition v1.4.7 describes which properties feed the report and any collection function. Its CollectionTimeScope distinguishes Point from Interval. For Point, the corresponding metric-value Timestamp identifies the point. For Interval, that timestamp identifies the interval end and CollectionDuration supplies its duration.

A CollectionFunction of Average represents an average over the defined duration. It does not establish a point reading at that interval's end. Report generation time defines neither boundary. Read the returned definition rather than infer a function or duration from the number or dashboard layout.

In this version, an unspecified CollectionFunction means no calculations are performed on the selected properties. Missing time-scope information still leaves coverage unresolved; it does not justify inventing an interval.

References: [RF02]

Compare a one-minute-old report with the observations inside it

RF-TIME-01 is a wholly fictional comparison of returned evidence. At a review time of 12:05:00, two offers show a report generated at 12:04:00. All example times share a stipulated consistent UTC basis on the same day. This assumption supports the arithmetic; it claims no actual clock accuracy or synchronization.

Offer One supplies only that report time and a green status badge. Its report is 60 seconds old at review. The display leaves the individual observation times, calculation and status-owning resource unidentified. The buyer cannot determine those missing facts from the badge.

Offer Two supplies the same report time plus identified evidence for fictional resources A and B. A's selected property is a Point result timestamped 12:03:00. Its observation age is 120 seconds at review. B's selected property is an Interval average, with a duration of 60 seconds and metric-value timestamp 12:00:00. That average covers 11:59:00–12:00:00. Its interval end is 300 seconds before review.

Offer Two lets the buyer distinguish three ages: 60 seconds since report generation, 120 seconds since A's point and 300 seconds since B's interval ended. B's duration is another quantity: 60 seconds of represented time. Neither offer's report time makes A and B simultaneous.

For a question about B's average over 11:59–12:00, Two identifies the relevant result. For B's point value at 12:05, that same average supplies no answer. A's point also leaves its later behavior unresolved. No freshness threshold, numeric metric reading or acceptable operating condition is stipulated.

Now stipulate that Two separately returns Health equal to OK on identified resource A, whose own schema supports Status. That additional result supplies neither a later point for A nor any missing observation for B. The example contains no device measurements or actual health assessment.

References: [RF01][RF02][RF04]

Keep Health, HealthRollup and State on their owning resource

The common Resource schema defines Health for the resource without its dependent resources, and HealthRollup for that resource including its dependencies. State is a separate property describing resource state. Health uses OK, Warning and Critical categories; these are not ages or durations.

Retain the actual resource reference and field behind a status display. Health for one component cannot silently become HealthRollup for a system or a fleet-wide result. MetricReport v1.5.2 has no standard Status property: a separately supplied resource status must stay separate.

A green status can answer a scoped health question without establishing complete sensor history, synchronized capture or workload correctness. The time a status was retrieved also does not, by itself, identify when its underlying assessment was updated.

References: [RF04][RF01]

Choose the offer that answers the intended observation question

Suppose the buyer also names C and D in its requested fleet population, while Two's returned definition expressly selects properties only on A and B. That evidence establishes no observation coverage for C or D. It also does not establish a collection failure: they may simply lie outside the offered selection. The difference is a scope question to resolve against the purchase.

A buyer seeking recent points needs evidence for those points on the requested properties and equipment. A buyer seeking interval history needs the relevant interval results and their coverage; one average does not reconstruct the observations within it or the rest of the history. A buyer seeking resource health needs the correctly scoped health field. These can be complementary deliverables, each answering its own question.

The schema versions discussed here were checked on October 20, 2026; Resource.json is an unversioned common schema checked that day. Their publication establishes model meanings, not that an offered BMC implements optional telemetry, supplies this metadata or meets a particular profile. Resolve the actual product, version and returned evidence before relying on the offer.

References: [RF02][RF04]

Use the project inquiry for a separate physical installation

If the equipment decision also requires physical management cabling, Leviathan's Structured Cabling & Fiber Installation service is the relevant next step. Use the linked service and project inquiry with a nonconfidential summary of the equipment, approved physical endpoints and routes, requested installation work, labels and handoff records.

This article explains telemetry evidence for the buyer. Telemetry integration, management software, monitoring and operating decisions belong to the separately appointed platform and software teams.