构建可观测的监控系统是保障线上服务可用性和性能的基础。本文从指标选取、数据采集、告警与追踪四个方面说明如何从零构建或改进监控体系。
核心指标（What to measure）
- 可用性：服务可达性、错误率（4xx/5xx）。
- 性能：请求延迟（p50/p95/p99）、页面关键性能指标（FCP、LCP、TTI）。
- 资源：CPU、内存、连接数与队列深度。
数据采集（How to collect）
- 后端：结构化日志、指标库（Prometheus）与分布式追踪（OpenTelemetry）。
- 前端：RUM（Real User Monitoring）收集真实用户的关键体验指标，并将其与后端 trace 关联。
告警与响应（Alerting）
- 基于业务影响设计告警阈值（错误率、延迟、用户受影响数），避免告警泛滥。
- 告警响应流程需集成 Runbook，指明排查路径与临时缓解措施。
Trace 与根因分析
- 集成分布式追踪，能在跨服务调用中快速定位瓶颈与错误源。将 trace id 贯穿到日志与请求上下文中，缩短定位时间。
实践建议
监控系统用于实时观察生成平台的运行状况与性能趋势，是发现性能回归与定位问题的首要工具。本文概述指标、日志与追踪（三位一体）的设计与实践。
核心观测面
- 指标（Metrics）：CPU/内存、请求延迟分位（P50/P95/P99）、队列深度与任务吞吐。
- 日志（Logs）：按照结构化 JSON 打点业务事件与错误上下文，便于聚合与搜索。
- 分布式追踪（Tracing）：跟踪跨服务请求链路（trace id），定位延迟来源与依赖耗时。
指标聚合与告警
- 为关键 SLA 指标设定阈值并在 CI 中记录基线；使用 Prometheus/Grafana 做可视化与长期趋势分析。
- 告警策略应结合抑制与分级，避免告警风暴并确保重要问题及时上报。
可观测性实践
- 在生成管线中打点关键阶段（入队、开始处理、外部调用、完成），并记录上下文（模板 id、用户 id、task id）。
- 对慢请求采样完整追踪日志以节省存储并提高诊断效率。
运行时诊断工具
- 提供快速的回放/回溯工具（replay）以在本地或预生产复现问题场景。
相关链接：