Referência de métricas, dimensões e filtros da análise

O número médio de transações, o que significa solicitações de proxy da API, por segundo. Se você tiver um número relativamente baixo de transações durante o período, o número médio de transações por segundo poderá parecer ser zero nos relatórios personalizados da IU se o número for menor que duas casas decimais.

Sintaxe de API: tps

O número de solicitações de API bem-sucedidas que usam o cache de resposta em vez da resposta do serviço de destino.

Sintaxe de API: sum(cache_hit)

Retorna o número de elementos no cache L1 (na memória) por transação em um determinado período. Por exemplo, se você escolher max no período de um dia e, nesse dia, o maior número de elementos no cache será 12 para uma transação específica, a contagem será 12. Para avg, se houver três transações no período consultado, e as contagens de cache forem 5, 6 e 7, a média será 6. O cache L1 é o cache na memória, e não o banco de dados L2, conforme descrito em elementos internos do cache.

Sintaxe de API: avg(ax_cache_l1_count)

É o número total de erros de política durante o período especificado.

Os erros de política geralmente ocorrem devido ao design. Por exemplo, a política "Verificar chave de API" gera um erro quando uma chave de API inválida é passada na solicitação, e uma política "Spike Arrest" gera um erro se o número de chamadas de API exceder o limite definido na política. Portanto, essa métrica é útil para encontrar possíveis pontos problemáticos nas suas APIs. Por exemplo, as métricas policy_error, agrupadas pela dimensão developer_app, podem ajudar você a descobrir que uma chave de API ou um token OAuth expirou para um determinado aplicativo, ou você pode descobrir que um proxy de API específico está gerando muitos erros do controle de pico fazendo com que o limite do controle de pico do proxy não leve em conta o aumento no tráfego de feriados.

Um erro de política será registrado nas análises somente se o erro resultar em uma falha de proxy da API. Por exemplo, se o atributo continueOnError de uma política for definido como true, o proxy da API continuará processando uma solicitação, mesmo se a política falhar. Nesse caso, um erro de política não é registrado na análise.

A dimensão "Nome da política em erro (ax_execution_fault_policy_name)" é útil para agrupar erros de política por nome de política.

Uma falha de destino (como 404 ou 503) não conta como uma falha de política. Isso conta como falhas do proxy de API (is_error).

Sintaxe de API: sum(policy_error)

O número total de vezes que os proxies da API falharam durante o período especificado. A falha de proxy pode ocorrer quando uma política falha ou quando há uma falha no ambiente de execução, como 404 ou 503 do serviço de destino.

A dimensão do Proxy (apiproxy) é útil para agrupar falhas de proxy da API por proxy.

Sintaxe de API: sum(is_error)

O tempo (médio, mínimo ou máximo), em milissegundos, que o Edge usa para processar as solicitações recebidas. A hora começa quando a solicitação atinge Edge e terminar quando ele encaminha a solicitação para o serviço de destino.

Ao usar dimensões diferentes, você pode examinar as latências de processamento de solicitações por proxy da API, aplicativo do desenvolvedor, região etc.

Sintaxe de API: max(request_processing_latency)

O tamanho do payload da solicitação recebido pelo Edge, em bytes.

Sintaxe de API: avg(request_size)

O número total de vezes que uma política de cache de resposta foi executada durante um determinado período.

Como a política de cache de resposta está anexada em dois locais em um proxy de API (uma vez na solicitação e uma vez na resposta), ela geralmente é executada duas vezes em uma chamada de API. Um "get" de cache e um "put" de cache contam como uma execução.

No entanto, a execução do cache de resposta será 0 se o elemento <SkipCacheLookup> na política for avaliado como verdadeiro (na solicitação) e 0 se o elemento <SkipCachePopulation> na política avalia como verdadeiro (na resposta).

Na Ferramenta de rastreamento, clique no ícone do cache de resposta em uma chamada de API executada e veja a variável de fluxo responsecache.executed para ver se houve ou não uma execução de cache (um valor de 1).

Sintaxe de API: sum(ax_cache_executed)

O tempo (médio, mínimo ou máximo), em milissegundos, que o Edge usa para processar respostas da API. O horário começa quando o proxy da API recebe a resposta do serviço de destino e termina quando a Apigee encaminha a resposta para o autor da chamada original.

Usando dimensões diferentes, você pode examinar as latências de processamento de resposta por proxy de API, região e assim por diante.

Sintaxe de API: min(response_processing_latency)

O tamanho do payload da resposta retornado ao cliente em bytes.

Sintaxe de API: max(response_size)

É o número total de respostas 5xx do serviço de destino. Esses são erros de serviço de destino não causados pela Apigee.

