logging-best-practices

作者: neondatabase

专注于宽事件(规范日志行)的日志记录最佳实践,用于强大的调试和分析

npx skills add https://github.com/neondatabase/mcp-server-neon --skill logging-best-practices

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:

来自 neondatabase 的更多技能

claimable-postgres
neondatabase
为本地开发、演示、原型设计和测试环境提供即时Postgres数据库。无需账户。除非认领到Neon账户,否则数据库将在72小时后过期。
neon
neondatabase
Neon平台概述,涵盖Postgres、Auth、Data API以及新服务:对象存储、计算函数和AI网关。当提到“Neon”时,用于概述如何与Neon协作及如何入门。否则,各项独立功能为触发点:“对象存储”或“S3兼容存储”、“无服务器函数”、“后台任务”或“在数据库附近运行代码”、“AI网关”、“LLM代理”、“模型路由”或“调用LLM”→...
apidatabasedevelopment
plugin-manager
neondatabase
管理此仓库在Cursor和Claude Code中的插件结构与配置。在创建、更新或审查插件文件夹时使用…
skill-creator
neondatabase
创建有效技能的指南。当用户想要创建新技能(或更新现有技能)以扩展Claude的功能时,应使用此技能。
using-neon
neondatabase
使用Neon Serverless Postgres的指南和最佳实践。涵盖入门、使用Neon进行本地开发、选择连接方法、Neon…
neon-js-react
neondatabase
在 React 应用(Vite、CRA)中设置完整的 Neon SDK,包含身份验证和数据库查询。创建类型化客户端、生成数据库类型并配置…
postgres-best-practices
neondatabase
使用Postgres的最佳实践和指南。涵盖模式设计、索引策略、查询优化、迁移以及常见陷阱。使用…
neon-postgres-egress-optimizer
neondatabase
指导用户诊断并修复导致其Postgres数据库产生过多数据传输(出站流量)的应用端查询模式。大多数高额出站流量账单源于应用程序获取的数据量超出实际使用量。