Serviços de rede de aplicativos : Mecanismos de conteúdo Cisco 500 Series

Compreendendo a análise do log de transação do Content Engine

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Este documento explica os códigos que você vê após ter emitido o comando show transaction-log entries 255 no Cisco Content Engine. Estes códigos de registro são gravados no formato de registro do Squid e cada registro pode ser analisado com a ferramenta de análise de arquivo de registro utilizada nos registros de cache do Squid.

Antes de Começar

Convenções

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Pré-requisitos

Os leitores deste documento devem ser conhecedors do formato de registro do calamar. Ao contrário do formato de Log comum, o formato de registro nativo do calamar foi projetado com estatísticas do Content Engine na mente. Este formato pode ser gerado não somente pelo calamar, mas igualmente pelo Content Engine comercial, tal como ContentFlow, InfoLibria, e NetContent. Para mais informação, refira o índice do proxy da Web do calamarleavingcisco.com .

Componentes Utilizados

As informações neste documento são baseadas nas versões de software e hardware abaixo.

  • todas as liberações do software do Cisco Content Engine (põe em esconderijo anteriormente o Software de Engine)

  • todas as versões do Cisco Content Engine (põe em esconderijo anteriormente o Software de Engine)

Códigos de log padrão

Esta seção explica os códigos de Log padrão.

TCP_HIT

Uma cópia válida do objeto solicitado estava no Content Engine.

TCP_MISS

O objeto solicitado não estava no Content Engine.

TCP_REFRESH_HIT

O objeto estava no Content Engine, mas era velho (velho). Um pedido do If-modified-since foi feito, e uma resposta 304 não alterada foi recebida.

TCP_REF_FAIL_HIT

O objeto estava no Content Engine, mas era velho. A solicitação para validar o objeto falhou, portanto, o objeto antigo foi retornado.

TCP_REFRESH_MISS

O objeto estava no Content Engine, mas era velho. Um pedido do If-modified-since foi feito, e a resposta conteve o índice novo.

TCP_CLIENT_REFRESH

O cliente emitiu uma solicitação com o no-cache pragma.

TCP_IMS_HIT

O cliente emitiu um pedido do If-modified-since, e o objeto estava no Content Engine e ainda fresco.

TCP_IMS_MISS

O cliente emitiu um pedido do If-modified-since para um objeto antigo.

TCP_SWAPFAIL

O objeto foi acreditado para estar no Content Engine, mas não poderia ser alcançado.

TCP_DENIED

Acesso negado a essa solicitação.

UDP_

Este código refere-se a solicitações na porta do Protocolo ICP (3130).

UDP_HIT

Uma cópia válida do objeto solicitado estava no Content Engine.

UDP_HIT_OBJ

Uma cópia válida do objeto solicitado estava no Content Engine, mas os dados do objeto eram pequenos bastante ser enviados no pacote de resposta do User Datagram Protocol (UDP). Salvar o pedido do Transmission Control Protocol (TCP).

UDP_MISS

O objeto solicitado não estava no Content Engine.

UDP_DENIED

Acesso negado a essa solicitação.

UDP_INVALID

Uma solicitação inválida foi recebida.

UDP_RELOADING

O pedido ICP foi recusado porque o Content Engine é ocupado recarregar seus metadata.

ERR_

Este código refere vários tipos de erros para pedidos do HTTP.

Códigos de dados de hierarquia

Esta seção explica os códigos de dados hierárquicos.

DIRECT

O objeto foi solicitado a partir do servidor de origem.

FIREWALL_IP_DIRECT

O objeto foi pedido do servidor de origem porque o endereço IP de Um ou Mais Servidores Cisco ICM NT do host de origem é dentro de seu Firewall.

FIRST_PARENT_MISS

O objeto foi pedido do Content Engine do pai com o Round-Trip Time tornado mais pesado o mais rápido.

FIRST_UP_PARENT

O objeto foi pedido do primeiro pai disponível em sua lista.

LOCAL_IP_DIRECT

O objeto foi solicitado a partir do servidor de origem porque o endereço IP do host de origem era compatível com sua lista local_ip.

SIBLING_HIT

O objeto foi pedido de um Content Engine do irmão, que respondessem com um UDP_HIT.

NO_DIRECT_FAIL

O objeto não poderia ser pedido devido às restrições de firewall, e nenhum Content Engine do pai estava disponível.

NO_PARENT_DIRECT

O objeto foi pedido do servidor de origem porque nenhum Content Engine do pai existe para a URL.

PARENT_HIT

O objeto foi pedido de um Content Engine do pai, que respondessem com um UDP_HIT.

SINGLE_PARENT

O objeto foi pedido do único Content Engine do pai apropriado para esta URL.

SOURCE_FASTEST

O objeto foi pedido do servidor de origem porque a resposta source_ping chegou primeiramente.

PARENT_UDP_HIT_OBJ

O objeto foi recebido em uma resposta UDP_HIT_OBJ de um Content Engine do pai.

SIBLING_UDP_HIT_OBJ

O objeto foi recebido em uma resposta UDP_HIT_OBJ de um Content Engine do irmão.

PASSTHROUGH_PARENT

O vizinho ou o proxy definido na opção de configuração passthrough_proxy foi utilizado.

SSL_PARENT_MISS

O vizinho ou o proxy definido na opção ssl_proxy config foi utilizado.

DEFAULT_PARENT

Nenhuma pergunta ICP foi enviada a todo o Content Engine do pai. Este principal foi escolhido porque foi marcado como padrão no arquivo config.

ROUNDROBIN_PARENT

Nenhuma pergunta ICP foi recebida de todo o Content Engine do pai. Este pai foi escolhido já que foi marcado como padrão no arquivo de configuração, e ele continha a menor contagem de uso de Rodízio (Round Robin).

CLOSEST_PARENT_MISS

Esse pai foi selecionado porque incluía a medida de Round-Trip Time (RTT) mais baixa até o servidor de origem. Isto aparece somente com um query_icmp na opção ajustada no arquivo de configuração.

CLOSEST_DIRECT

O objeto foi buscado diretamente do servidor de origem porque este Content Engine mediu um RTT mais baixo do que algum do Content Engine do pai.


Informações Relacionadas


Document ID: 12563