企业官网建设流程全解析

1. 四类主流架构的总体画像与演进逻辑

先直接说结论：2026年做运维监控和可观测方案选型，已经不能靠“别人用什么我就用什么”来糊弄了。我在过去几年帮不同规模的团队做过不少监控体系搭建和迁移，最深的感受是——监控这件事没有银弹，但一定有更适合你的那条路。市面上真正经过大规模生产验证的架构，基本可以归纳为四个流派：指标驱动的直连采集型、日志为中心的集中管道型、统一Agent覆盖的多信号可观测平台型，以及eBPF内核无侵入型。

这四类架构看着都在做“采集、传输、存储、展示”这件事，但设计出发点完全不同。

指标直连型架构的代表是Prometheus + Exporters + 时序数据库这套组合，它的核心思想是“主动拉取”和“按指标建模”。应用暴露HTTP接口，Prometheus定期来抓取，数据进入时序库，再通过Grafana出图。这套方案的优点非常明显：链路短、简单直接、告警规则成熟、社区生态庞大。但它天然对日志和链路追踪支持不足，而且在Kubernetes环境下做服务发现虽然方便，碰到需要采集业务日志的场景就得另起炉灶。

日志集中型架构是ELK/EFK加上Kafka缓冲层的经典组合。Filebeat采集日志，Kafka做削峰填谷，Logstash或Fluentd做清洗和转换，最终落到Elasticsearch，Kibana负责可视化。这套架构的价值在于把日志作为核心数据源，检索能力强，适合审计类、排障类、业务分析类场景。但它的坑也比较稳定：Kafka和ES都是重组件，维护成本高，数据量大时冷热分离和索引生命周期管理很折腾人。

统一Agent可观测平台型是最近几年增长最快的路线。以OpenTelemetry为数据规范，配合一个统一的Agent（比如Grafana Alloy、Grafana Agent或者商业方案里的采集器），同时采集Metrics、Logs、Traces、Profiles四类信号，后端分别对接Prometheus、Loki、Tempo、Pyroscope这类组件。这东西最大的好处是标准化，一套Agent解决所有数据接入问题，避免了每个团队各搞一套采集器。

eBPF无侵入型走的是另一条路。这类方案的代表有Cilium Hubble、Pixie、DeepFlow等，利用内核的eBPF能力直接在系统调用、网络协议栈层面采集数据，业务应用完全不需要改动，也不用装Agent。适合有大量第三方或历史遗留系统的场景，特别是网络调用链追踪和性能剖析，效果非常惊艳。缺点是平台化门槛高，对内核版本有要求，而且采集到的数据维度偏“系统级”，业务层面的语义还得靠其他手段补齐。

从演进逻辑上看，这四类架构不是简单的迭代替代关系，而是各有各的生存空间。小企业从Prometheus起步，发展到一定规模就会觉得日志检索不够用，于是引入ELK；等微服务和Kubernetes复杂到一定地步，多信号关联分析成为刚需，统一Agent平台就是必然选择；再往后，如果发现常规Agent对业务代码的侵入成了负担，eBPF就会作为补充手段被引入。这个路径我在不少公司身上都见过，几乎成了某种行业规律。

这里有个容易忽略的大背景：OpenTelemetry在2025年前后已经成为跨厂商的标准数据格式，大多数商业可观测平台都在向OTel兼容靠拢。这意味着2026年做选型，第一优先级是先看架构对OTel的支持程度，而不是看单一厂商的功能列表。后面我会逐个拆解每种方案的适用边界和落地技术细节。

2. 选型前必须回答的四个关键问题

很多团队一上来就对比Grafana和Datadog、对比ELK和Loki，这其实是走反了方向。我在帮客户做方案对比时，习惯先让他们回答几个问题，这些问题的答案会直接砍掉一半的候选方案，比纠结具体功能有用得多。

2.1 数据规模和增长趋势

