An EventId is a 128 bit identifier that uniquely identifies an event, such as a query. The event time recorded to the nearest microsecond, along with information about the process generating the event, ensures that all EventIds are unique. Details of this EventId are described in a design document: http://www/eng/designdocs/sawmill/adlogs.html

Attributes

• processId (type: integer(), default: nil) - process_id is an integer that identifies the process on this machine that generated this event. This id is calculated once when the server generates its first event, and may change if the process is migrated to a different host. This field has a very specific format mandated by the logs collection infrastructure, which is subject to change WITHOUT NOTICE. As of 2013-01-09, this format is: uint32 process_id = (time(NULL) << 24) + (getpid() & 0xFFFFFF); If you are generating an extended_pid directly, you MUST use one of the maintained library implementations in order to generate it properly: C++ //borg/borgletlib:extended_pid; call borg::ExtendedPid() Python //borg/borgletlib/python:pyextendedpid; call ExtendedPid() Go //borg/borgletlib/go:extendedpid; call Get() Java //java/com/google/common/logging; call EventId.getPid() If you think that you need to parse the values of this field, please contact logs-collection-dev@ to discuss your requirement.
• serverIp (type: integer(), default: nil) - server_ip is the IPv4 address or http://go/ghostid of the machine running the server that created this event message. This allows us to distinguish between events that occur at the same time on different servers. Format: 10.1.2.3 is stored as 0x0a010203, and GHostId 1 as 0x00000001.
• timeUsec (type: String.t, default: nil) - time_usec is the number of microseconds since the epoch (i.e., since 1970-01-01 00:00:00 UTC) as an int64: 1e6 (unix time) + microseconds. Applications must ensure that EventIdMessages have increasing times, artificially increasing time_usec to one greater than the previous value if necessary. Alternate implementations were considered: 1. storing unix time and microseconds separately would require a bit more storage, and the convenience of having a single value representing the time seemed more useful than having trivial access to a unix time. 2. storing unix time in the upper 32 bits would allow for more precision - up to 4G events/second, but it wouldn't print nicely as a decimal value and it seems unlikely that any single server would ever sustain more than 1M events/second. 3. Java-compatible time uses millis - this would limit servers to 1000 events per second - too small. Other names for this field were considered, including time, time_stamp, and utime. We felt that including the units in the name would tend to produce more readable code. utime might be interpreted as user time. unix timestamp 1e6 + microseconds