Co-Pilot / 辅助式
更新于 a month ago

logging-best-practices

Bboristane
0.0k
boristane/agent-skills/skills/logging-best-practices
82
Agent 评分

💡 摘要

该技能提供有效日志记录的指南,使用丰富上下文的宽事件以改善调试和分析。

🎯 适合人群

软件开发人员DevOps工程师技术项目经理质量保证工程师系统架构师

🤖 AI 吐槽:看起来很能打,但别让配置把人劝退。

安全分析低风险

风险:Low。建议检查:是否发起外网请求(SSRF/数据外发);文件读写范围与路径穿越风险。以最小权限运行,并在生产环境启用前审计代码与依赖。


name: logging-best-practices description: Logging best practices focused on wide events (canonical log lines) for powerful debugging and analytics license: MIT metadata: author: boristane version: "1.0.0"

Logging Best Practices Skill

Version: 1.0.0

Purpose

This skill provides guidelines for implementing effective logging in applications. It focuses on wide events (also called canonical log lines) - a pattern where you emit a single, context-rich event per request per service, enabling powerful debugging and analytics.

When to Apply

Apply these guidelines when:

  • Writing or reviewing logging code
  • Adding console.log, logger.info, or similar
  • Designing logging strategy for new services
  • Setting up logging infrastructure

Core Principles

1. Wide Events (CRITICAL)

Emit one context-rich event per request per service. Instead of scattering log lines throughout your handler, consolidate everything into a single structured event emitted at request completion.

const wideEvent: Record<string, unknown> = { method: 'POST', path: '/checkout', requestId: c.get('requestId'), timestamp: new Date().toISOString(), }; try { const user = await getUser(c.get('userId')); wideEvent.user = { id: user.id, subscription: user.subscription }; const cart = await getCart(user.id); wideEvent.cart = { total_cents: cart.total, item_count: cart.items.length }; wideEvent.status_code = 200; wideEvent.outcome = 'success'; return c.json({ success: true }); } catch (error) { wideEvent.status_code = 500; wideEvent.outcome = 'error'; wideEvent.error = { message: error.message, type: error.name }; throw error; } finally { wideEvent.duration_ms = Date.now() - startTime; logger.info(wideEvent); }

2. High Cardinality & Dimensionality (CRITICAL)

Include fields with high cardinality (user IDs, request IDs - millions of unique values) and high dimensionality (many fields per event). This enables querying by specific users and answering questions you haven't anticipated yet.

3. Business Context (CRITICAL)

Always include business context: user subscription tier, cart value, feature flags, account age. The goal is to know "a premium customer couldn't complete a $2,499 purchase" not just "checkout failed."

4. Environment Characteristics (CRITICAL)

Include environment and deployment info in every event: commit hash, service version, region, instance ID. This enables correlating issues with deployments and identifying region-specific problems.

5. Single Logger (HIGH)

Use one logger instance configured at startup and import it everywhere. This ensures consistent formatting and automatic environment context.

6. Middleware Pattern (HIGH)

Use middleware to handle wide event infrastructure (timing, status, environment, emission). Handlers should only add business context.

7. Structure & Consistency (HIGH)

  • Use JSON format consistently
  • Maintain consistent field names across services
  • Simplify to two log levels: info and error
  • Never log unstructured strings

Anti-Patterns to Avoid

  1. Scattered logs: Multiple console.log() calls per request
  2. Multiple loggers: Different logger instances in different files
  3. Missing environment context: No commit hash or deployment info
  4. Missing business context: Logging technical details without user/business data
  5. Unstructured strings: console.log('something happened') instead of structured data
  6. Inconsistent schemas: Different field names across services

Guidelines

Wide Events (rules/wide-events.md)

  • Emit one wide event per service hop
  • Include all relevant context
  • Connect events with request ID
  • Emit at request completion in finally block

Context (rules/context.md)

  • Support high cardinality fields (user_id, request_id)
  • Include high dimensionality (many fields)
  • Always include business context
  • Always include environment characteristics (commit_hash, version, region)

Structure (rules/structure.md)

  • Use a single logger throughout the codebase
  • Use middleware for consistent wide events
  • Use JSON format
  • Maintain consistent schema
  • Simplify to info and error levels
  • Never log unstructured strings

Common Pitfalls (rules/pitfalls.md)

  • Avoid multiple log lines per request
  • Design for unknown unknowns
  • Always propagate request IDs across services

References:

五维分析
清晰度9/10
创新性7/10
实用性8/10
完整性9/10
可维护性8/10
优缺点分析

优点

  • 促进结构化日志记录实践。
  • 增强调试能力。
  • 鼓励服务之间的一致性。

缺点

  • 可能需要对现有代码进行重大重构。
  • 对不熟悉结构化日志记录的团队有学习曲线。
  • 如果实施不当,可能会导致性能开销。

相关技能

ccmp

A
toolCo-Pilot / 辅助式
86/ 100

“看起来很能打,但别让配置把人劝退。”

claude-mods

A
toolCo-Pilot / 辅助式
86/ 100

“看起来很能打,但别让配置把人劝退。”

agentic-qe

A
toolCo-Pilot / 辅助式
86/ 100

“看起来很能打,但别让配置把人劝退。”

免责声明:本内容来源于 GitHub 开源项目,仅供展示和评分分析使用。

版权归原作者所有 boristane.