Ver métricas

Version 1.13 (latest)

Versões com suporte:

• v1.13 (mais recente)                        
• v1.12                         
• v1.11
• Lista de versões com suporte

Versões sem suporte:

• v1.10                                      
• v1.9
• v1.8                                         
• v1.7
• v1.6
• v1.5
• v1.4
• v1.3
• v1.2
• v1.1

Neste tópico, você aprenderá como visualizar métricas híbridas da Apigee em um painel do Cloud Operations.

Sobre o produto Operações do Cloud

Para mais informações sobre métricas, painéis e o Cloud Operations, consulte:

• Documentação do Metrics Explorer
• Introdução a alertas
• Como criar gráficos

Como ativar métricas híbridas

Antes de enviar métricas híbridas ao Cloud Operations, é preciso ativar a coleta de métricas primeiro. Consulte Configurar coleta de métricas para este procedimento.

Observação: as métricas do gateway de entrada da Apigee não são compatíveis. Consulte Problemas conhecidos.

Sobre rótulos e nomes de métricas híbridas

Quando ativada, a métrica híbrida preenche automaticamente as métricas do Cloud Operations. O prefixo do nome de domínio das métricas criadas por híbrido é:

apigee.googleapis.com/

Por exemplo, a métrica /proxy/request_count contém o número total de solicitações recebidas por um proxy de API. O nome da métrica no Cloud Operations é, portanto:

apigee.googleapis.com/proxy/request_count

O Cloud Operations permite filtrar e agrupar dados de métricas com base em rótulos. Alguns rótulos são predefinidos e outros são explicitamente adicionados por nuvem híbrida. A seção Métricas disponíveis abaixo lista todas as métricas híbridas disponíveis e todos os rótulos adicionados especificamente a uma métrica que pode ser usada para filtragem e agrupamento.

Como ver métricas

O exemplo a seguir mostra como visualizar métricas no Cloud Operations:

1. Abra o Metrics Explorer do Monitoring em um navegador. Como alternativa, se você já estiver no console do Cloud Operations, selecione Metrics explorer.

2. Em Encontrar tipo de recurso e métrica, localize e selecione a métrica que você quer examinar. Escolha uma métrica específica listada em Métricas disponíveis ou pesquise uma métrica.

3. Selecione a métrica pretendida.
4. Aplique filtros. As opções de filtro para cada métrica estão listadas em Métricas disponíveis.
5. O Cloud Operations exibe o gráfico da métrica selecionada.
6. Clique em Salvar.

Como criar um painel

Os painéis são uma maneira de visualizar e analisar dados de métricas que são importantes para você. O Cloud Operations fornece painéis predefinidos para os recursos e serviços que você usa, e também é possível criar painéis personalizados.

Use um gráfico para exibir uma métrica da Apigee no seu painel personalizado. Com os painéis personalizados, você tem controle total sobre os gráficos exibidos e as configurações. Para mais informações sobre a criação de gráficos, consulte esta página.

O exemplo a seguir mostra como criar um painel no Cloud Operations e adicionar gráficos para visualizar dados de métricas:

1. Abra o Metrics Explorer do Monitoring em um navegador e selecione Painéis.
2. Selecione + Criar painel.
3. Dê um nome ao painel. Por exemplo: Tráfego de solicitação de proxy híbrido.
4. Clique em Confirmar.

5. Para cada gráfico que quiser adicionar ao seu painel, siga estes passos:

   1. No painel, selecione Adicionar gráfico.
   2. Selecione a métrica pretendida conforme descrito acima em Como visualizar métricas.
   3. Preencha a caixa de diálogo para definir seu gráfico.
   4. Clique em Salvar. O Cloud Operations exibe os dados da métrica selecionada.

Métricas disponíveis

As tabelas a seguir listam as métricas para analisar o tráfego de proxy. Para mais informações sobre cada métrica da Apigee, consulte Métricas do Google Cloud.

Métricas de tráfego de servidor, destino e proxy

O Open Telemetry coleta e processa métricas (conforme descrito em Coleta de métricas) para tráfego de proxy, destino e servidor.

A tabela a seguir descreve as métricas usadas pelo coletor do Open Telemetry.

