class documentation

class LogLevel(Names): (source)

View In Hierarchy

Constants describing log levels.

Class Method levelWithName Get the log level with the given name.
Class Variable critical Critical failures: Errors indicating systemic failure (ie. service outage), data corruption, imminent data loss, etc. which must be handled immediately. This includes errors unanticipated by the software, such as unhandled exceptions, wherein the cause and consequences are unknown.
Class Variable debug Debugging events: Information of use to a developer of the software, not generally of interest to someone running the software unless they are attempting to diagnose a software issue.
Class Variable error Error conditions: Events indicating a systemic failure, such as programming errors in the form of unhandled exceptions, loss of connectivity to an external system without which no useful work can proceed, such as a database or API endpoint, or resource exhaustion...
Class Variable info Informational events: Routine information about the status of an application, such as incoming connections, startup of a subsystem, etc.
Class Variable warn Warning events: Events that may require greater attention than informational events but are not a systemic failure condition, such as authorization failures, bad data from a network client, etc. Such events are of potential interest to system administrators, and should ideally be phrased in such a way, or documented, so as to indicate an action that an administrator might take to mitigate the warning.
@classmethod
def levelWithName(cls, name: str) -> NamedConstant: (source)

Get the log level with the given name.

Parameters
name:strThe name of a log level.
Returns
NamedConstantThe LogLevel with the specified name.
Raises
InvalidLogLevelErrorif the name does not name a valid log level.
critical = (source)

Critical failures: Errors indicating systemic failure (ie. service outage), data corruption, imminent data loss, etc. which must be handled immediately. This includes errors unanticipated by the software, such as unhandled exceptions, wherein the cause and consequences are unknown.

Debugging events: Information of use to a developer of the software, not generally of interest to someone running the software unless they are attempting to diagnose a software issue.

Error conditions: Events indicating a systemic failure, such as programming errors in the form of unhandled exceptions, loss of connectivity to an external system without which no useful work can proceed, such as a database or API endpoint, or resource exhaustion. Similarly to warnings, errors that are related to operational parameters may be actionable to system administrators and should provide references to resources which an administrator might use to resolve them.

Informational events: Routine information about the status of an application, such as incoming connections, startup of a subsystem, etc.

Warning events: Events that may require greater attention than informational events but are not a systemic failure condition, such as authorization failures, bad data from a network client, etc. Such events are of potential interest to system administrators, and should ideally be phrased in such a way, or documented, so as to indicate an action that an administrator might take to mitigate the warning.