Choose useful INFO and DEBUG log messages
Set logging levels around operational meaning, keep diagnostic context without exposing secrets, and avoid alerting on every error indiscriminately.
Use INFO for events that help explain normal operation and DEBUG for finer detail needed to investigate how the program reached an outcome. The distinction is about the message's purpose, not whether a developer or an operator happens to read it.
An INFO production threshold is a common starting point. It is not a universal rule: volume, privacy, incident needs, and the application's logging design should determine the policy.
Give each level a clear meaning
| Level | Intended use | Example |
|---|---|---|
| DEBUG | Detailed diagnostic context | A chosen branch, bounded parameter summary, or timing detail |
| INFO | Useful normal-operation events | Service started, scheduled job completed, or an important state transition |
| WARNING | An unexpected or concerning condition the system can still handle | Repeated retries or a fallback caused by invalid configuration |
| ERROR | An operation failed | A request or background task could not complete |
| CRITICAL / FATAL | A severe condition requiring urgent attention | A service cannot initialize an essential dependency |
The names and exact semantics vary across frameworks. Logging at CRITICAL does not itself terminate a Python process; it records a severity. Likewise, an ordinary cache miss is usually expected behavior, not automatically a warning.
Keep examples deliberate
logger.debug("Lookup completed in %.1f ms", elapsed_ms)
logger.info("Order created: order_id=%s", order_id)
logger.warning("Cache unavailable; using the database fallback")
logger.error("Payment request failed: request_id=%s", request_id)
Python's parameterized formatting avoids eagerly constructing the final message when it is filtered out, although evaluating arguments still has a cost. Do not log raw passwords, tokens, payment data, or unrestricted request parameters at any level. Include safe correlation identifiers where they help connect related events.
Set a threshold and an investigation path
At an effective INFO logger threshold, Python's DEBUG calls are normally filtered out. Handlers and filters can impose additional restrictions, so changing one logger does not guarantee a message reaches every destination. The Python logging reference explains these stages.
When deeper evidence is needed, enable debug output for a specific component and a bounded time window if the application supports runtime changes. Check the added volume, sensitive fields, and rollback procedure. INFO and ERROR context, metrics, and distributed traces should still support investigation when debug output is off.
Some frameworks provide TRACE below DEBUG. Python's standard logging module does not define TRACE by default; it requires a custom level or another library.
Keep collection and alert semantics aligned
After ingestion, verify that the application's levels map correctly to collected fields. In Guance, inspect DataKit's parsed logs and use the log explorer to compare events by service.
An ERROR record is a useful alert input, but paging on every individual error can create noise. Define actionable conditions such as sustained error rates, failed critical operations, or customer impact. Misclassifying DEBUG as error corrupts those signals before any alert rule runs.
Contact us
Join the community
to join the community
Try Guance
Start online and pay only for what you use.
Get startedChoose a Guance plan