数据规模是最硬性的约束条件。这里的规模不只是“现在一天产生多少日志”，而是要考虑一年后、两年后的增长速度。我之前遇到过一家做IoT设备的公司，一开始觉得自己一天几个GB日志很小，选了最简单的ELK单节点方案，半年后设备出货量涨了十倍，日志量直接冲上每天几个TB，集群扩了又扩，运维同学天天在跟分片数和磁盘水位斗争。

如果你预期单日数据增量很快就会超过TB级别，那Kafka缓冲层几乎就是必选项，同时存储层要尽早考虑冷热分离。如果数据规模长期保持在几百GB以下，完全没必要上Kafka，Filebeat直接到Logstash再到ES就够了，多加一层只会增加延迟和故障点。

对于纯指标场景，时序数据库的选型也跟规模强相关。单机Prometheus能扛的序列数在百万级别，一旦超过这个量级，就要考虑Thanos或VictoriaMetrics这类方案，或者直接选云厂商的托管时序库。很多团队一开始图省事用单机Prometheus，序列数到几百万后查询开始超时，告警评估也跟不上，最后只能做迁移，迁移成本比当初直接上分布式方案高得多。

2.2 团队的技术栈和运维能力

架构选型最终要落到来维护的团队身上，这一点太容易被人忽视。一套开源组件的组合方案，看起来成本低，但背后的部署、调优、升级、排障全是要人力去填的。我见过一个团队只有两个运维，前面提到的那种“Prometheus全家桶 + ELK + Tempo + Loki”全上，结果光是处理组件之间的版本兼容就能把人耗干。

比较务实的做法是先盘点自己团队的技能树和可投入的精力。团队擅长Java，那Logstash和Elasticsearch生态的维护压力会小很多；团队对Go比较熟，Prometheus体系和VictoriaMetrics的二次开发就更有把握。如果团队规模不大，我认为优先选择商业SaaS或者云厂商的全托管可观测产品反而是划算的，隐藏成本更可控，这也是2026年一个明显的行业趋势——中小企业不再强求自建监控栈，而是用托管服务换研发精力。

另外还要考虑一个问题：你的平台是一锤子买卖还是长期演进项目。如果只是短期内部工具，那用开箱即用的方案，别在定制化上花太多时间；如果是准备沉淀成公司级平台，给几十个业务团队使用，那架构的扩展性、多租户能力、权限治理在选型阶段就要有明确规划，后期的改造难度非常高。

2.3 数据类型和消费场景

监控数据从信号类型上分，至少包括Metrics、Logs、Traces、Profiles、Events五类，不同类型对应的最佳存储引擎和查询方式差异很大。你在选型前，必须先搞清楚自己的核心消费场景到底是哪种。

以业务监控为主，核心是曲线和告警，那Prometheus体系天然最合适。因为它的数据模型就是为指标设计的，标签索引、聚合查询、阈值告警，每一步都很顺手。以问题排查为主，关键诉求是关键词检索和上下文关联，那ES或者Loki这类日志系统更重要。以性能瓶颈分析为主，那链路追踪和持续剖析就是刚需，接入OpenTelemetry和Pyroscope这类组件比堆日志更有价值。

绝大多数中大型团队的实际状态是“我全都要”，所以后面的架构选择往往会走向多信号融合的统一平台。这个事情有个需要注意的地方：不要为了追求统一而强行把所有数据塞进同一套存储，这是2026年选型最常见的误区之一。Metrics进时序库、Logs进倒排索引库、Traces进专门追踪存储，它们的设计哲学本来就不一样，强行统一的结果往往是哪边都做不好。

2.4 业务对可观测性的成熟度要求

最后一个问题容易被技术团队忽略：业务团队是否真的具备使用可观测平台的能力。监控平台的建设不只是一个技术项目，它伴随着一套工作方式的改变。过去业务看板是运营在Excel里做报表，现在要把数据链路打通，让业务指标、服务指标、资源指标关联分析。

