home / skills / dicklesworthstone / meta_skill / logging-patterns

logging-patterns skill

safe

This skill teaches structured logging practices with correlation IDs and appropriate levels to improve observability and debugging visibility.

npx playbooks add skill dicklesworthstone/meta_skill --skill logging-patterns

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

1.3 KB

---
id: logging-patterns
name: Logging Patterns
description: >-
  Common logging patterns and practices. This skill is designed to be
  included in composite skills via the 'includes' feature.
tags: [logging, observability, example]
---

# Logging Patterns

Foundational logging practices for observable applications.

## Rules

- Use structured logging (key-value pairs, not interpolated strings)
- Include request/correlation IDs in all log entries
- Log at appropriate levels (DEBUG, INFO, WARN, ERROR)
- Include enough context to debug issues without the code
- Don't log sensitive information (passwords, tokens, PII)

## Pitfalls

- Logging sensitive data (passwords, API keys, PII)
- Inconsistent log levels across the codebase
- Missing correlation IDs in distributed systems
- Logging at wrong levels (DEBUG in prod, ERROR for non-errors)

## Examples

```rust
// Structured logging with tracing
use tracing::{info, error, instrument};

#[instrument(skip(password))]
fn authenticate(user_id: &str, password: &str) -> Result<Token> {
    info!(user_id, "authentication attempt");

    match verify_credentials(user_id, password) {
        Ok(token) => {
            info!(user_id, "authentication successful");
            Ok(token)
        }
        Err(e) => {
            error!(user_id, error = %e, "authentication failed");
            Err(e)
        }
    }
}
```

Overview

This skill collects proven logging patterns and practices for building observable, maintainable applications. It focuses on structured logs, correlation IDs, sensible log levels, and avoiding sensitive data so teams can diagnose issues quickly without exposing secrets.

How this skill works

The skill summarizes rules, common pitfalls, and concrete examples (including idiomatic Rust snippets) so it can be embedded in larger toolchains or documentation. It inspects logging design choices and recommends changes: use key-value structured logging, attach correlation/request IDs, pick appropriate log levels, and strip sensitive fields before writing logs.

When to use it

During new service design to define a consistent logging strategy
When onboarding developers to a codebase to teach standard logging habits
While performing incident postmortems to evaluate log usefulness and coverage
When auditing code for security and privacy risks around logs
Before deploying to production to ensure no sensitive data is logged

Best practices

Emit structured logs (key=value) instead of interpolated strings to support indexing and querying
Always include a request or correlation ID in every log entry for traceability across services
Use log levels consistently: DEBUG for dev details, INFO for normal ops, WARN for recoverable issues, ERROR for failures
Avoid logging secrets or PII; redact or omit sensitive fields before writing logs
Provide enough contextual fields to reproduce a problem without peeking at code or user data

Example use cases

Add tracing and correlation IDs to HTTP handlers so distributed traces link across services
Refactor scattered println!/format! logs into structured tracing/info macros in a Rust service
Create a log-sanitization middleware that strips tokens and passwords from request bodies
Standardize log levels across microservices to make alerting thresholds reliable
Audit logs for missing context during an incident and add the minimal fields needed for root cause analysis

FAQ

What exactly is structured logging and why prefer it?

Structured logging emits key-value pairs instead of free text, enabling efficient search, filtering, and automated analysis in log platforms.

How should I handle sensitive fields?

Never write raw secrets or PII to logs. Redact, hash, or omit sensitive fields and centralize sanitization in middleware or logging helpers.