从“监控”到“可观测性”，从开源方案到大厂实践

写在前面

如果你刚开始接触Web监控，面对Prometheus、Grafana、Sentry、ELK、Jaeger、OpenTelemetry……这一大堆名字，大概只有一个感觉：好乱啊。

这不怪你。Web监控本身就是一个多维度、分层级的体系。不同的人（前端、后端、运维、SRE）和不同的目的（看可用性、追性能、查Bug）会看到完全不同的“监控”。本文试图帮你把这张地图画清楚——从概念到工具，从通用方案到大厂实践，一篇就够了。

一、先搞清楚：你在监控什么？

1.1 按监控对象分

这是最直观的分类方式：

  • 可用性监控：网站能不能打开？服务端口通不通？HTTP状态码正常吗？
  • 性能监控：页面加载有多快？接口响应要多久？系统吞吐量（QPS）是多少？
  • 错误监控：JavaScript有没有报错？接口请求有没有失败？资源加载有没有404？
  • 基础设施监控：CPU、内存、磁盘、网络——服务器扛不扛得住？
  • 业务监控：支付成功率、订单量、用户转化率——生意好不好？
  • 安全监控：有没有被攻击？有没有漏洞？

1.2 按数据获取方式分

  • 被动式监控（RUM - 真实用户监控） ：在用户真实访问时收集数据，反映真实体验，但数据量大、难以复现问题。
  • 主动式监控（Synthetic - 合成监控） ：用脚本模拟用户操作（如登录、下单），在真实用户受影响前主动发现问题。

二、可观测性的三大支柱：这是你理解监控体系的钥匙

如果你只记住一件事，那就记住这个：现代监控体系的核心是“可观测性（Observability）” ，而可观测性由三大支柱构成——Metrics（指标）、Logs（日志）、Traces（链路追踪） 。

Metrics：系统的体温计

告诉你CPU高不高、QPS多不多、错误率有没有爆。指标的特点是轻量、可聚合、能画趋势图。它回答的是“怎么样”的问题。

代表工具：Prometheus

Logs：系统的黑匣子

告诉你代码执行到了哪、错误是啥、参数长啥样、用户是谁。日志的特点是全面、细节丰富，但太多了会淹死人。它回答的是“发生了什么”的问题。

代表工具：ELK Stack、Loki

Traces：系统的链路地图

告诉你一次请求经历了哪些服务、哪一步慢、哪一步炸。链路追踪的可视化最强，但成本也较高。它回答的是“为什么慢/为什么错”的问题。

代表工具：Jaeger、SkyWalking

关键认知：可观测性不是把这三件套堆在一起，而是让它们“互相说话”。孤立使用就像看三个故事片段，关联起来才是完整电影。

三、主流开源方案：各司其职，统一展示

3.1 黄金组合：Prometheus + Grafana

Prometheus作为CNCF毕业项目，凭借多维度数据模型、拉取式监控和强大的PromQL查询语言，已成为云原生时代监控的事实标准。Grafana则是开源可视化平台的标杆，支持15+种数据源。

这套组合的核心逻辑是：Prometheus负责采集和存储，Grafana负责展示和告警。

# prometheus.yml 基础配置
global:
  scrape_interval: 15s
scrape_configs:
  - job_name: 'node-exporter'
    static_configs:
      - targets: ['192.168.1.100:9100']

3.2 日志方案：ELK vs Loki

  • ELK Stack（Elasticsearch + Logstash + Kibana） ：功能强大，支持全文检索和复杂解析，但资源消耗较高。
  • Loki：Grafana生态的日志方案，与Prometheus共用标签体系，存储效率比ELK提升3-5倍，资源消耗可减少10倍以上。

规模不大、已在用Grafana的团队，Loki是性价比很高的选择。

3.3 链路追踪：Jaeger / SkyWalking

Jaeger是Uber开源、CNCF毕业的分布式追踪系统，与Prometheus/Grafana生态集成良好。SkyWalking则提供了更完整的APM能力，对Java生态支持尤为出色。

3.4 前端监控：Sentry

Sentry以前端错误监控为核心，同时提供性能监控（Tracing） 、会话回放（Session Replay） 和日志关联能力。对于Next.js等现代框架，官方SDK支持从客户端到服务端的全链路错误捕获。

3.5 如何选型？一张表看懂

监控类型推荐工具适用场景
指标监控Prometheus + Grafana几乎所有场景，必选
日志监控Loki（轻量）/ ELK（重型）排错、审计
链路追踪Jaeger / SkyWalking微服务架构
前端错误SentryWeb应用，必选
全栈统一Datadog / 观测云预算充足，不想折腾

四、大厂怎么做？从“集成”到“统一”

常规开源方案已经能解决大部分问题，但到了字节跳动、腾讯、滴滴这种规模——几万甚至几十万台机器、日PB级数据——通用方案就“扛不住”了。

大厂的思路是从“集成”走向“统一” ：

4.1 采集层统一：OneAgent

多套采集Agent共存，资源浪费且管理困难。大厂的做法是打造统一的OneAgent，一个Agent采集Metrics、Traces、Logs、Events所有类型的数据。

4.2 标准统一：拥抱OpenTelemetry

OpenTelemetry提供了一套统一的API、SDK和工具，用于生成和采集遥测数据。它定义了900+属性的语义约定，覆盖70多个领域。大厂正在将内部系统向此标准靠拢，让不同语言、不同框架的服务“讲同一种话”。

4.3 存储与计算自研

开源方案在超大规模下会遇到瓶颈。特斯拉基于ClickHouse构建了千万亿级别的可观测性平台；字节跳动融合OpenTelemetry、Prometheus等开源组件，构建了覆盖全生命周期的全栈可观测体系。

4.4 平台化：一站式可观测平台

最终所有能力整合成一个对内部开发者友好的一站式平台，提供从SDK接入、数据采集、存储计算到产品化交互的完整解决方案。

给普通团队的建议：千万别盲目模仿大厂。如果你的业务只有几百台机器，官方裸装的Prometheus + Grafana + Jaeger已经非常完美，稳定性甚至比大厂自己改出来的还高。先通用，后定制——没有遇到“十万级节点”的痛，就不要动“定制化”的念头。

五、未来趋势

5.1 OpenTelemetry成为事实标准

OpenTelemetry在2025年达到了一个临界点，逐渐成为可观测性数据的统一标准。未来，不同工具之间的数据交换将越来越顺畅。

5.2 eBPF带来无侵入可观测

eBPF技术可以不修改代码、不重启服务，直接在内核层面采集监控数据。华为云、腾讯游戏等已经在基于eBPF构建无侵入的可观测能力。这意味着未来的监控可能不再需要你改一行代码。

5.3 AI驱动的智能可观测

可观测平台正在从“支撑系统”转向“智能助手”。智能告警分析、根因定位、异常检测——AI正在让监控从“被动响应”走向“主动预防”。

写在最后

Web监控之所以让人觉得乱，是因为它本身就是一个多层次的体系。但只要掌握了三大支柱（Metrics + Logs + Traces） 这个核心框架，再根据自身规模选择合适的工具组合，你就能搭建出一套清晰的监控体系。

对于大多数团队：Prometheus + Grafana + Sentry +（按需选日志和链路工具），已经足够好用。

对于大厂：在上述基础上做深度定制，解决规模带来的性能和管理问题。

对于未来：OpenTelemetry统一标准 + eBPF无侵入采集 + AI智能分析，正在重新定义“监控”这件事。

希望这篇文章能帮你理清思路，不再感到混乱。