如果业务团队还没有形成基于SLO的数据驱动文化，立刻上一套功能很重的可观测平台，大概率的结果是没人用。这种情况下，我建议先从最基础的核心指标和告警入手，把PV、成功率、延迟这些骨干指标做扎实，再逐步引导业务团队用平台数据去做决策。反之，如果团队的可观测性文化已经很成熟，那选型时就要特别关注SLO管理、错误预算、燃烧率告警这类高阶功能的支持度。

3. 四类架构的适用边界与落地差异对比

下面进入正题，细聊四种架构各自的适用场景、设计细节和落地时容易踩的坑。

3.1 指标直连型：小规模团队的黄金起点

适用边界方面，指标直连型适合数据规模可控、核心需求是指标监控和告警、团队运维能力有限的场景。与其说它像一个完备的监控平台，不如说它是性价比最高的起步方案。如果你的业务场景不需要复杂日志检索，也不要求链路追踪，这套架构两三天就能跑起来，出图、告警、邮件通知都能快速搞定。

在技术实施层面，核心设计是合理规划指标采集路径。Exporter负责暴露指标，Prometheus定期拉取，存储到本地TSDB，Grafana负责展示。为了让这套架构能撑住更大的规模，有几个关键优化点值得提前做。

首先，抓取周期要分级设计。默认的15秒抓取周期不是万能的，低频变化的指标（比如机器磁盘总量）完全可以放到30秒或60秒，高频业务指标（比如请求量、错误率）才用15秒甚至10秒。分级抓取能显著减少Series数量，降低存储压力。

其次，合理利用Recording Rule。Prometheus的查询在数据量大的时候执行比较慢，特别是频繁被Dashboard和告警复用的高基数查询。把这类查询预计算成新的时间序列，让查询变成查结果而不是实时算，对性能改善非常明显。这个优化在数据快上量的时候几乎是必做的。

然后是存储层的高可用设计。单机Prometheus自带的是本地存储，虽然够用但不具备持久化保证，节点挂了数据就丢了。规模上来后，建议用Thanos或者VictoriaMetrics做远程存储，把Prometheus变成无状态采集器，数据落到分布式存储里。这样的好处一个是容量可以横向扩展，另一个是不用担心单点故障导致历史数据全部丢失。

这套架构最大的优势是轻，代价是它管不了日志和链路。很多团队最后都是在这套方案跑顺之后，开始逐步引入Loki做日志，引入Tempo做追踪，最终演进成完整的三支柱方案。

3.2 日志集中型：当检索成为刚需

适用边界方面，日志集中型架构适合日志量中等以上、检索和排障是核心诉求的团队。与指标型不同，日志集中型的核心是管道，文件采集、传输缓冲、清洗解析、索引存储，每个环节都有明显的位置感。

我从具体链路开始拆解。Filebeat作为轻量级采集器放在业务机器上，负责读取日志文件并运输到Kafka。Kafka在这里承担的是缓冲和削峰的作用：日志产生速度有波动，ES的写入能力有限，Kafka在中间吸收这些波动，避免数据丢失和ES写入超限。Logstash从Kafka消费数据，做字段解析、格式转换、数据清洗，然后写入Elasticsearch。最后Kibana提供查询和可视化界面。

用这套架构，日常排障体验非常好。出了请求失败，直接按traceId去Kibana里搜日志，所有上下文一目了然。但维护成本和资源占用都不低，这也是日志集中型最明显的问题。Kafka集群要维护Topic、分区、消费者组和副本同步。ES集群要操心分片分配、JVM堆内存、冷热节点、索引生命周期。任何一个环节失守，都会影响整个日志管道的健康。

落地时我特别强调几个细节。Kafka的分区数设置要考虑消费者并行度：分区数要大于等于消费者实例数，否则会有消费者空闲。生产一个日志类Topic的分区数，我一般建议按消费者实例数的3到5倍设置，这样既保证并行消费能力，又留了扩容空间。Topic的副本数在生产环境至少2，条件允许就设3，毕竟日志丢失对排查问题是致命的。

