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

Você está vendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X.
informações

Este tópico é uma referência para métricas, dimensões e filtros de análise. Para mais informações sobre como usá-los, consulte a visão geral da análise de API.

Este tópico mostra os nomes das métricas e dimensões conforme elas aparecem na interface do usuário e conforme é necessário usá-las em chamadas de API.

Métricas

Veja a seguir as métricas da API que você pode recuperar em relatórios personalizados e chamadas de API de gerenciamento.

Nome dos relatórios personalizados Nome a ser usado na API de gerenciamento Funções Descrição
Média de transações por segundo TPS Nenhum

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

ocorrência em cache cache_hit soma

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)

Contagem de elementos do cache L1 ax_cache_l1_count média, mínima, máximo

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)

Erros de política policy_error soma

É 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)

Erros de proxy is_error soma

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)

Latência no processamento da solicitação request_processing_latency média, mínima, máximo

O tempo (médio, mínimo ou máximo), em milissegundos, que o Edge leva para processar as solicitações recebidas. O tempo começa quando a solicitação chega ao Edge e termina quando o Edge 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)

Tamanho da solicitação request_size soma, média, mínimo, máximo

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

Sintaxe de API: avg(request_size)

Cache de resposta executado ax_cache_executed soma

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)

Latência de processamento de respostas response_processing_latency média, mínima, máximo

O tempo (médio, mínimo ou máximo), em milissegundos, que o Edge leva para processar as 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)

Tamanho da resposta response_size soma, média, mínimo, máximo

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

Sintaxe de API: max(response_size)

Erros de destino target_error soma

É 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)

Tempo de resposta do destino target_response_time soma, média, mínimo, máximo

É 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 tempo começa quando o Edge encaminha uma solicitação para o 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)

Tempo total de resposta total_response_time soma, média, mínimo, máximo

O tempo (soma, média, mínimo ou máximo), em milissegundos, entre o momento em que o Edge recebe uma solicitação de um cliente e até o momento em que o Edge envia a resposta de volta a ele. 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)

Tráfego message_count ponderada

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)

Dimensões

As dimensões permitem visualizar métricas em agrupamentos significativos. Por exemplo, ver as contagens totais de tráfego se torna muito mais eficiente quando você as visualiza para cada app de desenvolvedor ou proxy de API.

Veja a seguir as dimensões fornecidas pela Apigee prontas para uso. Além disso, você pode criar suas próprias dimensões, conforme descrito em Analisar o conteúdo da mensagem da API usando análises personalizadas.

Nome dos relatórios personalizados Nome a ser usado na API de gerenciamento Descrição
Entidades da Apigee
Token de acesso access_token O token de acesso OAuth do usuário final do aplicativo.
Produto de API api_product

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)"?.

Chave de cache ax_cache_key

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.

Nome do cache ax_cache_name

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.

Origem do cache ax_cache_source

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.

ID do cliente client_id

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 apps estão 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)"?.

Aplicativo do desenvolvedor developer_app

O app do desenvolvedor registrado no Edge que faz 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 mais informações, consulte Primeiras coisas: 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)"?.

E-mail do desenvolvedor developer_email

O e-mail dos desenvolvedores registrados na Edge para o qual o 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 app do desenvolvedor. Para mais informações, consulte Primeiras coisas: 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)"?.

ID do desenvolvedor: desenvolvedor

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

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 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)"?.

Ambiente ambiente O ambiente de borda em que os proxies da API são implantados. Por exemplo, "test" ou "prod".
Código de falha em caso de erro ax_edge_execution_fault_code

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

Nome do fluxo no erro ax_execution_fault
  _flow_name

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)".

Recurso de fluxo flow_resource Apenas para uso da Apigee. Veja esta postagem na Comunidade se tiver curiosidade.
Estado do fluxo em caso de erro ax_execution_fault
  _flow_state

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.

