SkillRouter

## 核心用法 本 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 生态迭代较快，部分配置可能随版本更新失效