ES的索引策略建议按天分索引，配合生命周期管理。比如热阶段存3天，使用SSD；温阶段存7天，用普通磁盘；冷阶段存30天后删除或归档。这个策略直接决定了磁盘成本和查询效率的平衡。很多团队最初不重视这个，日志量上来后磁盘直接被打满，才回来配ILM策略，实际上已经付出了不少代价。

3.3 统一Agent平台型：多信号融合的标准化选择

适用边界方面，统一Agent平台型的价值在微服务和Kubernetes环境里体现得最明显。业务拆分的粒度越细，服务间的调用关系越复杂，对Metrics、Logs、Traces、Profiles多信号关联分析的需求就越强。这种场景下，如果每个信号都用不同的采集器、不同的规范、不同的后端，维护成本会失控，排障时信号之间的关联也成了问题。

统一Agent平台型的核心是OpenTelemetry。OTel定义了日志、指标、链路追踪、持续剖析的统一数据模型、采集规范和传播协议。应用通过SDK做埋点，或者通过Agent自动注入，把数据按OTel规范发出来，交给OTel Collector做处理，再分发到各类后端。这个设计把数据采集和存储解耦得比较彻底：采集端只负责输出标准格式，存储端只负责按类型存储数据。

具体到落地环节，有几个技术点比较关键。

Agent的部署形态上，Kubernetes环境推荐用DaemonSet方式部署，每台节点一个采集器，通过端口或者Unix Socket接收本节点业务Pod的数据。Kafka环境可以用Java Agent方式对Java应用做字节码注入，无感知地接入链路追踪。如果是多语言环境，再用OTel SDK在应用里做手动埋点，补足自动注入覆盖不了的部分。

OTel Collector的配置也很关键。它的Pipeline由Receivers、Processors、Exporters三段组成。Receivers负责接收数据，Processors负责处理，比如批处理、采样、过滤、属性修改，Exporters负责发送到后端。在规模较大的集群里，建议把OTel Collector拆成Agent和Gateway两层：Agent部署在节点上负责轻量采集，Gateway独立部署负责聚合和转发。Gateway层可以承担更多的数据处理任务，比如跨服务Trace的串联、敏感字段的脱敏，这都能让Agent层保持轻量。

后端层面，OTel的Metrics数据可以对接Prometheus、VictoriaMetrics或云上时序库；Logs可以对接Loki或Elasticsearch；Traces可以对接Tempo、Jaeger或者其他链路追踪后端。具体后端的选择可以结合已有的基础设施和团队的熟悉度来定，不需要追求全面切换。

这套架构的优点是规范化好，数据模型统一，一套Agent覆盖所有信号类型，团队学习和维护成本低。需要注意的问题是标准化带来的兼容性约束：某些老系统或特殊组件对OTel的支持不完善，工作量集中在适配和补全数据链路上。

3.4 eBPF无侵入型：特殊场景下的强力补充

适用边界方面，eBPF无侵入型最大的价值是“不动业务代码、不加业务Agent”。对于大量历史遗留系统、第三方商业软件、容器网络监控、性能剖析这类场景，常规Agent方案经常会遇到“没法装Agent”或者“不允许改代码”的限制，eBPF方案就能解决这个问题。

eBPF在内核层面挂载探针，可以直接观察系统调用、网络收发、进程调度等底层事件。基于eBPF的监控方案，比如Pixie和DeepFlow，可以做到完全无侵入地采集到Pod级别的网络流量、HTTP请求、数据库访问、DNS解析延迟等数据。这个能力对微服务环境下的网络及依赖问题排查特别有价值。我在一个实际项目里用DeepFlow做过一次网络链路分析，很快就定位出一个跨多个服务的偶发超时问题，原本这种问题靠业务日志排查是相当困难的。