Sintaxe de API: sum(target_error)

É o tempo (soma, média, mínimo ou máximo) em milissegundos, para o servidor de destino responder a uma chamada. Essa métrica informa o desempenho dos servidores de destino. O horário começa quando o Edge encaminha uma solicitação ao serviço de destino e termina quando o Edge recebe a resposta.

Observe que, se uma chamada de API retornar uma resposta do cache (usando a política de cache de resposta, por exemplo), a chamada nunca alcançará o serviço de destino e nenhuma métrica de tempo de resposta será registrada.

Sintaxe de API: avg(target_response_time)

A quantidade de tempo (soma, média, mínimo ou máximo) milissegundos, a partir do momento em que o Edge recebe uma solicitação de um cliente e O Edge envia a resposta de volta ao cliente. O tempo inclui a sobrecarga da rede (como o tempo que leva balanceadores de carga e roteadores para fazer seu trabalho), latência do processamento da solicitação latência do processamento da resposta e tempo de resposta do destino (se a resposta for exibida do serviço de destino em vez do cache).

Ao usar dimensões diferentes, é possível examinar as latências de processamento por proxy da API, aplicativo do desenvolvedor, região etc.

Sintaxe de API: avg(total_response_time)

O número total de chamadas de API processadas pelo Edge no período especificado.

Use as dimensões para agrupar as contagens de tráfego das maneiras mais significativas para você.

Sintaxe de API: sum(message_count)

O nome do produto da API que contém os proxies da API que estão sendo chamados. Para conseguir essa dimensão, os aplicativos de desenvolvedor que fazem as chamadas precisam estar associados a um ou mais produtos de API que contenham os proxies de API, e os proxies que estão sendo chamados precisam verificar uma chave de API ou um token OAuth. enviados com a chamada de API. A chave ou o token está associado a um produto de API. Para mais informações, consulte Antes de mais nada: como gerar dados de análise completos.

Se os critérios acima não forem atendidos, você verá o valor "(não definido)". Consulte também O que significa um valor de entidade de análise "(não definido)"?.

A chave que contém o valor do cache de resposta que foi acessado. Para mais informações sobre como a chave é criada para o cache de resposta, consulte Política de cache de resposta.

Na Ferramenta de rastreamento, quando você seleciona uma política de cache de resposta que lê ou grava no cache, é possível ver esse valor no responsecache.cachekey variável de fluxo.

O nome do cache que contém as chaves/valores usados pela política do Cache de resposta, com o prefixo orgName__envName__. Por exemplo, se a organização for "foo", o ambiente for "test" e o nome do cache for "myCache", o ax_cache_name será foo__test__myCache.

Na ferramenta de rastreamento, ao selecionar uma política de cache de resposta, você pode ver esse valor na variável de fluxo responsecache.cachename.

O nível de cache ("L1" na memória ou "L2" banco de dados) usado para recuperar o cache de resposta. Essa dimensão também mostra "CACHE_MISS" quando a resposta é entregue a partir do destino em vez do cache (e o cache de resposta foi atualizado com a resposta de destino), ou quando uma chave de cache na solicitação é inválida. As chaves de cache são limitadas a 2 KB.

Na ferramenta de rastreamento, ao selecionar a política de cache de resposta, é possível ver esse valor na variável de fluxo responsecache.cachesource.

Para mais informações sobre níveis de cache, consulte Elementos internos de cache.

A chave do consumidor (chave de API) do app do desenvolvedor que faz as chamadas de API, transmitidas na solicitação como chaves de API ou incluídas nos tokens OAuth.

Para ter essa dimensão, os proxies que recebem chamadas precisam ser configurados para verificar uma chave de API ou um token OAuth válidos. Os apps do desenvolvedor recebem chaves de API, que podem ser usadas para gerar tokens OAuth quando os aplicativos estiverem registrados no Edge. Para mais informações, consulte Antes de mais nada: como gerar dados de análise completos.

Se os critérios acima não forem atendidos, você verá o valor "(não definido)". Veja também O que significa um valor de entidade de análise "(não definido)"?.

O app de desenvolvedor registrado no Edge fazendo chamadas de API.

Para conseguir essa dimensão, os aplicativos precisam estar associados a um ou mais produtos da API que contenham os proxies de API que estão sendo chamados. Além disso, é necessário que os proxies verifiquem a chave de API ou o token OAuth enviados com a chamada de API. A chave ou o token identifica o app do desenvolvedor. Para Para mais informações, consulte Primeiras etapas: como gerar dados de análise completos.

Se os critérios acima não forem atendidos, você verá o valor "(não definido)". Veja também O que significa um valor de entidade de análise "(não definido)"?.

