As some of you may know, two new logging APIs are currently under development/evolution: a general-purpose logging API for Swift discussed here aimed at server-side programming, and a new Swift API for Apple's os logging system which is discussed here. The former is aimed at server-side development and needs to accommodate different logging backends and platforms, whereas the latter is meant for Apple's systems/devices and is meant to interface with Apple's native os-logging system. While there are differences between server and device-side logging, it would be desirable to provide a common interface and a consistent user model for functionality that is common across server and devices. A step towards this is to standardize the log levels, such as
error, that would be supported on both server and devices.
The aim of this post is to converge on this common set of log levels along with their recommended semantics. We propose to adopt the log levels defined by syslog (standardized by RFC 5424), which are listed below. They mostly only add to those available in os_log and the current server-side logging proposal. The levels also have a numerical code which is standardized by syslog and is listed below.
|Level||Numerical code||Recommended semantics|
|Debug||7||Messages meant to be useful only during development. This is meant to be disabled in shipping code.|
|Info||6||Informational messages that are not essential for troubleshooting errors. These can be discarded by the logging system, especially if there are resource constraints.|
|Notice||5||Conditions that are not error conditions, but that may require special handling or that are likely to lead to an error. These messages will be stored by the logging system unless it runs out of the storage quota.|
|Warning||4||Abnormal conditions that do not prevent the program from completing a specific task. These are meant to be persisted (unless the system runs out of storage quota).|
|Critical||2||Logging at this level or higher could have a significant performance cost. The logging system may collect and store enough information such as stack shot etc. that may help in debugging these critical errors.|
|Alert||1||Action must be taken immediately|
|Emergency||0||System is unusable|
The semantics description proposed above is only meant to be a guideline and is borrowed from the syslog standard and os_log documentation. Each logging backend may more accurately define the levels in accordance with this recommendation. In the case of Apple's os logging system, the levels such as notice, warning, critical and above do not have a namesake in the system. They will be mapped on to levels that closely matches their recommendation. In this case, those are probably default, error and fault.
We welcome feedback on this.