Jump to page content

Logging

Caveats

Most if not all pages are just rough notes, and these pages as a whole are far from complete. More notes will be added in time, eventually, maybe.

If, from reading these notes, you conclude that I am off my rocker, you won’t be the first, and you may even be right. These pages may simply position me as an acolyte to the late Gene Ray.

No doubt there are a dozen and one reasons why none of this would ever work, but perhaps somewhere deep down there is a tiny fragment that could be used for something.

Contents

Overview

As with every other facility, logging is centralised and handled by the Log Manager. The application can issue log entries directly by sending messages to the Log Manager. Applications using the legacy event model (see at events) that are run non-interactively will also have all STDERR and STDOUT entries written to the application’s log. Log entry formatting is handled automatically. Each application has its own log file, similar to the macOS approach.

The intention was that, unlike the Windows event log, there would be no general-purpose logs such as “Application” and “System”, as these classifications have proved meaningless. Each system component and application will have its own log, much more like Linux. Combinations of logs, such as viewing the logs for all system components, are simply a matter of specifying the appropriate query. With that said, there is likely to be a (hotly debated) subset of entries that are sufficiently common and useful as to be placed into the “Event Log Lite”™, as noted below. Practical structuring of logging is a very elusive goal. Having too many activities in a single log creates clutter, while having too many separate logs reduces oversight effectiveness.

Each log entry contains the time, date, user ID, user session, process ID and log details. Users may retrieve all log entries for their own sessions and for all unprivileged system activity. With administrative privileges, users may also query the log entries for other users and all privileged system logs. The log levels (e.g. information, warning, error, debug) are system-defined. The maximum log level is set within the Log Manager itself; language runtime may choose to not send log levels below that specified for the application, but the Log Manager will discard any entries at too high a level. The log level can be changed with a request to the Log Manager, made either by the application itself or by the user, e.g. from within the Log Viewer application.

The log database is maintained by the Log Manager and can be queried using standard message passing. Comprehensive search and filtering is to be available.

Entry format

Log entries in plain text are supported, if only for the legacy event model and programs that only write to STDERR and STDOUT (utilities ported from Linux and UNIX).

The difficulty with plain-text log entries is the limited ability to search and filter them. The event ID system in Windows is invaluable in being able to trivially isolate specific events. Plain text logging is able to achieve the same basic objective so long as the log format is formalised and consistent across all applications, and this will require intervention on the part of the operating system to funnel all logging through an API call that collects the necessary details.

There is potential merit in the idea of named placeholders, e.g.

{ message: "User $username successfully logged on from computer $computer.", username: "Trogdor", computer: "COMPY386" }

This arrangement allows users to more accurately query for log entries by specifying parameters by name. However, the log storage arrangement is not specifically determined. Some means will be necessary to identify which placeholders exist and are searchable, and whether placeholders these are defined formally or simply extracted from the first log entry of the type desired. Having a standard format with fixed columns that can be directly queried is, however, of more importance.

Log entries could also save the messages in string tables just like in Windows, to save on log storage: detailed logging is space-hungry even with the string table method. The log message definitions would likely have their own MDFS dimension for ready access.

Messages

The Log Manager supports the following events and messages:

“Event Log Lite”™

After Microsoft Windows “starts up” (that is, booted sufficiently as to allow a user to sign in), lots of services continue to start in the background and there is no way to for the user to readily see what is happening. Although the boot UI is meant to show each step of the start-up process, there is no proposed UI for watching system activity after logging in (you could arguably show details at the logon desktop, but not after that).

There are other things that one should be able to review, such as DHCP allocation, Wi-Fi connections etc.

Something like an “Event Log Lite”™ that shows just a summary of the basics of system operation may be useful, amended to cover anything else that is later decided ought to be included. Candidates for this special log include:

Event IDs

The Windows event log has “semi-unique” event IDs. There is however no convenient way to filter (inclusive or exclusive) events by both source and ID, and IDs are not guaranteed to be unique to their source. Some kind of autocomplete for this would help. Prefixes on events, e.g. "WL-1000" would be nice but it would be too hard to ensure that every event source has a unique prefix. Not unless the prefixes were dynamic, and that would be too confusing.

The Windows Event Viewer is a good starting point but it has many flaws that need to be ironed out. It has too many logs that are never used and just waste space, such as the MSPaint Admin log. The source list when filtering is not specific to the log in question, making it unduly tedious. There is no way to point at an event and add it to a filter. It should be possible to point to an event and add it to the filter without enabling the filter, to allow the user to choose multiple event types to be filtered before the rest of the events are hidden.