摘要

  • RFC 2039 把管理信息分成两层：操作模型描述硬件、操作系统、进程、依赖与容量，服务模型描述 Web 客户端发出的请求以及服务器给出的响应。
  • 文档认为当时已有的 MIB 能覆盖相当一部分主机侧信息，却不足以独立说明服务侧状态；一台主机承载三个虚拟域名的例子尤其说明，服务身份与底层进程之间没有天然的一一对应关系。

“服务器在线”看似是一句完整的判断，其实只回答了被观察对象的一部分。CPU 没有耗尽、磁盘仍可读、网卡仍在收发、进程没有退出，这些事实都可能成立；与此同时，某个虚拟站点需要的网关或数据库已经失效，客户端仍然拿不到动态页面。

RFC 2039 正是从这里开始。它于 1996 年 11 月发布，全名是《标准轨 MIB 对万维网服务器管理的适用性》。它是一份 Informational 文档，不是互联网标准。文档应网络管理领域主管要求而作，回应了同年洛杉矶第 35 届 IETF 会议上的 HTTP-MIB BOF 讨论。它没有发明一套万能指标，而是先把“管理什么”拆清楚。

操作模型把 Web 服务器看成一台计算机：处理器、磁盘、网络接口、操作系统、服务器软件、安装文件与运行进程。这里关心的是资源利用率、应用依赖、错误报告、历史容量，以及停止、重启或重新配置一个组件时会影响谁。

服务模型则暂时把机器内部当作黑箱，只看它是否处理来自 Web 客户端的请求并产生响应。这里关心检索服务如何被使用、性能如何、静态和动态文档是否可用、访问权限是否生效，以及生成动态内容的网关或数据库是否处于可工作状态。

两种模型互相补充，却不能互相替代。主机数据回答“机器与进程发生了什么”，服务数据回答“请求与响应发生了什么”。一个答案为真，不能推出另一个答案也为真。

三个虚拟域名暴露出的映射问题

RFC 2039 认真盘点了当时已有的工具。MIB-II 提供系统与接口信息；Host Resources MIB 描述处理器、存储、设备以及安装或运行的软件；Network Services Monitoring MIB 记录服务应用及其活动关联；Application MIB 工作则试图进一步描述可执行文件、文件与经过插桩的应用。

文档没有否定这些工具。它判断，主机侧的大部分需求已经能够得到满足，Network Services Monitoring 也覆盖了部分服务视角。但这些信息栈彼此正交，任何一套都没有同时穿透两层。服务与进程的关系也不是加一个指针就能解决，因为软件的组合方式取决于具体实现。

文档用一台物理主机承载三个虚拟域名来说明问题。三个域名可能由同一个进程提供，也可能各由一个进程负责；某个动态页面还可能依赖外部网关和数据库，静态文件则没有这条依赖。进程表可以准确报告服务器程序仍在运行，却未必说明哪个虚拟服务失败、哪个域名传输了什么。服务表可以区分虚拟域名和连接，却未必告诉运维人员该重启哪个可执行程序、检查哪个配置文件或追踪哪个下游应用。

因此，缺的不是“更多数字”，而是一张持续维护的对应关系：服务身份如何落到进程、文件、网关和数据库上；同时还要有 Web 专用的观测，描述请求、文档与响应本身。

两层各自需要什么

在操作层，RFC 2039 要求监测 CPU、磁盘和网络容量，明确应用之间的依赖，以统一方式生成和报告错误，用历史数据支持容量规划，并把通常散落在日志里的重要活动转成结构化管理信息。依赖关系尤其关键，因为同一个程序可能承载多项服务，一次重启会跨越原本以为独立的边界。

在服务层，文档要求观察检索服务的使用和性能，覆盖静态与动态文档，记录文档访问与权限，并检查提供动态信息的应用是否正常。它还提出集中配置、启动、停止、日志轮转以及服务质量指示等控制面需求。

这里不能把历史术语包装成今天的成果。RFC 2039 没有给出可靠性改善幅度，没有定义现代意义上的服务目标，也没有证明某个实现得到广泛部署。它提到的 Internet-Draft、邮件列表与样例实现，只能证明当时有人在做这项工作。安全问题则被明确排除在讨论之外。

1999 年的 RFC 2594 把服务侧进一步具体化。它以抽象文档传输协议为基础，描述 WWW 服务、请求、响应、状态码、虚拟主机与统计信息，并明确说自己的视角是“面向服务”而非“面向进程”。它聚焦短期故障发现与排障，不处理计费和点击计量。它可以与系统和应用管理框架配合，也能独立实现。

RFC 2594 并没有在元数据上更新或废止 RFC 2039，但它显示了前一份文档的结构性后果：服务层需要自己的词汇。一次请求不是一条 CPU 样本，一个虚拟主机不是一个可执行文件，查到进程存在也不是收到正确响应。

来源