你打开一个网页，看到的是一个页面。但在页面背后，有许多看不见的基础设施正在同时工作：服务器负责计算，数据库保存数据，网络负责连接不同服务，容器帮助应用稳定运行。正是这些底层资源，共同支撑着业务能够稳定运行。

这些基础设施不会直接告诉你“我快出问题了”，但它们会通过运行状态留下很多信号。CPU、内存、磁盘、网络等指标，就是这些信号的表现形式。这些指标，就像系统状态的“体温计”，帮助工程人员了解系统当前是否健康。当某些指标出现持续变化时，团队可以据此判断系统是否正在承受压力，并进一步寻找异常发生的位置。

过去，当业务主要运行在少量服务器上时，查看基础资源指标通常可以快速判断问题方向。随着云计算、微服务和容器化架构的发展，应用运行环境逐渐由多个服务和基础组件共同组成，故障定位也从单点检查变成跨层分析。

工程团队需要回答：问题发生在哪个资源？影响的是哪个服务？背后的原因是什么？

这也是基础设施可观测性需要解决的问题。

观测云基础设施监控：连接分散的基础设施信息

基础设施排障的难点，并不是缺少数据，而是这些数据往往分布在不同层面。主机、进程、容器、数据库和网络分别描述了系统的一部分状态，真正的问题定位需要把这些信息关联起来。观测云 Infrastructure Monitoring 将这些基础设施信息整合到统一视角中。 当业务出现异常时，团队可以基于已有线索查看相关资源状态，并结合不同层级的信息进行分析。

后续章节将围绕这些核心能力展开，介绍它们如何在实际基础设施监控和故障定位过程中发挥作用。

主机监控：先从基础资源状态发现异常

服务器是业务运行的基础。当应用出现响应变慢、服务波动等问题时，团队通常需要先确认基础资源是否处于正常状态。

在传统环境中，服务器数量有限，资源状态相对容易掌握。但随着业务规模扩大，生产环境中往往存在大量主机，单靠人工查看很难及时发现异常变化。

观测云主机监控通过采集服务器运行状态和关键资源指标，让工程人员在统一视图中查看主机状态。 结合 CPU 使用率、内存使用情况、磁盘状态等信息，团队可以判断当前异常是否与基础资源压力有关，并定位需要关注的主机。

在主机列表中，工程人员可以快速查看不同服务器的资源状态，发现 CPU、内存等指标异常的主机。

进入主机详情后，可以查看资源变化趋势，判断异常是否来自基础资源压力。

主机监控提供的是基础设施排查的第一层视角。当服务器出现资源压力时，团队可以结合进程、容器等更细粒度的信息继续分析问题来源。

业务异常并不一定意味着服务器已经不可用。有时只是某些资源指标持续升高，正在影响应用稳定性。当某服务响应时间增加时，团队可以通过主机监控查看相关服务器状态，判断 CPU、内存等资源变化是否与当前问题相关。

进程监控：找到资源异常背后的来源

主机指标可以告诉团队哪里出现压力，但无法直接说明压力来自哪里。如果一台服务器 CPU 使用率持续升高，可能是访问流量突然增加，也可能是某个应用进程异常占用了大量资源。如果无法继续定位具体进程，如果无法继续定位具体进程，团队仍需要花费大量时间逐步排查。

观测云进程监控提供主机内部运行进程的状态和资源使用情况，帮助团队了解服务器内部正在运行的程序，并分析不同进程对 CPU、内存等资源的占用情况。

通过进程视角，团队可以将排查范围从“某台服务器出现异常”缩小到“某个具体程序或服务出现问题”，为后续分析代码逻辑、服务运行状态等问题提供依据。

在实际生产环境中，资源异常往往只是表象。例如，当某服务运行过程中出现 CPU 持续升高时，团队可以先通过主机监控确认异常服务器，再进入进程视角查看具体资源占用情况。如果发现某个业务进程长期占用大量 CPU，就可以结合应用变化、任务执行情况等信息分析原因。

如果该服务运行在容器化环境中，还需要继续查看对应的 Container、Pod 以及 Kubernetes 资源关系，以判断问题是否与运行环境有关。

容器与 Kubernetes 监控：从运行环境中发现服务异常

在云原生环境中，服务器状态正常并不代表应用运行正常。服务可能因为 Container 异常退出、Pod 重启或资源分配不足影响业务，而这些问题仅通过主机指标通常难以判断。

观测云容器与 Kubernetes 监控覆盖 Container、Pod 以及集群资源状态，工程人员可以查看应用在容器化环境中的实际运行情况，并分析不同资源之间的关联关系。

通过 Kubernetes 视角，团队可以查看集群中的 Node、Pod 和 Container 等运行对象，并结合资源状态判断异常发生的位置。

在实际生产环境中，当业务出现异常时，排查重点往往不仅是“服务器有没有问题”，还包括“应用运行环境是否稳定”。例如，某个订单服务出现访问异常，但服务器 CPU 和内存指标正常，进一步查看 Kubernetes 状态后发现对应 Pod 频繁重启，团队便可以继续分析容器配置、资源限制或服务自身问题。

