How should logs from several systems be compared?¶

Logs from several systems should be compared only after each source has been understood on its own terms.

The aim is to align what each system observed, not force every record into identical wording or time.

Avoid the dangerous assumption¶

The dangerous assumption is that fields with the same label mean the same thing across different products.

They may not.

One system’s “user” may be the authenticated account. Another may record the process owner or administrator. “Success” may mean request accepted in one log and transaction completed in another.

Investigators should identify the source, event type, field definitions, time zone, timestamp stage and retention for each dataset. Preserve the original values before normalising or converting them.

Create a comparison structure that records source system, event time, ingestion time, account, device, address, action, result and linking identifiers. Note where a field is absent or inferred.

Use request IDs, session IDs, transaction IDs, message IDs and other strong identifiers before relying on time alone. Check whether one system imports or duplicates another’s records.

Contradictions should be examined, not hidden. They may reveal different stages, clock problems, failed actions, retries or incomplete collection.

Where conversion or interpretation has been applied, record the method. Another investigator should be able to follow how the comparison was made.

A simple comparison table can expose these differences early and prevent an apparently matching field from carrying more evidential weight than the source definition supports.

Operational takeaway¶

Multi-system comparison requires source-specific field definitions, preserved original times and explicit linking logic, because similar labels can describe different stages, actors and outcomes.