Nome da métrica	Usar
/proxy/request_count	Número de solicitações para o proxy da Apigee desde o registro da última amostra. Observação: disponível para a Apigee híbrida v1.12 e versões mais recentes.
/proxy/response_count	Número de respostas enviadas pelo proxy da API Apigee. Observação: disponível para a Apigee híbrida v1.12 e versões mais recentes.
/proxy/latencies	Distribuição das latências, que são calculadas a partir do momento em que a solicitação foi recebida pelo proxy da Apigee até o momento em que a resposta foi enviada do proxy da Apigee para o cliente. Observação: disponível para a Apigee híbrida v1.12 e versões mais recentes.
/proxyv2/request_count	O número total de solicitações de proxy de API recebidas.
/proxyv2/response_count	O número total de respostas de proxy da API recebidas.
/proxyv2/latencies_percentile	Porcentagem de todas as respostas da política da API a uma solicitação.
/target/request_count	Número de solicitações enviadas para a meta da Apigee desde o registro da última amostra. Observação: disponível para a Apigee híbrida v1.12 e versões mais recentes.
/target/response_count	Número de respostas recebidas da meta da Apigee desde que a última amostra foi registrada. Observação: disponível para a Apigee híbrida v1.12 e versões mais recentes.
/target/latencies	Distribuição das latências, que são calculadas a partir do momento em que a solicitação foi enviada ao destino da Apigee até o momento em que a resposta foi recebida pelo proxy da Apigee. O tempo não inclui o overhead de proxy da API Apigee. Observação: disponível para a Apigee híbrida v1.12 e versões mais recentes.
/targetv2/request_count	O número total de solicitações enviadas ao destino do proxy.
/targetv2/response_count	O número total de respostas recebidas do destino do proxy.
/server/fault_count	O número total de falhas do aplicativo do servidor. Por exemplo, o aplicativo pode ser apigee-runtime, apigee-synchronizer ou apigee-udca. Use o rótulo pod_name para filtrar os resultados por aplicativo.
/server/nio	Essa é uma métrica de indicador que pode ser filtrada pelo rótulo state para extrair detalhes de vários rótulos. Os valores representam diferentes operações de E/S e do sistema. Rótulos como accepted, accepted_total, close_failed, close_success, conn_pending, connected, connected_total, max_conn e timeouts estão relacionados a operações de soquete e de conexão. Os rótulos restantes se referem a outras operações do sistema.
/server/num_threads	O número de linhas de execução não daemon ativas no servidor.
/server/request_count	O número total de solicitações recebidas pelo aplicativo do servidor. Por exemplo, o aplicativo pode ser apigee-runtime, apigee-synchronizer ou apigee-udca. Use o rótulo pod_name para filtrar os resultados por aplicativo.
/server/response_count	Número total de respostas enviadas pelo aplicativo do servidor. Por exemplo, o aplicativo pode ser apigee-runtime, apigee-synchronizer ou apigee-udca. Use o rótulo pod_name para filtrar os resultados por aplicativo.
/server/latencies	Latência é a latência em milésimos de segundo introduzida pelo aplicativo do servidor. Por exemplo, o aplicativo pode ser apigee-runtime, apigee-synchronizer ou apigee-udca. Use o rótulo pod_name para filtrar os resultados por aplicativo.
/upstream/request_count	O número de solicitações enviadas pelo aplicativo do servidor para o aplicativo upstream. Por exemplo, para apigee-synchronizer, o plano de controle é upstream. Portanto, upstream/request_count para apigee-synchronizer é uma métrica que indica as solicitações que apigee-synchronizer fez para o plano de controle.
/upstream/response_count	O número de respostas recebidas pelo aplicativo do servidor a partir do aplicativo upstream. Por exemplo, para apigee-synchronizer, o plano de controle é upstream. Portanto, upstream/response_count para apigee-synchronizer é uma métrica que indica as solicitações que apigee-synchronizer recebeu do plano de controle.
/upstream/latencies	A latência incorrida no aplicativo do servidor upstream em milissegundos. Por exemplo, para o apigee-synchronizer, o plano de controle é upstream. Portanto, upstream/latencies para apigee-synchronizer é uma métrica que indica a latência do plano de controle.

Métricas de UDCA

O Open Telemetry coleta e processa métricas (conforme descrito em Coleta de métricas) do serviço UDCA da mesma forma que faz para outros serviços híbridos.

A tabela a seguir descreve as métricas que o coletor do Open Telemetry usa nos dados de métricas do UDCA.

state

state