相比前几类架构，eBPF方案实施起来要关注的点不太一样。内核版本必须满足要求，至少是4.14以上，版本越老，能用的探针类型越少。容器运行时的权限配置也要放开一些内核能力，比如SYS_ADMIN、SYS_PTRACE等，这在很多安全要求高的企业里要进行合规评估。数据采集的粒度也需要注意，eBPF采集高频事件时会产生大量数据，如果没有配合合理的采样策略，存储和网络开销会很大。

不过eBPF方案也有它的局限性。它只能看到系统层和网络层的数据，业务层面的语义需要结合日志和指标来理解。对HTTP/HTTPS流量的完整解析依赖协议栈支持，遇到自定义二进制协议、加密流量解析不出来就是个麻烦事。所以eBPF更适合作为Agent方案的补充而不是替代，两者结合才能形成完整的数据视图。

4. 架构选型的决策路径与实操落地细节

4.1 决策路径：五分法判断自己该走哪条路

把四类架构的核心逻辑讲清楚之后，我分享一个相对完整的选型决策路径，算是我这几年实操下来觉得最不容易出错的流程。整个决策分成五步，每步问一个问题，按答案逐步收窄范围。

第一步，不做自研。除非你的团队有充足的人力和非常清晰的定制需求，否则建议站在成熟方案和组件基础上选型。自研采集器、自研存储引擎、自研查询层，每一条都是投入产出比极低的路线，哪怕在2026年，我依然坚持这个判断。监控系统的价值体现在数据闭环和分析问题上，不是体现在重复造轮子上。

第二步，确认信号类型和规模。盘点一下你的核心场景需要哪些信号：只要指标，那跳过日志方案和eBPF方案，直接进指标型。只要日志检索，那就进日志型。需要两三种信号以上的，通常就要考虑统一Agent平台了，因为用多套采集方案拼起来的数据关联性会很差。在确定通道后，再用日志量和指标序列数来约束存储方案的选择。

第三步，评估环境限制。如果是Kubernetes环境为主，指标型和统一Agent平台型优先考虑；如果有大量虚拟机、物理机上的老系统，日志型和eBPF型的价值就凸显出来。这里特别强调，eBPF方案不是首选项，是环境逼到那个份上才选它。

第四步，盘点团队能力与运维资源。两条路摆在你面前，一条维护成本高但灵活，一条维护成本低但约束多，选哪个取决于团队的时间和技能。以我的经验，大多数团队高估了自己维护开源组件的耐心和精力，低估了托管服务的长期价值。

第五步，考虑演进路径。不要只看今天的需求，要判断一年后这个平台会被多少人、多少业务团队使用。如果预期会快速扩大，那选型时就应该偏向开放标准和生态更丰富的方案，避免被锁定在封闭体系里，后续的集成和扩展才不会被卡住。

4.2 核心组件选型建议

选型决策做完后，真正动手时还得做组件选型。以下是我基于2026年实际生态给出的推荐组合，按场景列出来，供参考。

指标场景的采集端，Prometheus依然是首选标准。如果你需要推模式，可以补一个Pushgateway，可以一边用拉模式一边用推模式，但不能替代Prometheus的主体地位。存储端，单机和轻量场景直接用Prometheus本地存储；几千台机器、几百万序列数的生产环境，用VictoriaMetrics，兼容性好，运维成本远低于Thanos；如果公司已经重度用云，直接选云厂商的托管时序库，省事很多。

日志场景的采集端，Filebeat或者Fluent Bit都是轻量级的选择，前者适合文化较成熟的团队，后者资源占用更小。传输层看数据量：几百GB到几个TB日增量，直接走Kafka作为缓冲；规模更小的，可以由采集器直连Logstash或Golang的采集管道，简化链路。存储端，Elasticsearch还是首选，数据检索能力强，生态最成熟；Loki更适合以Kubernetes为核心且希望降低存储成本、日志量中等规模的团队，它的索引方式是按标签而非全文，查询能力弱一些但存储量压缩效果好。