O e-mail dos desenvolvedores registrados no Edge cujo app fez as chamadas de API.

Para conseguir essa dimensão, os desenvolvedores precisam ter apps associados a um ou mais produtos de API que contenham os proxies de API que estão sendo chamados, e os proxies precisam verificar uma chave de API ou um token OAuth enviado com a chamada de API. A chave ou o token identifica o desenvolvedor app. Para mais informações, consulte Primeiras etapas: como gerar dados de análise completos.

Se os critérios acima não forem atendidos, você verá o valor "(não definido)". Veja também O que significa um valor de entidade de análise "(não definido)"?.

O ID exclusivo do desenvolvedor gerado pelo Edge na forma de org_name@@@org_name.

Para conseguir essa dimensão, os desenvolvedores precisam ter apps associados a um ou mais produtos de API que contenham os proxies de API sendo chamados. Além disso, é necessário que os proxies verifiquem uma chave de API ou um token OAuth enviados com as chamadas de API. A chave ou o token identifica o desenvolvedor. Para mais informações, consulte Primeiras etapas: como gerar dados de análise completos.

Se os critérios acima não forem atendidos, você verá o valor "(não definido)". Veja também O que significa um valor de entidade de análise "(não definido)"?.

O código de falha do erro. Por exemplo: messaging.adaptors.http.flow.GatewayTimeout

O flow nomeado em um proxy de API que gerou um erro. Por exemplo, "PreFlow", "PostFlow" ou o nome de um fluxo condicional que você criou.

Observe que o nome completo a ser usado na API de gerenciamento é ax_execution_fault_flow_name, sem uma quebra de linha.

Onde não ocorreram erros, você verá o valor "(não definido)".

O nome do fluxo do proxy da API indica que gerou erros, como "PROXY_REQ_FLOW" ou "TARGET_RESP_FLOW".

Observe que o nome completo a ser usado na API de gerenciamento é ax_execution_fault_flow_state, sem quebra de linha.

O nome da política que gerou um erro e causou falha na chamada da API.

Observe que o nome completo a ser usado na API de gerenciamento é ax_execution_fault_policy_name, sem quebra de linha.

Se uma política gerar um erro, mas o atributo raiz da política continueOnError estiver definido como true, o fluxo do proxy da API continuará sem falha, e a falha da política não será contada nessa dimensão.

O caminho base configurado no ProxyEndpoint da API. O caminho base não inclui o domínio e a parte da porta do URL do proxy de API. Por exemplo, se o URL base de um proxy de API for https://apigeedocs-test.apigee.net/releasenotes/, o caminho base será /releasenotes.

O valor também é armazenado na variável de fluxo proxy.basepath.

O caminho do recurso adicionado ao caminho base do proxy da API. Por exemplo, se o URL base de um proxy de API for https://apigeedocs-test.apigee.net/hello/ e uma chamada for feita para https://apigeedocs-test.apigee.net/hello/json, o caminho de sufixo será /json.

Se nenhum sufixo de caminho for usado, o valor ficará vazio.

O valor também é armazenado na variável de fluxo proxy.pathsuffix.

Contém o endereço IP do cliente de origem. O valor da dimensão ax_resolved_client_ip é calculado a partir dos valores nas dimensões ax_true_client_ip e x_forwarded_for_ip.

Observe que ao usar produtos de roteamento como a Akamai para capturar os endereços IP verdadeiros dos clientes, o IP do cliente é transmitido para o Edge no cabeçalho HTTP True-Client-IP, que é usada para definir a dimensão ax_true_client_ip.

O valor da dimensão ax_resolved_client_ip é calculado da seguinte maneira:

1. Se ax_true_client_ip não for nulo e não contiver um endereço IP local, defina ax_resolved_client_ip como ax_true_client_ip.
2. Caso contrário, defina ax_resolved_client_ip como o primeiro endereço IP não local em x_forwarded_for_ip.
3. Se ax_true_client_ip e x_forwarded_for_ip tiverem apenas endereços IP locais, depois defina ax_resolved_client_ip como o primeiro endereço IP local em x_forwarded_for_ip.
4. Se ax_true_client_ip e x_forwarded_for_ip forem nulos, defina ax_resolved_client_ip como (not set).
5. Se ax_true_client_ip for um endereço IP local e x_forwarded_for_ip for nulo, defina ax_resolved_client_ip como (not set).

A versão do sistema operacional do dispositivo que está fazendo a chamada.

É útil usá-lo como uma segunda dimensão de "detalhamento" com a família do SO (ax_ua_os_family) para ver as versões dos sistemas operacionais.

