At some time in the last six months, Apple has changed the behaviour of unified logging in Sierra. Most significantly, this has extended the period for which log entries are kept, making them of even greater value for diagnosis and in forensic analysis.

When I assessed this in March 2017, the default period for which log entries remained, appeared to be determined by log size, and amounted to several days.

In Sierra 10.12.6, the current period is about 20 days, possibly even more.

The present structure of log files is also quite different from early releases of Sierra.

In Sierra 10.12.6, two folders are used to contain log files when they are stored on disk: /var/db/diagnostics/ and /var/db/uuidtext/.

/var/db/diagnostics/ consists of:

• The folder Persist, which contains the main tracev3 files which consistute the saved log, numbered in sequence. These are written up to a maximum of just under 10.5 MB each, then the next is opened and used to contain fresh log entries. Apple does not document the tracev3 format, so at present these are only accessible to the log command and Consolation.
• The folder Special, which contains additional tracev3 files holding supplementary log content. Although numbered sequentially, these are not filled in order, and range in size up to just over 2 MB.
• The folder timesync, which contains timesync files numbered in order, extending back to the Sierra upgrade a year ago. These appear to contain information about time synchronisation between the system clock and ticks.
• A series of plain text files named logdata.statistics.0.txt and others in numeric sequence, which form a master log and statistical summary for all other log files.
• Other data files such as shutdown.log containing predominantly plain text details of significant log events.
• version.plist.

/var/db/uuidtext/ consists of a series of folders, named 00 to FF, each containing files named by UUID for specific log events, which extend beyond normal log entries. These include crash events and other items which overflow single line entries in the log. There is another folder named dsc which contains similar files.

Of all these files, the most accessible and informative are the log logs named logdata.statistics.0.txt (and others in the numbered series) in /var/db/diagnostics/. Among the events recorded in these logs are:

• Log file rotation. When the log closes an old tracev3 log file (including those in the folder Special) and opens a new one, this entry records details, including the total number of log entries in the old file, and a summary of the number of entries and percentage written by each process.
• Memory log rollover. When log entries which are only stored in memory are rolled over, this entry records details, including a similar statistical summary on log entries.
• Purging of records in /var/db/uuidtext/, giving the UUIDs of all records being removed.
• Periodic compactions, which delete old files in the Persist and Special folders.

A glance through my iMac’s log log reveals that one process is responsible for making almost half of all log entries – /System/Library/Frameworks/WebKit.framework/Versions/A/XPCServices/com.apple.WebKit.Networking.xpc/Contents/MacOS/com.apple.WebKit.Networking – and one for almost half of all entries in the log held in memory – /usr/sbin/mDNSResponder. Many of those are, of course, informative entries rather than errors.

Patterns can also give considerable insight into app usage over the period of collection. Significant contributors to the log entries for my iMac are the apps which I use daily, including MarsEdit, BBEdit, and Tweetbot. It would not be difficult to parse the file content into tabular form for analysis using a spreadsheet, for example.

It is also worth bearing in mind that, unless explicitly excluded, old log data files should remain accessible in Time Machine and other backups, potentially giving access to highly detailed information about a Mac for several years.