An operator comparing a server event with a collected log needs to know what each time field represents. A source can report when something happened, while the collection system records when it observed the event. Preserve both meanings during an investigation.
Identify the field before sorting the timeline
The OpenTelemetry Logs Data Model defines Timestamp as event time measured by the source clock. ObservedTimestamp records when the collection system observed the event, using that system’s clock. Source time is optional when it is unknown. For events originating inside OpenTelemetry, the two fields are commonly equal.
Ask which field your search interface uses for its time filter and display. Record the answer beside the query used in the investigation. Then check the export: a column labelled “time” needs an identifiable mapping to the underlying field.
If your pipeline transforms records, inspect the relevant configuration and a permitted sample record. Keep the mapping with the runbook so the next operator can reproduce the same search.
Work through a small example
Consider this invented example for explaining the fields. A source reports an event at 14:00:00Z, and the collector observes it at 14:00:03Z. The displayed values differ by three seconds.
That comparison raises several checks. Confirm that the two values belong to the same event, identify which systems supplied them and examine the available clock-synchronization evidence. Collection delays, buffering and clock differences can all matter when interpreting the record. The arithmetic alone cannot assign the entire interval to one network hop.
Write the conclusion at the level the evidence supports. You can report the two recorded times and the field definitions immediately. A statement about actual transit time requires the additional timing and pipeline evidence needed to support that measurement.
Retain the time zone and clock context
A display can show UTC while an exported file uses a local offset. Include the date and time-zone information when sharing a timeline. RFC 3339 defines timestamp representations with a date, time and UTC relationship, including the Z suffix and numeric offsets. Preserve the original value when producing a normalized comparison.
NIST’s Internet Time Service guidance explains that operating systems can synchronize clocks through NTP. For an investigation, ask the system owner to check the applicable synchronization status and any recorded exceptions around the event window. A configured time source alone leaves the historical condition of the clock unresolved.
Keep clock changes in the investigation notes. If a host restarted, changed its time source or had a known synchronization problem, record when that happened and which records may be affected. Avoid silently correcting the original evidence while preparing a more readable timeline.
Test what a receiving operator can see
Use a permitted test record with a known identifier to review the logging path. Record its source field names, the collector’s observation fields and the names shown in the destination. Compare the original record with a downloaded export and the version attached to an incident.
- Check whether both timestamp meanings survive each step.
- Identify the time field used for filtering, sorting and alert evaluation.
- Record how the destination handles a missing source timestamp.
- Confirm that equipment or service identity remains attached to the event.
This exercise evaluates the records available to the responder. Document any step you cannot inspect and the person responsible for explaining it. An undocumented transformation should become a specific follow-up item.
Write the comparison rule into the runbook
A useful timeline note names the event, the source, the time fields and the query window. It also states any unresolved clock or collection issue that limits interpretation. Keep that note with the records used to reach the operating decision.
For example, a responder investigating a service interruption might compare source events first, then inspect observation times to understand when those records became available to the collection system. The runbook should explain that choice and preserve enough information for another operator to question it.
When discussing monitoring requirements with Valen Systems, bring one representative event and the decision your team needs to make from its history. The field mapping and known timing gaps provide a concrete basis for reviewing whether the available observations can answer that question.
Sources
- OpenTelemetry — Logs Data ModelPublication date not stated. Retrieved October 17, 2026.
- NIST — Internet Time ServicePublication date not stated. Retrieved October 17, 2026.
- IETF RFC 3339 — Date and Time on the Internet: TimestampsPublication date not stated. Retrieved October 17, 2026.