ID do fluxo do gateway gateway_flow_id Conforme as chamadas de API se movem pelo Edge, cada chamada recebe o próprio ID de fluxo de gateway. Exemplo: rrt329ea-12575-114653952-1. O ID do fluxo de gateway é útil para distinguir as métricas em situações de alto TPS em que outras dimensões, como organização, ambiente e carimbo de data/hora, são idênticas nas chamadas.
Organização organização A organização de borda em que os proxies da API são implantados.
Erro: nome da política ax_execution_fault
  _policy_name

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.

Proxy apiproxy O nome da máquina (não o nome de exibição) de um proxy de API.
Caminho base de proxy proxy_basepath

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.

Sufixo do caminho do proxy proxy_pathsuffix

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.

Revisão de proxy apiproxy_revision O número de revisão do proxy de API que processou as chamadas de API. Isso não significa necessariamente a revisão mais recente de um proxy de API. Se um proxy de API tiver 10 revisões, a oitava revisão poderá ser implantada. Além disso, uma API pode ter várias revisões implantadas, desde que elas tenham caminhos base diferentes, conforme descrito em Como implantar proxies na IU.
IP do cliente resolvido ax_resolved_client_ip

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 verdadeiros endereços IP dos clientes, o IP do cliente é transmitido para o Edge no cabeçalho HTTP True-Client-IP, que é então usado 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 contiverem apenas endereços IP locais, 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).
Código de status da resposta response_status_code O código de status da resposta HTTP encaminhado da Apigee para o cliente, como 200, 404, 503 e assim por diante. No Edge, o código de status de resposta do destino pode ser substituído por políticas como Atribuir mensagem e Informar falha. Por isso, essa dimensão pode ser diferente do Código de resposta do destino (target_response_code).
Host virtual virtual_host O nome do host virtual em que a chamada de API foi feita. Por exemplo, as organizações têm dois hosts virtuais por padrão: default (http) e secure (https).
Entrada/Cliente
Endereço IP do cliente. client_ip Endereço IP do sistema que chega ao roteador, como o cliente original (proxy_client_ip) ou um balanceador de carga. Quando há vários IPs no cabeçalho X-Forwarded-For, esse é o último IP listado.
Categoria do dispositivo ax_ua_device_category O tipo de dispositivo a partir do qual a chamada de API foi feita, como "Tablet" ou "Smartphone".
SO Família ax_ua_os_family A família do sistema operacional do dispositivo que está fazendo a chamada, como "Android" ou "iOS".
Versão do SO ax_ua_os_version

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.

IP do cliente do proxy proxy_client_ip

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 chamada de entrada, que é o endereço IP que a borda recebeu do último handshake de 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.

IP do cliente indicado ax_true_client_ip

Ao usar produtos de roteamento, como a Akamai, para capturar os verdadeiros endereços IP de clientes, os IPs de clientes 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 dimensão ax_resolved_client_ip, o Edge usa as dimensões ax_true_client_ip e x_forwarded_for_ip.

Caminho da solicitação request_path

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.

URI da solicitação request_uri

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.

Solicitar Verbo request_verb O verbo de solicitação HTTP nas solicitações de API, como GET, POST, PUT, DELETE.
User agent useragent

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
Família do user agent ax_ua_agent_family A família do user agent, como "Chrome Mobile" ou "cURL".
Tipo de user agent ax_ua_agent_type O tipo de user agent como "Browser", "Mobile Browser", "Library" e assim por diante.
Versão do user agent ax_ua_agent_version

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.

Saída/destino
Caminho base de destino target_basepath

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.

Host de destino target_host O host do serviço de destino. Por exemplo, se um proxy de API chamar http://mocktarget.apigee.net/help, o target_host será mocktarget.apigee.net.
Endereço IP de destino target_ip O endereço IP do serviço de destino que retorna a resposta para o proxy da API.
Código de resposta de destino target_response_code

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).

URL de destino target_url

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 encadeamento de proxy e ao usar destinos de script (Node.js), o target_url no proxy de chamada será nulo.

