Maintenance Logs: Timestamp and ObservedTimestamp

Why two timestamps exist in one log record

A maintenance log often carries more than one clock reading, and the OpenTelemetry logs data model makes that explicit rather than leaving it implicit. The specification defines Timestamp as the time when the event occurred, measured by the origin clock, and ObservedTimestamp as the time when the event was observed by the collection system (OpenTelemetry logs data model). These are not redundant copies of the same value. They answer two different questions: when did the thing happen, and when did our pipeline first see it. In a robot maintenance record, conflating the two can make a delayed export look like a delayed fault, or hide the fact that a collector sat on a record for a while before forwarding it.

The data model also notes that for events originating inside OpenTelemetry, such as those produced by the Logging SDK, ObservedTimestamp is typically set at generation time and equals Timestamp. For events that originate externally and are collected by OpenTelemetry, ObservedTimestamp reflects when OpenTelemetry's own code observed the event, measured by that code's clock. That distinction matters when you are reading a maintenance record that mixes native SDK output with re-exported lines from a robot controller.

Reading Timestamp as the origin claim

Timestamp represents the event time under the source clock and may be absent when unknown. The OTel logs data model recommends preferring Timestamp, otherwise ObservedTimestamp, when converting to a format with only one timestamp. That is a conversion recommendation; it does not establish that both fields had the same meaning or that either clock was accurate in a particular deployment.

In a maintenance context, the origin timestamp is the one you would cite if you needed to align a log line with a controller's internal sequence of operations. If the controller reports a gripper pressure reading at a given Timestamp, that value is the controller's own account of when the reading was taken. Whether the controller's clock was correct is a separate question, and the data model does not settle it.

Reading ObservedTimestamp as the collection claim

ObservedTimestamp describes observation by the collection system in the data model. For a particular extract, identify the observation boundary represented by the field instead of assuming every forwarding component replaces it. The event time and observation time answer different questions, even when their recorded values happen to agree.

For an explicitly fictional example, imagine an exported record with an event-time field and an observation-time field. Ask which component supplied each field and whether an existing observation time was preserved through later processing. A numerical difference would not, on its own, identify transport delay: clock relationships and processing context would still need evidence. No actual times, latency measurement or incident sequence are supplied here.

Where Python LogRecord.created fits

The Python logging documentation describes LogRecord.created as the record creation time in seconds since the epoch. This is a Python logging field, not an OTel field definition. Its relationship to an exported event depends on the actual record creation and mapping process. The field name does not establish a universal ordering relative to every collector or exporter.

When a Python application emits a log record, LogRecord.created is set at creation time. If that record is later mapped into an OTel log record, the mapping decision determines whether created populates Timestamp, ObservedTimestamp, or neither. The OTel data model does not prescribe a single mapping for Python's created; it defines the destination fields and their meanings, and the exporter or bridge is responsible for the translation. A maintenance reviewer who encounters a Python-origin record should therefore ask which field received created, rather than assuming it landed in Timestamp.

A standard attribute description is not a guarantee that custom record creation or later processing left the value unchanged. A supplied extract may have passed through a record factory, filter, formatter or another transformation. Ask what the contributor actually retained. This article does not inspect a logging configuration and does not treat created as immutable evidence of a physical event.

Keeping the three fields distinct in a maintenance record

A careful maintenance record can carry all three values without collapsing them: the OTel Timestamp as the origin claim, the OTel ObservedTimestamp as the collection claim, and LogRecord.created as the Python-source creation time. They may coincide, and in a simple setup where a Python app uses the OTel Logging SDK directly, they often will. But the record should still name them separately so that a later reader can see which clock each value came from.

The practical rule is to treat each timestamp as a provenance statement. Timestamp says "the source says this is when it happened." ObservedTimestamp says "the collector says this is when it saw it." LogRecord.created says "Python's logging module stamped this when the record object was built." None of these is a synchronization guarantee, and none should be read as proof that the clocks agreed. They are three labeled claims, and the maintenance reviewer's job is to keep the labels attached.

A receiving editor can ask which component supplied each field and what the contributor's mapping description supports. Related reading is available in the maintenance documentation articles and the article directory. This article provides no actual service extract or verified clock relationship.

A bounded reading routine for mixed-origin extracts

For a mixed-origin extract, identify the declared field meanings and ask what supports the origin attribution. The mere presence of a field called created does not prove that Python generated it. Likewise, equality or a gap between OTel timestamps does not classify a record as SDK-originated or externally collected. Record actual field presence and the available mapping explanation, without inferring an implementation from the values alone.

This routine does not tell you whether any clock was accurate, and it does not reconstruct an incident timeline. It only organizes what the record actually claims. That is the appropriate scope for a maintenance explainer: not to certify synchronization, but to keep the fields distinct so that a human reviewer can decide what further investigation is warranted. The OTel data model and the Python logging documentation give you the vocabulary; the discipline of separating the claims is the editorial contribution.