O endereço IP do cliente que fez a chamada, armazenado na variável de fluxo proxy.client.ip. Geralmente, esse é o endereço X-Forwarded-For da ligação recebida, que é o endereço IP de borda recebido do último handshake TCP externo. Pode ser o cliente que faz a chamada ou um balanceador de carga. Quando há vários IPs no cabeçalho X-Forwarded-For, esse é o último IP listado.

Ao usar produtos de roteamento como a Akamai para capturar os endereços IP verdadeiros dos clientes, os IPs do cliente são transmitidos para o Edge no cabeçalho HTTP True-Client-IP. Essa dimensão captura esses IPs de clientes verdadeiros desse cabeçalho.

Para determinar o endereço IP original do cliente, acessado pela ax_resolved_client_ip dimensão, o Edge usa a ax_true_client_ip e a x_forwarded_for_ip.

O caminho do recurso (sem incluir o domínio) para o serviço de destino, excluindo parâmetros de consulta.

Por exemplo, o destino da amostra http://mocktarget.apigee.net da Apigee inclui vários recursos, incluindo /user, que retorna uma saudação. Independentemente de como o proxy da API chama http://mocktarget.apigee.net/user, o request_path é /user.

O caminho do recurso (não incluindo o domínio) para o serviço de destino, incluindo parâmetros de consulta.

Por exemplo, o destino de amostra da Apigee http://mocktarget.apigee.net inclui vários recursos, incluindo /user?user={name} e parâmetro de consulta para retornar uma saudação personalizada ao nome fornecido. Independentemente de como o proxy da API chama http://mocktarget.apigee.net/user?user=Dude, o request_uri é /user?user=Dude.

O nome do user agent ou agente de software usado para fazer a chamada de API. Exemplos:

• Um Pixel XL com uma chamada do Chrome: Mozilla/5.0 (Linux; Android 7.1.2; Pixel XL Build/NHG47N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.92 Mobile Safari/537.36
• Um iPad fazendo uma chamada pelo Chrome: Mozilla/5.0 (iPad; CPU OS 10_2 like Mac OS X) AppleWebKit/602.1.50 (KHTML, like Gecko) CriOS/54.0.2840.91 Mobile/14C92 Safari/602.1
• cURL from a terminal: curl/7.51.0

A versão do user agent.

É útil usá-lo como uma segunda dimensão de "detalhamento" com a família de user agent (ax_ua_agent_family) para receber a versão da família do agente.

O caminho do recurso (sem incluir o domínio) no serviço de destino, exceto os parâmetros de consulta, que são definidos no <TargetEndpoint> do proxy.

Por exemplo, digamos que um proxy de API chame o seguinte destino:

<TargetEndpoint name="default">
...
<HTTPTargetConnection>
  <URL>http://mocktarget.apigee.net/user?user=Dude</URL>
</HTTPTargetConnection>

Neste exemplo, o target_basepath é /user.

Se o destino for o seguinte:

<TargetEndpoint name="default">
...
<HTTPTargetConnection>
  <URL>http://mocktarget.apigee.net</URL>
</HTTPTargetConnection>

o target_basepath seria nulo.

Na Ferramenta de rastreamento, quando você selecionar o ícone AX no final do diagrama de fluxo, a target.basepath variável de fluxo é mapeada para a dimensão target_basepath.

O código de status de resposta HTTP retornado pelo serviço de destino para o proxy de API, como 200, 404, 503 e assim por diante.

Um valor "nulo" significa que a solicitação nunca chegou ao serviço de destino. Isso ocorre quando a resposta é veiculada pela política do cache de resposta ou quando há uma falha no processamento da solicitação.

Isso é diferente da dimensão Código de status da resposta (response_status_code).

O URL completo do serviço de destino definido TargetEndpoint do proxy de API.

<TargetEndpoint name="default">
...
<HTTPTargetConnection>
  <URL>http://mocktarget.apigee.net/user?user=Dude</URL>
</HTTPTargetConnection>

Neste exemplo, o target_url é http://mocktarget.apigee.net/user?user=Dude.

O URL também pode ser modificado durante o processamento do proxy da API com a variável de fluxo target.url.

No proxy encadeamento e ao usar scripts destinos (Node.js), o target_url no proxy de chamada será nulo.

A lista de endereços IP no cabeçalho X-Forwarded-For.

Para determinar o endereço IP original do cliente, acessado pela ax_resolved_client_ip dimensão, o Edge usa a ax_true_client_ip e a x_forwarded_for_ip.

Com base em um relógio de 24 horas, a hora de dois dígitos em que as chamadas de API foram feitas. Por exemplo, para chamadas de API feitas na hora entre 22h e 23h, a ax_hour_of_day seria 22.

O valor de hora é em UTC.