logging-observability

核心用法

本 Skill 是一套完整的可观测性工程实践指南，围绕日志（Logs）、指标（Metrics）、追踪（Traces）三大支柱展开。核心用法包括：

1. 结构化日志实施：强制使用 JSON 格式输出，包含 timestamp、level、service、trace_id、span_id 等必需字段，通过异步上下文存储实现自动上下文传递
2. 分布式追踪配置：基于 OpenTelemetry 标准，使用 NodeSDK 初始化追踪器，通过 W3C Trace Context 协议在 HTTP/gRPC/消息队列间传播上下文，支持多种采样策略（概率采样、速率限制、尾部采样）
3. 指标体系建设：采用 RED 方法（Rate/Errors/Duration）监控服务端点，USE 方法（Utilization/Saturation/Errors）监控基础设施资源
4. 监控栈搭建：推荐 OTel Collector → Prometheus + Grafana + Loki + Jaeger 的开源组合，提供从采集到可视化的完整链路
5. 告警与仪表盘设计：定义 P1-P4 严重级别，遵循"告警症状而非原因"原则，配套 Overview Dashboard（全局战情室）和 Service Dashboard（单服务视图）两种模板

显著优点

• 标准先行：全面拥抱 OpenTelemetry 开放标准，避免厂商锁定，支持多云/混合云环境
• 生产就绪：提供可直接落地的代码示例（Pino/zerolog/zap 等高性能日志库选型）、配置模板和检查清单
• 安全内建：专设 PII/Secret 脱敏章节，明确"NEVER log passwords/tokens/API keys"等红线，包含 8 条反模式警示
• 成本意识：强调采样策略、日志级别动态调整、高基数标签规避等成本控制手段
• 全链路覆盖：从开发规范（结构化日志）到运维实践（告警疲劳预防）形成闭环

潜在缺点与局限性

• 无自动化能力：纯文档型 Skill，不提供代码生成或自动配置功能，需人工逐条实施
• 技术栈偏向：示例以 Node.js/TypeScript 为主，Python/Go/Rust 覆盖相对简略
• 云原生假设：默认假设 Kubernetes/Prometheus 环境，传统虚拟机或 Serverless 场景需额外适配
• 缺乏量化基准：未提供"多少 QPS 该选什么采样率"等具体数值建议
• T3 来源风险：来自个人开发者账号，无组织背书，长期维护承诺不明确

适合的目标群体

• SRE/平台工程师：搭建或重构可观测性基础设施
• 后端开发团队：制定团队日志规范、接入分布式追踪
• 技术负责人：审查现有系统的可观测性成熟度
• DevOps 转型企业：从传统监控向云原生可观测性迁移

使用风险

• 实施落差风险：文档建议与团队现有技术债可能存在冲突，需评估迁移成本
• 性能误配风险：不当的采样策略或日志级别可能导致数据丢失或存储成本激增
• 安全合规风险：尽管文档强调 PII 脱敏，实际实施时仍需结合企业合规要求定制
• 依赖项风险：OpenTelemetry 生态迭代较快，部分配置可能随版本更新失效