Кратко

  • RFC 2039 отделил операционную модель — оборудование, ОС, процессы, зависимости и ёмкость — от сервисной модели, описывающей запросы и ответы веб-клиентов.
  • Пример трёх виртуальных доменов на одном компьютере показал, что служба не обязана совпадать с процессом один к одному, поэтому состояние хоста не заменяет карту сервисных зависимостей.

Процессор свободен, диск отвечает, сетевой интерфейс активен, серверный процесс не завершился. Все четыре утверждения могут быть верны в тот момент, когда динамическая страница не открывается: шлюз или база данных, от которых она зависит, уже недоступны. Ошибка возникает не в показаниях, а в попытке применить их к другому объекту.

RFC 2039 вышел в ноябре 1996 года как Informational-документ, а не стандарт Интернета. Его подготовили по запросу руководителя области сетевого управления после BOF HTTP-MIB на 35-й встрече IETF в Лос-Анджелесе. Авторы оценивали применимость существующих стандартных MIB к управлению серверами World Wide Web.

Операционная модель видела в сервере компьютер: аппаратуру, диски, операционную систему, серверное ПО, файлы и процессы. Здесь требовалось измерять загрузку CPU, диска и сети, знать зависимости приложений, унифицировать сообщения об ошибках, хранить историю для планирования ёмкости и понимать последствия остановки либо перенастройки.

Сервисная модель временно превращала внутреннее устройство в чёрный ящик. Её предметом были клиентские запросы и ответы: использование и производительность службы получения документов, статический и динамический контент, права доступа и состояние приложений, создающих динамические данные.

Эти представления дополняют друг друга, но не подменяют. Исправный хост способен нести сломанную виртуальную службу; работающая служба может скрывать быстрое сокращение ресурсного запаса. Это не противоречие, а два разных объекта наблюдения.

Почему три домена не помещаются в таблицу процессов

RFC 2039 рассмотрел MIB-II, Host Resources MIB, Network Services Monitoring MIB и создававшиеся Application MIB. Уже существовали полезные сведения о системе, интерфейсах, процессорах, накопителях, устройствах, установленном и запущенном ПО, сетевых приложениях и соединениях. Операционные требования покрывались во многом, сервисные — лишь частично.

Граница обнаруживалась в сценарии одного компьютера с тремя виртуальными доменами. Их мог обслуживать один процесс либо три разных. Статическому документу мог требоваться только файл, динамическому — ещё шлюз и база. Таблица процессов честно показывала работающий сервер, но не называла отказавший домен и переданные им данные. Таблица служб различала домены и связи, но могла не указать исполняемый файл или нижестоящее приложение для ремонта.

Связь уровней поэтому была не универсальным указателем, а зависящим от реализации отображением. Его требовалось поддерживать и дополнять веб-специфическим инструментированием.

На операционном уровне RFC требовал данные CPU, диска и сети, зависимости приложений, стандартные ошибки, историю ёмкости и структурирование важных сведений из журналов. На сервисном — использование и производительность получения, активность и разрешения документов, состояние динамических источников, централизованную настройку, запуск, остановку, ротацию журналов и признак качества службы.

Это перечень требований, не отчёт об успехе. Источники не измеряют распространение, прирост производительности или снижение числа отказов. Упомянутые Internet-Draft, список рассылки и пример реализации подтверждают работу того времени, но не эксплуатацию. Вопросы безопасности были явно исключены.

В 1999 году RFC 2594 оформил сервисную сторону как Proposed Standard. Он моделировал WWW-службы, действия передачи документов, запросы, ответы, коды состояния, виртуальные хосты и статистику. Документ прямо называл взгляд сервисным, а не процессным, и ограничивал его краткосрочным обнаружением и устранением проблем, не учётом посещений. Формально RFC 2039 он не обновлял и не отменял, но подтвердил необходимость отдельного языка для службы.

Источники