Nome da métrica	Usar
/udca/server/local_file_oldest_ts	O carimbo de data/hora, em milissegundos desde o início da era Unix, para o arquivo mais antigo no conjunto de dados. Ela é calculada a cada 60 segundos e não reflete o estado em tempo real. Se a UDCA estiver atualizada e não houver arquivos aguardando o upload quando essa métrica for calculada, esse valor será 0. Se esse valor continuar aumentando, os arquivos antigos ainda estarão no disco.
/udca/server/local_file_latest_ts	O carimbo de data/hora, em milissegundos desde o início da Era Unix, para o arquivo mais recente no disco por estado. Ela é calculada a cada 60 segundos e não reflete o estado em tempo real. Se a UDCA estiver atualizada e não houver arquivos aguardando o upload quando essa métrica for calculada, esse valor será 0.
/udca/server/local_file_count	Uma contagem do número de arquivos em disco no pod de coleta de dados. O ideal é que o valor seja próximo de 0. Um valor alto consistente indica que os arquivos não estão sendo enviados ou que a UDCA não consegue fazer upload rápido o suficiente. Esse valor é calculado a cada 60 segundos e não reflete o estado da UDCA em tempo real.
/udca/server/total_latencies	O intervalo de tempo, em segundos, entre o arquivo de dados que está sendo criado e o arquivo de dados que está sendo enviado com sucesso. Os buckets serão 100 ms, 250 ms, 500 ms, 1s, 2s, 4s, 8s, 16s, 32s e 64s. Histograma para latência total desde a hora de criação do arquivo até o momento do upload.
/udca/server/upload_latencies	O tempo total, em segundos, que a UDCA gastou fazendo o upload de um arquivo de dados. Os buckets serão 100 ms, 250 ms, 500 ms, 1s, 2s, 4s, 8s, 16s, 32s e 64s. As métricas exibirão um histograma para a latência total de upload, incluindo todas as chamadas upstream.
/udca/upstream/http_error_count	A contagem total de erros HTTP encontrados pela UDCA. Essa métrica é útil para determinar qual parte das dependências externas da UDCA está falhando e por que motivo. Esses erros podem surgir para vários serviços (getDataLocation, Cloud storage, Token generator) e para vários conjuntos de dados (como api e trace) com vários códigos de resposta.
/udca/upstream/http_latencies	A latência upstream dos serviços, em segundos. Os buckets serão 100 ms, 250 ms, 500 ms, 1s, 2s, 4s, 8s, 16s, 32s e 64s. Histograma para latência de serviços upstream.
/udca/upstream/uploaded_file_sizes	O tamanho do arquivo que está sendo enviado para os serviços da Apigee, em bytes. Os buckets serão de 1 KB, 10 KB, 100 KB, 1 MB, 10 MB, 100 MB e 1 GB. Histograma para tamanho de arquivo por conjunto de dados, organização e ambiente.
/udca/upstream/uploaded_file_count	Uma contagem dos arquivos enviados pela UDCA para os serviços da Apigee. Observações: O valor do conjunto de dados event precisa continuar aumentando. O valor do conjunto de dados api precisa continuar aumentando se a organização/ambiente tiver tráfego constante. O valor do conjunto de dados trace aumenta quando você usa as ferramentas de rastreamento da Apigee para depurar ou inspecionar suas solicitações.
/udca/disk/used_bytes	O espaço ocupado pelos arquivos de dados no disco do pod de coleta de dados, em bytes. Um aumento nesse valor ao longo do tempo: ready_to_upload indica que o agente está atrasado. failed indica que os arquivos estão se acumulando no disco e não estão sendo enviados. Esse valor é calculado a cada 60 segundos.
/udca/server/pruned_file_count	Contagem de arquivos que foram excluídos porque o tempo de vida útil (TTL, na sigla em inglês) estava além do limite definido. O conjunto de dados pode incluir API, trace e outros, e o estado pode ser UPLOADED, FAILED ou DISCARDED.
/udca/server/retry_cache_size	Uma contagem do número de arquivos, por conjunto de dados, que a UDCA está tentando enviar. Depois de três tentativas para cada arquivo, a UDCA move o arquivo para o subdiretório /failed e o remove deste cache. Um aumento nesse valor ao longo do tempo indica que o cache não está sendo limpo, o que acontece quando os arquivos são movidos para o subdiretório /failed após três novas tentativas.

Métricas do Cassandra

O Open Telemetry coleta e processa métricas (conforme descrito em Coleta de métricas) do Cassandra da mesma forma que faz para outros serviços híbridos.

A tabela a seguir descreve as métricas que o coletor do Open Telemetry usa nos dados de métricas do Cassandra.