链路追踪场景，后端选Tempo或Jaeger，两者都符合OTel规范，Tempo更重视与Grafana生态的集成。持续剖析选Pyroscope，跟Grafana的Dashboard可以直接联动。可视化层如果已经选了Grafana，监控、日志、追踪、剖析都能在一个界面里统一看，这个体验个人体验还是很重要的。

4.3 一个典型的落地路径演示

理论讲得再多，不如直接把一个典型的中型团队落地路径写出来，方便大家对照参考。

假设一个公司规模在200台主机左右，核心业务是微服务架构部署在Kubernetes上，日志日增量在1TB以内，团队运维能力中等。我的建议落地路径是：第一阶段先部署Prometheus + Grafana + Alertmanager，把基础设施指标和核心业务指标的监控告警先做起来，这一步通常一周内就能完成。第二阶段针对日志场景，部署Filebeat采集日志，Logstash解析清洗，写入Elasticsearch，配好索引生命周期管理，让排障场景先用起来。第三阶段根据实际需求再考虑引入OpenTelemetry做链路追踪，比如发现跨服务调用问题频繁排查效率低的时候，就值得引入了。最后如果评估后发现一些老系统无法接入Agent，再考虑用eBPF方案做无侵入的网络和系统观测补盲区。

这个路径对大多数中等规模团队来说是最平滑的，每一步都能在较短时间内产生可见价值，又不会同时引入过重的维护负担。很多项目失败，往往不是选型选错了，而是步子迈太大，一次引入一堆组件，还没跑通就已经把团队消耗光了。

5. 常见问题与排障实录

5.1 数据采集不完整

采集不完整是需要优先排查的问题。先确认Agent或者Exporter运行状态和日志有没有报错，再看采集到的样本数量是否符合预期。一个常见的坑是Kubernetes环境下Pod重新调度后，采集目标的标签配置没有同步，导致部分Pod的数据缺失。排查这类问题最好的工具是Prometheus的Targets页面，以及检查服务发现是否生效。

另外很多团队容易忽略采集超时问题。Exporter接口响应太慢，Prometheus在抓取窗口内拿不到完整数据，就会出现采集断档。这种情况一般要优化Exporter的查询逻辑，把大查询拆小，或者增加抓取间隔。我在实践中把一些大数据量Exporter的抓取间隔从15秒调到30秒，断档问题就消失了，效果立竿见影。

5.2 Kafka消费堆积

日志型架构里，Kafka消费堆积大概是最常见的告警项之一。处理思路是先看消费者的Lag，如果Lag持续上涨，说明消费速度跟不上生产速度。这时候先不要急着加消费者实例，而是先检查下游存储是否成为瓶颈：ES写入是否过慢、Logstash的管道是否阻塞、磁盘IO是否被打满。

如果下游没有问题，再来考虑调优。常见手段包括增加Topic的分区数、增加消费者实例数、增大消费者的批量拉取大小和提交间隔。这部分调整最好基于监控数据来判断，而不是盲目扩容。我遇到过一种比较有意思的情况：Logstash的pipeline配置写得太重，每个事件做了一堆正则解析，吞吐量直接掉了一个量级。把正则优化成grok预编译之后，消费速度立刻上来了。

5.3 时序库存储膨胀

Prometheus存储膨胀几乎是所有指标监控方案在规模增长后都会遇到的问题。判断存储是否膨胀，核心指标是每个Target暴露的Series数量以及标签基数。标签基数过高是存储膨胀的元凶，特别是那些值变化很频繁的标签，比如把用户ID、请求URL直接放到指标的标签里。

解决存储膨胀的套路比较固定：一是在Exporter端限制指标暴露，只保留必要的指标，用metric_relabel_configs把不需要的时间序列直接丢弃；二是在采集侧做标签规整和聚合，用Recording Rule把高基数指标降维；三是如果仍然不够，考虑扩展存储层，比如加Thanos或者VictoriaMetrics，让容量和查询性能都能跟得上。我个人建议一上来就用VictoriaMetrics，因为Prometheus单机存储的坑，很多团队都是踩完之后才意识到要补。

