来自社区的可观测性最佳实践指南，涵盖结构化日志、分布式追踪与指标采集三大支柱，帮助团队构建高可观测性的生产系统。
说明：
## 核心用法
本 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 生态迭代较快，部分配置可能随版本更新失效
会员专属