Nome da métrica (excluindo o domínio)	Usar
/cassandra/process_max_fds	Número máximo de descritores de arquivos abertos.
/cassandra/process_open_fds	Abra os descritores de arquivos.
/cassandra/jvm_memory_pool_bytes_max	Uso máximo de memória do JVM para o pool.
/cassandra/jvm_memory_pool_bytes_init	Uso inicial de memória da JVM para o pool.
/cassandra/jvm_memory_bytes_max	Uso máximo de memória de heap do JVM.
/cassandra/process_cpu_seconds_total	Tempo de CPU do usuário e do sistema gasto em segundos.
/cassandra/jvm_memory_bytes_used	Uso de memória de heap do JVM
/cassandra/compaction_pendingtasks	Compactação pendente para sstables do Cassandra. Consulte Compactação para saber mais.
/cassandra/jvm_memory_bytes_init	Uso de memória inicial de heap da JVM.
/cassandra/jvm_memory_pool_bytes_used	Uso de memória do pool JVM.
/cassandra/jvm_memory_pool_bytes_committed	Uso de memória confirmada do pool JVM.
/cassandra/clientrequest_latency	Latência da solicitação de leitura no intervalo de 75º percentil em microssegundos.
/cassandra/jvm_memory_bytes_committed	Uso de memória comprometida de heap do JVM.

Como trabalhar com métricas do Cassandra

A Apigee recomenda as seguintes métricas como essenciais para monitorar o banco de dados do Cassandra:

• Taxa de solicitação do Cassandra: use essa métrica para monitorar a taxa de solicitações de leitura e gravação do Cassandra.

  Métrica:	apigee.googleapis.com/cassandra/clientrequest_latency
  Rótulos de recursos:	project_id, location, cluster_name, namespace_name, pod_name, container_name
  Rótulos de métricas:	scope, unit Use esses rótulos para filtrar o recurso específico ou fazer o agrupamento.

  Para monitorar a taxa de solicitação de leitura do Cassandra, aplique o filtro a seguir.

  Filtros:

  metric.scope == 'Read' metric.unit == 'OneMinuteRate'

  Para monitorar a taxa de solicitação de gravação do Cassandra, aplique o filtro a seguir.

  Filtros:

  metric.scope == 'Write' metric.unit == 'OneMinuteRate'

• Latência da solicitação do Cassandra: use essa métrica para monitorar a latência de solicitação de leitura e gravação do Cassandra. Essa é a mesma métrica que a taxa de solicitação, apigee.googleapis.com/cassandra/clientrequest_latency, com diferentes filtros aplicados.

  Para monitorar a latência de solicitação de leitura do Cassandra, aplique o filtro a seguir.

  Filtros:

  metric.scope == 'Read' metric.unit == '99thPercentile' ou '95thPercentile' ou '75thPercentile'

  Para monitorar a latência de solicitação de gravação do Cassandra, aplique o filtro a seguir.

  Filtros:

  metric.scope == 'Write' metric.unit == '99thPercentile' ou '95thPercentile' ou '75thPercentile'

• Uso de solicitação de CPU de pod do Cassandra

  Métrica:	kubernetes.io/container/cpu/request_utilization (GKE on Google Cloud) kubernetes.io/anthos/container/cpu/request_utilization (Google Distributed Cloud)
  Rótulos de recursos:	project_id, location, cluster_name, namespace_name, pod_name, container_name Use esses rótulos para filtrar o recurso específico ou fazer o agrupamento.

• Uso do volume de dados do Cassandra

  Métrica:	kubernetes.io/pod/volume/utilization (GKE on Google Cloud) kubernetes.io/anthos/pod/volume/utilization (Google Distributed Cloud)
  Rótulos de recursos:	project_id, location, cluster_name, namespace_name, pod_name
  Rótulos de métricas:	volume_name Use esses rótulos para filtrar o recurso específico ou fazer o agrupamento.

Recomendações para escalonar o cluster do Cassandra

As diretrizes a seguir podem servir como um cluster recomendado para a decisão de escalonar seu cluster do Cassandra. Em geral, se as solicitações de leitura ou gravação mostrarem de maneira consistente a latência do 99º percentil ou se a latência aumentar continuamente e você observar picos correspondentes na utilização da solicitação de CPU e nas taxas de solicitação de leitura ou gravação, o cluster do Cassandra poderá ser considerado sob estresse. Considere fazer o escalonamento vertical do cluster. Para mais informações, consulte Como escalonar o Cassandra

Métrica	Limite	Duração do gatilho
kubernetes.io/pod/volume/utilization	85%	5 min
kubernetes.io/container/cpu/request_utilization	85%	3 min
Read request Latency 99thPercentile	5 s	3 min
Write request Latency 99thPercentile	5 s	3 min