5.4 链路追踪与日志关联不上

统一Agent平台里常见的一个问题是链路追踪数据跟日志数据无法关联。明明同一个请求，traceId在链路数据里查得到，但到日志系统里搜不到。这个问题的根因几乎都是日志中根本没有打印traceId，或者打印了但采集器没有把traceId提取成单独的字段。

解决思路分两层：应用侧要确认日志输出格式中包含traceId，OpenTelemetry的SDK会自动把这个字段注入到相关的日志上下文。采集侧要确保日志管道把traceId作为索引字段处理，比如在Loki里配置结构化元数据，或者在ES里用单独的字段存储。链路追踪和日志关联是统一可观测平台最有价值的场景之一，这个打通工作值得做透。

5.5 eBPF方案的内核兼容性

最后聊一下eBPF方案落地时最容易踩的坑：内核版本和权限问题。eBPF探针的可用性依赖内核版本以及编译时的BTF支持。理想状态是内核5.x以上，带BTF，这样探针切换维护成本很低。如果内核版本低于4.14，很多关键探针类型根本用不了，方案基本可以放弃。这些限制在选型阶段就要评估清楚，别等部署到一半才发现跑不起来。

权限方面主要是容器环境的安全策略限制，比如Pod安全策略禁止了CAP_SYS_ADMIN或者CAP_BPF，挂载探针就会失败。遇到这类问题，排查落地团队是否有权限调整安全策略，这个环节卡壳的话，eBPF方案的推进阻力会非常大。

6. 一些不太多人提的经验之谈

聊到这里，四类架构的技术细节和落地差异应该已经很清楚了。最后分享几条我在实际项目中反复验证过的个人体会，不算完备，但都是踩过坑换来的。

第一件事，监控体系基础打不好，后面什么高级功能都白搭。数据采集的稳定性永远是最优先的，无论你用哪种架构，每个环节的监控都要覆盖到，比如采集器自身的存活、管道的Lag、存储的容量水位、查询的耗时。我之前见过不少团队搞了一堆漂亮的Dashboard，结果底层数据链路空转，问题出来一个都看不见。

第二件事，告警要做减法而不是加法。监控建设的前期，大家容易把告警规则越加越多，最后变成告警风暴，重要告警反而被淹没了。我个人比较推崇基于SLO的告警方式，围绕错误预算和燃烧率来做告警设计，比盯着一堆阈值更有效，也能迫使团队真正理解自己服务的核心指标。告警策略的持续优化比配置告警重要得多。

第三件事，选型落地要坚持标准化。2026年这个时间点，OpenTelemetry已经是实际上的行业标准了，新引入的组件和服务必须优先考虑对OTel的兼容。标准化带来的红利不是立刻体现的，而是半年后、一年后，当你要接入新系统、要做跨团队的数据打通时，你会感谢当初那个“不为眼前方便妥协标准”的决定。

第四件事，可观测性解决的是“未知的未知”问题，而监控解决的是“已知的已知”问题。这个词看着有点抽象，但落到工程实践上非常重要。监控是假设你知道要关注哪些指标，然后设置告警去盯。可观测性则是当出现一个你完全没有想到的症状时，你能通过数据快速构建出问题上下文。这两种能力的建设思路其实完全不同，选型时也要先想清楚自己当下更缺哪一块。多数团队前期更需要的是把告警和监控做扎实，后续再去追求更完整的可观测能力，这个顺序本身是符合事物发展规律的。

最后再提一个小技巧，无论选哪条路，第一阶段的平台请务必让业务团队真正用起来，而不是建设完就束之高阁。可观测平台的价值需要在真实问题的定位中才能体现出来，让一两个核心业务团队先深用起来，用出典型场景和标杆案例，后续推广的阻力就会小很多。好的基础平台会替团队省出大量排查问题的时间，但前提是大家愿意从Excel记事本里走出来，真正把平台当作日常工作的一部分。