Logging levels and diagnostic detail
Logging levels select which diagnostic events are recorded, so the available evidence depends on the enabled detail and the component producing it.
A logging level classifies a diagnostic event by its purpose or severity. A configured filter determines which of those events the logging system records.
Detailed messages can help explain a particular operation, while concise operational messages make longer periods easier to inspect. These are different views of the same workload rather than different proof standards.
A level selects evidence
The common .NET level names illustrate the roles:
| Level | Typical purpose |
|---|---|
| Trace | Very fine-grained activity |
| Debug | Details useful for diagnosing behavior |
| Information | Ordinary operational events |
| Warning | An unexpected condition that may still permit progress |
| Error | Failure of an operation or component |
| Critical | Severe failure affecting continued operation |
The application decides which events belong at each level. A warning in one component is not automatically equivalent to a warning in another.
An original filter model accepts Information and more severe messages. Debug and Trace events are omitted from that model's output. Their absence says nothing about whether the corresponding activity occurred.
An error line needs operation context
A background lookup can fail while playback succeeds. A failed playback attempt can be followed by a successful retry. Reading only the word “error” loses the operation and time relationship.
Useful context includes the request or task, timestamp, component, input being processed and subsequent result. A transcode log describes another layer from a general server log; it can explain command and media-processing details that the general log does not contain.
Emby's log-file documentation identifies the supported way to locate its logs. Its current controls and component behavior determine the recorded detail.
More detail also creates more volume
Verbose activity can increase write work and make relevant events harder to find among repeated messages. Record the interval and enabled detail when interpreting a diagnostic capture.
Logs may include sensitive request context, paths or identifiers. The useful evidence is the relevant operation with secret values handled appropriately; a credential is not made safe to distribute because it appeared in a diagnostic line.
Rotation and retention determine how long those events remain available. A missing historical event can reflect filtering or retention rather than proof that the server never performed the operation.