logging-observability-standards
Skill6 starsChanged 6 months agoMITView on GitHub
When setting up telemetry, debugging distributed systems, or standardizing application output.
- Reads credentials
In this repository13 other files it gives its agents.
- caching-strategiesSkill
- event-driven-designSkill
- api-design-restSkill
- database-query-optimizationSkill
- error-handling-architectureSkill
- code-review-guidelinesSkill
- ci-cd-pipeline-architectureSkill
- debugging-strategiesSkill
- git-workflow-branchingSkill
- dom-security-hardeningSkill
- react-component-designSkill
- state-management-patternsSkill
- accessibility-ui-designSkill
The file
We split this skill into the rules it gives an agent
11 rules. About 0 are common, 11 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈11
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 58
MUST output JSON in production environments (not plain text)
- Distinctive: line 59
MUST include Request ID/Correlation ID in all HTTP requests
- Distinctive: line 60
MUST NEVER log raw passwords, session tokens, or financial data
- Distinctive: line 61
MUST log full stack traces for ERROR level (for debugging)
- Distinctive: line 62
MUST log only message and context for WARN/INFO (not verbose)
- Distinctive: line 63
MUST redact/sanitize any PII before log emission
- Distinctive: line 64
MUST include timestamps in UTC
- Distinctive: line 65
MUST standardize key names across all logs
- Distinctive: line 78
No correlation ID tracking
- Distinctive: line 81
No way to correlate logs across services
- Distinctive: line 105
All PII (names, emails, phone numbers) MUST be redacted or anonymized
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Logging & Observability Standards
Purpose
Logs are the black box recorder of your system. When failures happen at 2 AM in production, logs are your only witness. This skill ensures application state and failures are highly searchable, machine-readable, and traceable across system boundaries WITHOUT leaking sensitive user data.
When to use
- Bootstrapping a new backend microservice or monolithic API
- Refactoring code filled with disorganized
console.logorprintstatements - Designing a system that spans multiple services/functions
- Setting up monitoring, alerting, and debugging infrastructure
When NOT to use
- Application performance monitoring (APM) - related but different concern
- Security incident response (use SIEM/security tools)
- User analytics (different use case, different tool)
Inputs required
- Backend service with multiple endpoints/functions
- Logging infrastructure (ELK, DataDog, Grafana Loki, CloudWatch, etc.)
- Understanding of structured logging concepts
Workflow
- Implement Structured Logging: Configure logger to output NDJSON (Newline Delimited JSON) instead of plain text
- Inject Context: Attach a
correlation_id(ortrace_id) at HTTP entry point and pass through all downstream calls - Standardize Levels: ERROR (system broken), WARN (unexpected but recovered), INFO (lifecycle), DEBUG (verbose tracing)
- Sanitize Data: Implement redaction middleware to mask credentials, tokens, and PII before logs hit the stream
- Add Request Context: Log request duration, status code, user context (anonymized), and performance metrics
- Trace Async Flows: Pass correlation ID through event handlers, message queues, and inter-service calls
- Monitor Log Health: Alert on high ERROR rates, unexpected patterns, or missing correlation IDs
Rules
- MUST output JSON in production environments (not plain text)
- MUST include Request ID/Correlation ID in all HTTP requests
- MUST NEVER log raw passwords, session tokens, or financial data
- MUST log full stack traces for ERROR level (for debugging)
- MUST log only message and context for WARN/INFO (not verbose)
- MUST redact/sanitize any PII before log emission
- MUST include timestamps in UTC
- MUST standardize key names across all logs
Anti-patterns
- String Concatenation:
logger.info("User " + userId + " failed to login")(unqueryable) - Logging Expected Errors as ERROR: Logging validation failure as ERROR (use INFO/WARN)
- Silent Catching: Catching exception without logging the stack trace
- No Context: Logs with no request/correlation ID (impossible to trace)
- Unstructured Logs: Plain text logs without JSON structure
- Missing Timestamps: Logs without UTC timestamps (ordering problems)
- Over-Logging: Logging every line of execution (noise, storage cost)
Failure conditions
- Logs are plain text (not JSON)
- No correlation ID tracking
- PII or credentials in logs
- Missing stack traces on ERROR logs
- No way to correlate logs across services
Validation checklist
- Logger outputs NDJSON (each line is valid JSON)
- Correlation ID/Trace ID included in all requests
- ERROR logs include full stack traces
- INFO/WARN logs are concise (no excessive detail)
- All timestamps in UTC
- No passwords, tokens, or PII in logs
- Request duration/latency logged
- Correlation ID passed through async/inter-service calls
- Redaction middleware configured and working
- Log levels used correctly (ERROR for failures, INFO for lifecycle)
- Searchable by correlation ID (verified in log aggregator)
- Sampling/retention policy defined (cost management)
Output format
- Log structure: JSON with consistent keys: timestamp, level, message, correlationId, userId (anonymized), duration, error, stack
- Log format: NDJSON (one valid JSON object per line)
- Timestamps: UTC ISO 8601 format
- Levels: ERROR, WARN, INFO, DEBUG
- Middleware: Automatic request ID generation, redaction on output
Security considerations
- All PII (names, emails, phone numbers) MUST be redacted or anonymized
- Tokens, API keys, passwords MUST NEVER appear in logs
- Credit card data MUST NEVER appear in logs
- Database connection strings MUST be redacted
- User IDs may appear but real names MUST NOT
- Logs MUST be encrypted in transit and at rest
Agent execution notes
- Agent MAY: Add structured logging, implement correlation IDs, add redaction middleware, configure log rotation
- Agent MUST NEVER: Log passwords/tokens, use plain text logs, leave PII unredacted, omit stack traces
- Agent MUST ASK: Before adding new log messages that might contain PII, before changing log levels
- Agent MUST VALIDATE: Logs are JSON, correlation IDs flow through system, no PII present
Example
❌ Anti-pattern (String concatenation, no context, no redaction):
// BAD: Unstructured, concatenated
console.log('User ' + req.user.id + ' logged in at ' + new Date());
// BAD: No correlation ID
logger.info('Processing order');
logger.info('Order processed');
// BAD: Leaking PII and secrets
logger.error('Failed to connect: ' + process.env.DB_PASSWORD);
logger.info('User email: ' + user.email + ' password hash: ' + user.passwordHash);
// BAD: Expected error logged as ERROR
try {
const user = await User.findById(userId);
} catch (e) {
logger.error('User not found'); // WRONG level
}✅ Correct pattern (Structured JSON, correlation IDs, redacted):
// CORRECT: Structured JSON with context
logger.info('User login successful', {
userId: 'user_123', // Anonymized or hashed
correlationId: req.id,
duration: Date.now() - req.startTime,
timestamp: new Date().toISOString()
});
// CORRECT: Correlation ID flows through system
const requestId = req.headers['x-request-id'] || uuid();
req.correlationId = requestId;
// Pass to downstream calls
await orderService.process(order, { correlationId: requestId });
// CORRECT: Redaction middleware
logger.addRedaction([
process.env.DB_PASSWORD,
/\d{4}-\d{4}-\d{4}-\d{4}/, // Credit card pattern
/@\w+\.\w+/, // Email pattern
]);
// CORRECT: Proper error logging with stack trace
try {
const user = await User.findById(userId);
} catch (error) {
logger.warn('User not found', {
userId,
correlationId: req.correlationId,
message: error.message
// Stack trace logged by error handler, not here
});
}
// CORRECT: Full context on errors
logger.error('Database connection failed', {
error: error.message, // Not the password!
code: error.code,
stack: error.stack,
correlationId: req.correlationId,
timestamp: new Date().toISOString(),
severity: 'critical'
});Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

