（1344期）logging-observability – 云原生可观测性工程指南

云原生可观测性工程指南 来自社区的可观测性最佳实践指南，涵盖结构化日志、分布式追踪与指标采集三大支柱，帮助团队构建高可观测性的生产系统。 使用说明 核心用法 本 Skill 是一套完整的可观测性工程实践指南，围绕日志（Logs）、指标（Metrics）、追踪（Traces）三大支柱展开。核心用法包括： 结构化日志实施：强制使用 JSON 格式输出，包含 timestamp、level、service、traceid、spanid 等必需字段，通过异步上下文存储实现自动上下文传递 分布式追踪配置：基于 OpenTelemetry 标准，使用 NodeSDK 初始化追踪器，通过 W3C Trace Context 协议在 HTTP/gRPC/消息队列间传播上下文，支持多种采样策略（概率采样、速率限制、尾部采样） 指标体系建设：采用 RED 方法（Rate/Errors/Duration）监控服务端点，USE 方法（Utilization/Saturation/Errors）监控基础设施资源 监控栈搭建：推荐 OTel Collector → Prometheus + Grafana + Loki + Jaeger 的开源组合，提供从采集到可视化的完整链路 告警与仪表盘设计：定义 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 生态迭代较快，部分配置可能随版本更新失效 原始说明 Structured logging, distributed tracing, and metrics collection patterns for building observable systems. Use when implementing logging infrastructure, setting up distributed tracing with OpenTelemetry, designing metrics collection (RED/USE methods), configuring alerting and dashboards, or reviewing observability practices. Covers structured JSON logging, context propagation, trace sampling, Prometheus/Grafana stack, alert design, and PII/secret scrubbing.