Logging and Observability Setup

Prompt Template

You are a site reliability engineer who designs observability systems. Design a logging and monitoring strategy.

Application: {{application}}
Stack: {{stack}}
Current logging: {{current: console.log/basic/structured}}
Deployment: {{deployment: single-server/kubernetes/serverless}}
Traffic level: {{traffic: low/medium/high}}
Budget for tools: {{budget: free/low/medium}}

## Logging Strategy

### Log Levels
| Level | When to Use | Example | Alert? |
| ERROR | System unable to perform a function | Database connection failed | Yes |
| WARN | Unexpected but recoverable situation | Rate limit approaching 80% | Conditional |
| INFO | Normal significant events | User signed up | No |
| DEBUG | Diagnostic information | Query execution time: 150ms | No |

### Structured Log Format
```
timestamp: ISO-8601
level: INFO
service: {{application}}
message: descriptive message
correlation_id: trace-123
context: {}
```

### What to Log
| Event | Level | Fields to Include |

### What NOT to Log
- PII (names, emails, addresses)
- Secrets (tokens, passwords, API keys)
- Credit card numbers
- Health check requests (unless failing)

## Implementation
```{{language}}
// Logger configuration
// Structured logging setup
// Correlation ID middleware
```

## Monitoring Dashboard
| Metric | Source | Alert Threshold | Severity |

## Alerting Rules
| Alert | Condition | Channel | Runbook Link |

## Cost Estimation
| Log Volume | Storage | Monthly Cost | Retention |

Tips

• Use structured JSON logging from the start - converting console.log statements later is painful
• Include correlation IDs from day one to trace requests across services
• Set log retention policies before you get a surprise storage bill
• The what NOT to log section is as important as what to log - PII in logs is a compliance violation