Resumen

  • RFC 2039 definió un modelo operacional para hardware, sistema, procesos, dependencias y capacidad, y otro de servicio para lo que ocurre con las solicitudes y respuestas de los clientes web.
  • Al imaginar tres dominios virtuales sobre un solo equipo, mostró que servicio, proceso y máquina no forman una correspondencia fija y que ningún inventario del host basta para explicar la experiencia del cliente.

Una CPU desahogada puede convivir con una página dinámica rota. Un proceso vivo puede depender de una base caída. Incluso una parte del sitio puede responder mientras otro dominio virtual, alojado en la misma máquina, deja de hacerlo. No hay contradicción: cada señal describe una capa distinta.

RFC 2039 apareció en noviembre de 1996 como documento Informational, no como estándar de Internet. Había sido solicitado después del BOF HTTP-MIB celebrado durante la 35.ª reunión del IETF en Los Ángeles. Su pregunta era práctica: ¿hasta dónde servían las MIB existentes para administrar servidores del World Wide Web?

La respuesta comenzó dividiendo el objeto administrado. El modelo operacional veía un ordenador: hardware, disco, sistema operativo, software servidor y consumo de recursos. Interesaban CPU, almacenamiento, red, dependencias entre aplicaciones, errores, planificación de capacidad y el alcance de una parada o reconfiguración.

El modelo de servicio trataba el servidor como una caja negra que recibe peticiones web y devuelve respuestas. Interesaban el uso y el rendimiento del servicio de recuperación, los documentos estáticos y dinámicos, sus permisos y la situación de las aplicaciones que generaban el contenido.

Ambas perspectivas se necesitaban, pero podían implantarse por separado. Eso evitaba confundir una señal válida con una conclusión excesiva. Que el host esté disponible no demuestra que el servicio correcto responda; que todavía haya respuestas no demuestra que la base operacional tenga margen suficiente.

El hueco entre tablas

El RFC revisó MIB-II, Host Resources MIB, Network Services Monitoring MIB y los trabajos de Application MIB. Encontró información útil sobre sistema, interfaces, procesadores, almacenamiento, dispositivos, software instalado y ejecutándose, aplicaciones de red y asociaciones activas. No presentó el pasado como un vacío instrumental.

Sin embargo, consideró ortogonales las pilas orientadas al host y las orientadas al servicio. Las primeras cubrían buena parte de los requisitos operacionales. Network Services Monitoring ofrecía una porción del modelo de servicio. Ninguna unía por completo el resultado web con los componentes que lo producían.

La prueba mental de los tres dominios virtuales aclara por qué. Un solo programa podía servirlos todos, o cada dominio podía tener su proceso. Una respuesta dinámica podía necesitar un gateway y una base; una página estática, sólo un archivo. Saber que el binario estaba ejecutándose no identificaba el dominio afectado ni lo que había transmitido. Saber que un servicio tenía asociaciones no señalaba necesariamente el ejecutable, la configuración o la dependencia que debía repararse.

La relación entre capas exigía, por tanto, más que un puntero. Había que mantener el mapa de servicio a procesos, archivos y aplicaciones auxiliares, además de instrumentar la actividad propia del Web.

Dos listas de requisitos, dos verdades operativas

Para el modelo operacional, RFC 2039 pedía medir CPU, disco y red; describir dependencias; normalizar la generación de errores; conservar historia para capacidad; y estructurar datos de actividad que solían quedar en logs. Un reinicio sólo era correcto si el sistema de gestión entendía qué servicios compartían aquel componente.

Para el modelo de servicio, pedía observar uso y desempeño de la recuperación, documentos y permisos, fuentes estáticas y dinámicas, y el estado de gateways o bases que producían información. Incluía configuración central, arranque, parada, rotación de logs e indicación de calidad del servicio.

No son resultados medidos. El RFC no informa de adopción, mejora de rendimiento ni reducción de fallos; tampoco define objetivos de servicio contemporáneos. El borrador, la lista de correo y la implementación de muestra que menciona son señales de trabajo, no pruebas de despliegue. La seguridad quedó fuera de su análisis.

RFC 2594 llevó en 1999 la vertiente de servicio a una MIB concreta. Modeló servicios WWW, acciones de transferencia de documentos, solicitudes, respuestas, códigos de estado, hosts virtuales y estadísticas. Declaró expresamente una mirada orientada al servicio, no al proceso, destinada a detección y diagnóstico a corto plazo y no a contabilidad o medición de visitas. No actualizó ni dejó obsoleto formalmente RFC 2039; sí confirmó que una petición web requería vocabulario distinto del inventario de procesos.

Fuentes