对于运行在复杂 Kubernetes 集群中的业务，了解资源之间的关系同样重要。通过查看节点、Pod 和 Container 之间的关联，团队可以更快建立对当前运行环境的理解，并缩小问题范围。

数据库监控：识别业务访问瓶颈

很多接口响应变慢的问题，最终并不发生在应用代码本身，而是来自数据访问环节。

在实际生产环境中，一个接口响应变慢，原因可能来自多个环节。代码执行效率、基础资源状态、服务调用情况以及数据库查询性能，都可能影响最终响应速度。

数据库作为业务系统中承载数据存储和查询的重要组件，一旦出现性能问题，往往会直接影响上层应用。例如，查询耗时增加、数据库连接压力升高，都可能导致接口响应变慢。

观测云数据库监控关注数据库运行过程中的关键性能信息，包括数据库实例状态、查询性能和关键运行指标，帮助开发和运维人员了解数据库状态，并判断性能问题是否来自数据访问层。

通过数据库监控视角，团队可以查看数据库请求变化、查询耗时等信息，快速判断数据库是否成为影响业务稳定性的原因，并进一步定位需要优化的查询操作。

在实际排障过程中，数据库问题通常不会直接表现为“数据库故障”，而更多体现为业务体验下降。

当某个业务接口出现响应延迟时，团队可以结合前面的基础设施信息确认服务器、进程和运行环境状态。当接口响应出现异常时，数据库查询性能也是需要关注的重要方向。

例如，在订单查询场景中，如果部分请求响应时间持续增加，通过数据库监控发现某些查询耗时明显上升，团队就可以围绕相关 SQL、数据访问逻辑或数据库配置继续分析问题。

网络监控：发现服务通信异常

在微服务和分布式架构中，业务不再由单个应用完成，而是由多个服务共同协作。服务之间需要不断进行数据传输和调用，网络状态也因此成为影响业务稳定性的重要因素。

当服务出现响应延迟或调用失败时，问题不一定发生在应用本身，也可能来自服务之间的通信过程。例如，服务连接异常、网络延迟增加或者流量波动，都可能影响最终业务表现。

观测云网络监控通过分析网络连接、流量变化以及异常状态，帮助团队了解基础设施网络层的运行情况，并判断业务问题是否与网络因素相关。

通过网络监控视角，团队可以观察不同服务之间的通信情况，快速发现连接异常、流量波动等问题，并进一步缩小故障排查范围。

服务调用异常时，问题并不一定发生在应用本身，也可能来自服务之间的通信过程。当某个服务接口出现超时，但服务器资源、应用进程和数据库状态均未发现明显异常时，团队还需要确认服务之间的通信是否正常。

通过网络监控，团队可以观察相关连接状态和网络变化，判断问题是否发生在基础设施网络层，并结合其他观测数据继续分析影响范围。

Obsy AI Copilot 帮助理解基础设施

Infrastructure Monitoring 让工程团队能够从不同层面看到系统状态，而 AI 可以进一步参与异常分析。

一次指标变化或服务异常，通常不会直接告诉工程师原因在哪里。真正困难的是将这些变化与相关资源、服务关系以及历史信息联系起来，判断哪些线索值得继续关注。

在这样的排查过程中，AI 可以帮助工程人员理解系统状态。观测云 AI 基于已有观测数据，对指标变化进行分析，并结合相关上下文帮助工程人员理解当前异常背后的可能原因。

当某项指标出现异常趋势时，工程人员可以结合 AI 对当前数据、关联资源以及历史变化进行分析，判断问题可能涉及的方向，并获得后续排查思路。

通过 Obsy AI Copilot，工程人员可以直接在当前观测页面中与 AI 交互，让 AI 基于当前视图和数据上下文参与分析，而不需要重新整理问题背景。

构建统一基础设施可观测能力

基础设施是业务稳定运行的底座，但一次真实的问题排查，往往不会只停留在某一个层面。一次服务异常可能同时涉及服务器资源、应用调用、日志信息以及业务影响范围。单独查看某一类数据，通常只能看到问题的一部分，而完整定位问题需要将不同层面的信息结合起来分析。

Infrastructure Monitoring 帮助团队了解基础设施运行状态，快速发现主机、容器、数据库以及网络层面的异常。但在实际排障过程中，基础设施问题往往还会进一步影响应用表现，因此需要结合 APM、日志等观测数据，从资源状态、服务调用和错误信息等多个角度还原问题发生的过程。

随着系统规模不断扩大，工程团队面对的不只是“有没有异常”，而是如何从大量运行数据中快速找到关键线索。AI 的加入，让可观测平台能够进一步辅助分析这些数据，帮助团队理解指标变化、关联资源以及异常背后的可能原因。

通过统一的数据视角，将基础设施、应用和业务信息连接起来，让工程团队从发现问题、分析原因到定位影响范围，形成更加完整的问题排查路径。