X encaminhado para x_forwarded_for_ip

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

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

Tempo
Dia da semana ax_day_of_week A abreviação de três letras do dia da semana em que a chamada de API foi feita. Por exemplo, Seg, Ter, Qua.
Mês ax_month_of_year O mês numérico em que as chamadas de API foram feitas. Por exemplo, "03" para março.
Hora do dia ax_hour_of_day

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.

Time Zone ax_geo_timezone Os nomes comuns dos fusos horários em que as chamadas de API foram feitas, como América/Nova York e Europa/Dublin.
Semana do mês ax_week_of_month A semana numérica do mês. Por exemplo, para chamadas de API feitas na terceira semana de um mês, o ax_week_of_month é 3.
Local
Cidade ax_geo_city A cidade de onde as chamadas da API foram feitas.
Continente ax_geo_continent O código de duas letras do continente de que as chamadas da API foram feitas. Por exemplo, NA para a América do Norte.
País ax_geo_country O código de duas letras do país de onde as chamadas da API foram feitas. Por exemplo, US para Estados Unidos.
Região geográfica ax_geo_region O código hifenizado para a região geográfica, como STATE-COUNTRY. Por exemplo, WA-US para Washington-Estados Unidos.
Região ax_dn_region Nome do data center da Apigee em que os proxies da API são implantados, como us-east-1.
Monetização
Mensagem de ignorar transação da Mint x_apigee_mint_tx_ignoreMessage Sinalização que especifica se mensagens relacionadas à monetização devem ser ignoradas. Defina como false para todas as organizações que geram receita.
Status da transação de cunhar x_apigee_mint_tx_status Status de uma solicitação de monetização, como sucesso, falha, inválido ou nenhum.

Filtros

Os filtros permitem limitar os resultados a métricas com características específicas. Veja a seguir alguns exemplos de filtro. Use nomes no estilo de API e dimensão ao definir filtros.

Retorna métricas para proxies de API com os nomes de livros ou músicas:

filter=(apiproxy in 'books','music')

Retorna métricas para proxies de API com nomes que começam com "m":

filter=(apiproxy like 'm%')

Retorna métricas para proxies de API com nomes que não começam com "m":

filter=(apiproxy not like 'm%')

Retorna métricas de chamadas de API com códigos de status de resposta entre 400 e 599:

filter=(response_status_code ge 400 and response_status_code le 599)

Retorna métricas para chamadas de API com código de status de resposta 200 e código de resposta de destino 404:

filter=(response_status_code eq 200 and target_response_code eq 404)

Retorna métricas de chamadas de API com um código de status de resposta 500:

filter=(response_status_code eq 500)

Retorna métricas de chamadas de API que não resultaram em erros:

filter=(is_error eq 0)

Veja a seguir os operadores que podem ser usados para criar filtros de relatório.

Operador Descrição
in Incluir na lista
notin Excluir da lista
eq Igual a ==
ne Diferente de !=
gt Maior que >
lt Menor que <
ge Maior que ou igual a >=
le Menor que ou igual a <=
like Retorna verdadeiro se o padrão de string corresponder ao padrão fornecido.
not like Retorna falso se o padrão de string corresponder ao padrão fornecido.
similar to Retorna verdadeiro ou falso, dependendo do padrão corresponder à string fornecida. É semelhante a like, exceto que interpreta o padrão usando a definição padrão do SQL de uma expressão regular.
not similar to Retorna falso ou verdadeiro dependendo se o padrão corresponde à string fornecida. É semelhante a not like, exceto por interpretar o padrão usando a definição padrão SQL de uma expressão regular.
and Permite que você use a lógica "e" para incluir mais de uma expressão de filtro. O filtro inclui dados que atendam a todas as condições.
or Permite que você use a lógica "ou" para avaliar diferentes expressões de filtro possíveis. O filtro inclui dados que atendem a pelo menos uma das condições.