Configure Litestar logging with `LoggingConfig`, `queue_listener`, exception logging policy, selective stack-trace suppression, standard logging, picologging, Structlog, and custom logging config subclasses. Use when establishing or refactoring application logging behavior, request-level logs, or production-safe error logging in Litestar. Do not use for metrics/tracing instrumentation or exception-response contract design.
설치
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
Configure Litestar logging with `LoggingConfig`, `queue_listener`, exception logging policy, selective stack-trace suppression, standard logging, picologging, Structlog, and custom logging config subclasses. Use when establishing or refactoring application logging behavior, request-level logs, or production-safe error logging in Litestar. Do not use for metrics/tracing instrumentation or exception-response contract design.
Logging
Execution Workflow
Choose the logging backend first: stdlib logging, picologging, Structlog, or a custom config subclass.
Configure logging once at app setup with logging_config or the Structlog plugin.
Use Litestar's non-blocking queue_listener handler unless a concrete reason requires otherwise.
Decide when exceptions should be logged and which stack traces should be suppressed.
Standardize request and app logger usage so fields, levels, and redaction rules stay consistent.
Validate that logs remain actionable without leaking sensitive data.
Core Rules
Keep logging configuration centralized at app construction.
Prefer the built-in non-blocking queue_listener handler for async applications.
Treat exception logging policy as an explicit decision; Litestar does not log exceptions by default outside debug mode.
Use disable_stack_trace for expected exception types or status codes that should not spam traces.
Keep secrets, auth material, and sensitive request data out of logs.
Avoid duplicate logging across middleware, exception handlers, and business code.
Keep logging concerns separate from metrics and tracing.
Decision Guide
Use LoggingConfig for standard logging or picologging-based setups.
Use logging_module="picologging" when picologging is the desired backend.
Use StructlogPlugin when structured logging with Structlog is the project standard.
Use log_exceptions="always" when production incidents require exception logs even outside debug mode.
Use disable_stack_trace for common expected errors such as 404 or domain-level validation problems.
Subclass BaseLoggingConfig only when the built-in configs cannot express the needed behavior.