Set up monitoring and observability: $ARGUMENTS
1. Structured Logging Audit
Verify the current logging setup:
- • Consistent log format across all modules
- • Level:
INFOby default,DEBUGwhen debug mode enabled - • No
print()statements in source root - • All loggers use
logging.getLogger(__name__) - • Project's audit logger used for state changes
Log levels used correctly:
| Level | Used For |
|---|---|
| DEBUG | Verbose troubleshooting (protocol commands, request details) |
| INFO | Normal operations (startup, shutdown, state changes) |
| WARNING | Recoverable issues (resource not found, degraded mode) |
| ERROR | Failures that need attention (communication errors) |
2. Health Endpoint Verification
Verify the health endpoint returns appropriate status information:
- • Responds within 200ms (load balancer requirement)
- • Bypasses authentication
- • Returns degraded status when external resource is disconnected
- • Returns correct version from config
3. Readiness Probe
Consider adding a readiness endpoint that checks:
- •Service is initialized
- •External resource is connected and responsive
- •Rate limiter is functional
4. Request Logging Middleware
Consider adding request/response logging for production debugging:
- •Log method, path, status code, and response time for every request
- •Don't log request/response bodies (may contain sensitive data)
- •Use a dedicated access logger
5. Metrics Endpoint (optional)
If Prometheus/metrics are needed:
- •Request count by endpoint and status code
- •Request latency histogram
- •External resource connection state gauge
- •Active entity states gauge
6. Docker Health Integration
Verify Dockerfile HEALTHCHECK matches the health endpoint URL (see project config).
Output
For each section, report:
- •CONFIGURED: Already in place and working
- •ADDED: New monitoring capability implemented
- •RECOMMENDED: Optional improvement (describe what and why)