Resumo

  • O RFC 2039 distinguiu o Modelo Operacional, voltado a hardware, sistema, processos, dependências e capacidade, do Modelo de Serviço, voltado às requisições e respostas percebidas pelo cliente web.
  • Ao colocar três domínios virtuais em um único computador, o documento mostrou que processo, serviço e máquina não têm correspondência fixa e precisam de uma ligação administrada.

Uma máquina com CPU folgada, disco acessível, interface ativa e processo presente pode continuar incapaz de entregar uma página dinâmica. Basta que o gateway ou o banco do qual aquela página depende tenha falhado. A telemetria do host não mentiu; foi a pergunta feita a ela que ultrapassou sua camada.

Publicado em novembro de 1996, o RFC 2039 era Informational e não especificava um padrão da Internet. Surgiu por solicitação do diretor da área de gestão depois do BOF HTTP-MIB na 35ª reunião do IETF, em Los Angeles. Sua contribuição duradoura foi dividir o objeto de gestão.

No Modelo Operacional, o servidor web é um computador: processador, disco, rede, sistema operacional, software servidor, arquivos e processos. A gestão acompanha uso de recursos, dependências, erros e histórico de capacidade, além de entender o alcance de uma parada ou reconfiguração.

No Modelo de Serviço, o interior vira provisoriamente uma caixa-preta. O que importa é o tratamento de pedidos de clientes, o desempenho da recuperação, os documentos estáticos e dinâmicos, suas permissões e o estado das aplicações que produzem conteúdo.

Os dois modelos se complementam sem se substituírem. Um host pode estar saudável enquanto um serviço virtual falha. Um serviço pode continuar respondendo enquanto a margem de disco ou conexões desaparece. São verdades sobre objetos diferentes.

Três domínios, uma máquina, vários arranjos

O RFC examinou MIB-II, Host Resources MIB, Network Services Monitoring MIB e os trabalhos da Application MIB. Já havia dados úteis sobre sistema, interfaces, processadores, armazenamento, software instalado e em execução, aplicações de rede e associações. Boa parte da visão operacional estava coberta; a visão de serviço, apenas em parte.

O limite aparecia em um exemplo simples. Um computador servia três domínios virtuais. Um único processo poderia atender os três, ou haver um processo para cada um. Um documento estático dependeria de um arquivo; um dinâmico poderia atravessar gateway e banco de dados. A tabela de processos confirmaria que o servidor rodava, mas não qual domínio falhara nem o que transmitira. A tabela de serviços separaria domínios e conexões, mas talvez não apontasse o executável ou a dependência a corrigir.

Por isso a relação entre serviço e operação não cabia em um ponteiro universal. Era preciso manter o mapa entre identidades de serviço e componentes, além de instrumentar o comportamento próprio do Web.

Na camada operacional, o RFC pediu CPU, disco e rede, dependências de aplicações, relato padronizado de erros, histórico para capacidade e informação estruturada antes confinada a logs. Na camada de serviço, pediu uso e desempenho da recuperação, atividade e permissão por documento, estado de fontes dinâmicas, configuração central, início, parada, rotação de logs e indicação de qualidade.

Esses itens são requisitos, não resultados. A fonte não mede ganhos, adoção ou redução de falhas. O Internet-Draft, a lista e a implementação de exemplo mencionados registram trabalho em andamento, não implantação. Segurança foi expressamente deixada fora.

Em 1999, o RFC 2594 transformou a perspectiva de serviço numa MIB para serviços WWW. Modelou ações de transferência de documentos, pedidos, respostas, códigos de estado, hosts virtuais e estatísticas. Declarou-se orientado ao serviço, não ao processo, com foco em detecção e diagnóstico de curto prazo, não em contabilidade. Não atualizou nem tornou obsoleto formalmente o RFC 2039; mostrou, porém, por que uma requisição precisava de vocabulário próprio.

Fontes