Skip to main content

Name

log_hires_timestamp — enable microsecond resolution for log timestamps

Synopsis

log_hires_timestamp = true

Description

When log_hires_timestamp is set to true, Momentum writes log timestamps with microsecond (1 µs) resolution instead of the default 1-second resolution.

Rationale

Several Momentum log files are produced concurrently by independent loggers (for example mainlog, bouncelog, rejectlog, and paniclog). With the default 1-second resolution, many events that happen within the same second share an identical timestamp, and the relative ordering of events between files becomes ambiguous when the logs are read together — for instance when merging them in a log viewer such as lnav or feeding them into a SIEM or analytics pipeline. Microsecond timestamps preserve the true ordering across files, which is essential for diagnostics, latency analysis, and other investigations.

Scope of the option

The setting is global and affects every log file whose timestamps are produced by the core logging code, including:

  • mainlog (reception, delivery, transient failure, permanent failure, heartbeat, accounting and import records — see mainlog)

  • bouncelog (bounce and heartbeat records — see bouncelog)

  • rejectlog (rejection records — see rejectlog)

  • paniclog (panic and HTTP request records — see paniclog)

  • Custom logs produced by custom_logger and custom_bounce_logger

  • Chunk logs produced by chunk_logger

  • Message generation logs produced by the msg_gen module

  • Critical messages written to stderr by the ec_logger, formatted with timestampformat

The effect on each timestamp depends on how it is rendered:

  • Numeric (epoch) timestamps. A timestamp emitted as a decimal Unix epoch value (for example, the first field of every mainlog, bouncelog, rejectlog, or paniclog line) changes from a 10-digit seconds-since-epoch value (1064868656) to a 16-digit microseconds-since-epoch value (1064868656123456). No separator is inserted, so the field remains a single integer that downstream parsers can keep treating as a number.

  • Formatted (strftime) timestamps. Timestamps rendered through a strftime(3) format string — such as the timestamp_format of chunk_logger, the %t{...} macro of custom_logger, or timestampformat — keep the configured format, but every %S or %T conversion is followed by a .NNNNNN six-digit microsecond fraction. For example, the default [%a %d %b %Y %H:%M:%S] becomes [%a %d %b %Y %H:%M:%S.NNNNNN] and renders as [Mon 20 May 2026 14:32:17.482915] .

When log_hires_timestamp is false (the default), timestamps are emitted exactly as in previous releases of Momentum, with 1-second resolution and no .NNNNNN fraction.

Compatibility

Tools that parse the numeric epoch field must accept either 10 or 16 decimal digits when this option is enabled. The Perl modules under Ecelerity::Log shipped with Momentum (Ecelerity::Log::Auto, Ecelerity::Log::Bounce, Ecelerity::Log::Reject, Ecelerity::Log::Statp) recognize both forms; when the source field is in microseconds, they expose it on the parsed record as epoch_us and keep populating epoch with the integer seconds, so existing consumers continue to work unchanged.

Online Modification

log_hires_timestamp is not online-tunable. Changing the option requires a Momentum restart.

Scope

log_hires_timestamp is valid in the global scope.

See Also

Was this page helpful?