Ver métricas

Está atualmente a ver a versão 1.14 da documentação do Apigee Hybrid. Para mais informações, consulte Versões suportadas.

Version 1.14 

Versões com suporte:

• v1.15 (mais recente)                        
• v1.14                        
• v1.13                         
• Lista de versões com suporte

Versões sem suporte:

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

Este tópico explica como ver as métricas do Apigee hybrid num painel de controlo do Cloud Operations.

Acerca das operações na nuvem

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

• Documentação do Metrics Explorer
• Introdução aos alertas
• Criar gráficos

Ativar métricas híbridas

Antes de poderem ser enviadas métricas híbridas para o Cloud Operations, tem de ativar primeiro a recolha de métricas. Consulte o artigo Configure a recolha de métricas para ver este procedimento.

Nota: as métricas para o gateway de entrada do Apigee não são suportadas. Consulte os problemas conhecidos.

Acerca dos nomes e das etiquetas das métricas híbridas

Quando ativada, a opção híbrida preenche automaticamente as métricas do Cloud Operations. O prefixo do nome do domínio das métricas criadas pelo híbrido é:

apigee.googleapis.com/

Por exemplo, a métrica /proxy/request_count contém o número total de pedidos recebidos por um proxy de API. Por conseguinte, o nome da métrica no Cloud Operations é:

apigee.googleapis.com/proxy/request_count

As Cloud Operations permitem filtrar e agrupar dados de métricas com base em etiquetas. Algumas etiquetas são predefinidas e outras são adicionadas explicitamente pelo híbrido. A secção Métricas disponíveis abaixo apresenta todas as métricas híbridas disponíveis e quaisquer etiquetas adicionadas especificamente para uma métrica que pode usar para filtragem e agrupamento.

Visualizar métricas

O exemplo seguinte mostra como ver métricas no Cloud Operations:

1. Abra o Explorador de métricas de monitorização num navegador. Em alternativa, se já estiver na consola Cloud Operations, selecione Explorador de métricas.

2. Em Encontre o tipo de recurso e a métrica, localize e selecione a métrica que quer examinar. Escolha uma métrica específica apresentada 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 são apresentadas em Métricas disponíveis.
5. O Cloud Operations apresenta o gráfico da métrica selecionada.
6. Clique em Guardar.

Criar um painel de controlo

Os painéis de controlo são uma forma de ver e analisar os dados de métricas importantes para si. O Cloud Operations fornece painéis de controlo predefinidos para os recursos e os serviços que usa, e também pode criar painéis de controlo personalizados.

Usa um gráfico para apresentar uma métrica do Apigee no seu painel de controlo personalizado. Com os painéis de controlo personalizados, tem controlo total sobre os gráficos apresentados e a respetiva configuração. Para mais informações sobre como criar gráficos, consulte o artigo Criar gráficos.

O exemplo seguinte mostra como criar um painel de controlo no Cloud Operations e, em seguida, adicionar gráficos para ver os dados de métricas:

1. Abra o Monitoring Metrics Explorer num navegador e, de seguida, selecione Painéis de controlo.
2. Selecione + Criar painel de controlo.
3. Atribua um nome ao painel de controlo. Por exemplo: tráfego de pedidos de proxy híbrido
4. Clique em Confirm.

5. Para cada gráfico que quer adicionar ao painel de controlo, siga estes passos:

   1. No painel de controlo, selecione Adicionar gráfico.
   2. Selecione a métrica pretendida, conforme descrito acima em Ver métricas.
   3. Conclua a caixa de diálogo para definir o gráfico.
   4. Clique em Guardar. O Cloud Operations apresenta dados para a métrica selecionada.

Métricas disponíveis

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

Métricas de tráfego de proxy, segmentação e servidor

O Open Telemetry recolhe e processa métricas (conforme descrito na secção Recolha de métricas) para o tráfego de proxy, de destino e de servidor.

A tabela seguinte descreve as métricas que o coletor Open Telemetry usa.

Nome da métrica	Utilizar
/proxy/request_count	Número de pedidos ao proxy do Apigee desde que a última amostra foi registada. Nota: disponível para o Apigee hybrid v1.12 e superior.
/proxy/response_count	O número de respostas enviadas pelo proxy da API Apigee. Nota: disponível para o Apigee hybrid v1.12 e superior.
/proxy/latencies	Distribuição das latências, que são calculadas a partir do momento em que o pedido foi recebido pelo proxy do Apigee até ao momento em que a resposta foi enviada do proxy do Apigee para o cliente. Nota: disponível para o Apigee hybrid v1.12 e superior.
/proxyv2/request_count	O número total de pedidos de proxy de API recebidos.
/proxyv2/response_count	O número total de respostas de proxy da API recebidas.
/proxyv2/latencies_percentile	Percentil de todas as respostas da política de API a um pedido.
/target/request_count	O número de pedidos enviados para o destino do Apigee desde que a última amostra foi registada. Nota: disponível para o Apigee hybrid v1.12 e superior.
/target/response_count	O número de respostas recebidas do destino do Apigee desde que a última amostra foi registada. Nota: disponível para o Apigee hybrid v1.12 e superior.
/target/latencies	Distribuição das latências, que são calculadas a partir do momento em que o pedido foi enviado para o destino do Apigee até ao momento em que a resposta foi recebida pelo proxy do Apigee. O tempo não inclui a sobrecarga do proxy de API do Apigee. Nota: disponível para o Apigee hybrid v1.12 e superior.
/targetv2/request_count	O número total de pedidos enviados para o 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 da aplicação de servidor. Por exemplo, a aplicação pode ser apigee-runtime, apigee-synchronizer ou apigee-udca. Use a etiqueta pod_name para filtrar os resultados por aplicação.
/server/nio	Esta é uma métrica de indicador que pode ser filtrada pela etiqueta state para obter detalhes de várias etiquetas. Os valores representam diferentes operações de sistema e de I/O. As etiquetas, como accepted, accepted_total, close_failed, close_success, conn_pending, connected, connected_total, max_conn e timeouts, estão relacionadas com operações de soquete e de ligação. As restantes etiquetas referem-se a outras operações do sistema.
/server/num_threads	O número de threads não daemon ativas no servidor.
/server/request_count	O número total de pedidos recebidos pela aplicação de servidor. Por exemplo, a aplicação pode ser apigee-runtime, apigee-synchronizer ou apigee-udca. Use a etiqueta pod_name para filtrar os resultados por aplicação.
/server/response_count	O número total de respostas enviadas pela aplicação de servidor. Por exemplo, a aplicação pode ser apigee-runtime, apigee-synchronizer ou apigee-udca. Use a etiqueta pod_name para filtrar os resultados por aplicação.
/server/latencies	A latência é a latência em milissegundos introduzida pela aplicação do servidor. Por exemplo, a aplicação pode ser apigee-runtime, apigee-synchronizer ou apigee-udca. Use a etiqueta pod_name para filtrar os resultados por aplicação.
/upstream/request_count	O número de pedidos enviados pela aplicação de servidor à respetiva aplicação a montante. Por exemplo, para o apigee-synchronizer, o plano de controlo está a montante. Assim, upstream/request_count para apigee-synchronizer é uma métrica que indica os pedidos que apigee-synchronizer fez ao plano de controlo.
/upstream/response_count	O número de respostas recebidas pela aplicação de servidor da respetiva aplicação a montante. Por exemplo, para o apigee-synchronizer, o plano de controlo está a montante. Assim, upstream/response_count para apigee-synchronizer é uma métrica que indica os pedidos que apigee-synchronizer recebeu do plano de controlo.
/upstream/latencies	A latência incorrida na aplicação do servidor a montante em milissegundos. Por exemplo, para o apigee-synchronizer, o plano de controlo está a montante. Assim, upstream/latencies para apigee-synchronizer é uma métrica que indica a latência do plano de controlo.

Métricas de UDCA

O Open Telemetry recolhe e processa métricas (conforme descrito na secção Recolha de métricas) para o serviço UDCA, tal como faz para outros serviços híbridos.

A tabela seguinte descreve as métricas que o coletor Open Telemetry usa nos dados de métricas da UDCA.

state

state

Nome da métrica	Utilizar
/udca/server/local_file_oldest_ts	A data/hora, em milissegundos desde o início da época Unix, do ficheiro mais antigo no conjunto de dados. Este valor é calculado a cada 60 segundos e não reflete o estado em tempo real. Se o UDCA estiver atualizado e não existirem ficheiros à espera de carregamento quando esta métrica é calculada, este valor é 0. Se este valor continuar a aumentar, significa que os ficheiros antigos ainda estão no disco.
/udca/server/local_file_latest_ts	A indicação de tempo, em milissegundos desde o início da época Unix, do ficheiro mais recente no disco por estado. Este valor é calculado a cada 60 segundos e não reflete o estado em tempo real. Se o UDCA estiver atualizado e não existirem ficheiros à espera de carregamento quando esta métrica é calculada, este valor é 0.
/udca/server/local_file_count	Uma contagem do número de ficheiros no disco no pod de recolha de dados. Idealmente, o valor deve estar próximo de 0. Um valor elevado consistente indica que os ficheiros não estão a ser carregados ou que a UDCA não consegue carregá-los com rapidez suficiente. Este 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 a criação do ficheiro de dados e o carregamento bem-sucedido do ficheiro de dados. Os intervalos são 100 ms, 250 ms, 500 ms, 1 s, 2 s, 4 s, 8 s, 16 s, 32 s e 64 s. Histograma da latência total desde a hora de criação do ficheiro até à hora de carregamento bem-sucedido.
/udca/server/upload_latencies	O tempo total, em segundos, que o UDCA demorou a carregar um ficheiro de dados. Os intervalos são 100 ms, 250 ms, 500 ms, 1 s, 2 s, 4 s, 8 s, 16 s, 32 s e 64 s. As métricas apresentam um histograma da latência total de carregamento, incluindo todas as chamadas a montante.
/udca/upstream/http_error_count	A contagem total de erros HTTP que o UDCA encontrou. Esta métrica é útil para ajudar a determinar que parte das dependências externas da UDCA está a falhar e por que motivo. Estes 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 a montante dos serviços, em segundos. Os intervalos são 100 ms, 250 ms, 500 ms, 1 s, 2 s, 4 s, 8 s, 16 s, 32 s e 64 s. Histograma da latência dos serviços a montante.
/udca/upstream/uploaded_file_sizes	O tamanho do ficheiro que está a ser carregado para os serviços do Apigee, em bytes. Os intervalos são 1 KB, 10 KB, 100 KB, 1 MB, 10 MB, 100 MB e 1 GB. Histograma do tamanho do ficheiro por conjunto de dados, organização e ambiente.
/udca/upstream/uploaded_file_count	Uma contagem dos ficheiros que o UDCA carregou para os serviços Apigee. Tenha em atenção que: O valor do conjunto de dados event deve continuar a aumentar. O valor do conjunto de dados api deve continuar a aumentar se a organização/o ambiente tiver um tráfego constante. O valor do conjunto de dados trace deve aumentar quando usa as ferramentas de rastreio do Apigee para depurar ou inspecionar os seus pedidos.
/udca/disk/used_bytes	O espaço ocupado pelos ficheiros de dados no disco do pod de recolha de dados, em bytes. Um aumento deste valor ao longo do tempo: ready_to_upload implica que o agente está atrasado. failed implica que os ficheiros estão a acumular-se no disco e não estão a ser carregados. Este valor é calculado a cada 60 segundos.
/udca/server/pruned_file_count	A quantidade de ficheiros que foram eliminados porque o respetivo tempo de vida (TTL) estava acima de um limite definido. O conjunto de dados pode incluir API, rastreio e outros, e o estado pode ser UPLOADED, FAILED ou DISCARDED.
/udca/server/retry_cache_size	Uma contagem do número de ficheiros, por conjunto de dados, que a UDCA está a tentar carregar novamente. Após 3 novas tentativas para cada ficheiro, o UDCA move o ficheiro para o subdiretório /failed e remove-o desta cache. Um aumento neste valor ao longo do tempo implica que a cache não está a ser limpa, o que acontece quando os ficheiros são movidos para o subdiretório /failed após 3 novas tentativas.

Métricas do Cassandra

O Open Telemetry recolhe e processa métricas (conforme descrito na secção Recolha de métricas) para o Cassandra, tal como faz para outros serviços híbridos.

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

Nome da métrica (excluindo o domínio)	Utilizar
/cassandra/process_max_fds	Número máximo de descritores de ficheiros abertos.
/cassandra/process_open_fds	Descritores de ficheiros abertos.
/cassandra/jvm_memory_pool_bytes_max	Utilização máxima de memória da JVM para o conjunto.
/cassandra/jvm_memory_pool_bytes_init	Utilização inicial de memória da JVM para o conjunto.
/cassandra/jvm_memory_bytes_max	Utilização máxima da memória heap da JVM.
/cassandra/process_cpu_seconds_total	Tempo da CPU do utilizador e do sistema gasto em segundos.
/cassandra/jvm_memory_bytes_used	Utilização de memória heap da JVM.
/cassandra/compaction_pendingtasks	Compactações pendentes para sstables do Cassandra. Para mais informações, consulte a secção Compactação.
/cassandra/jvm_memory_bytes_init	Utilização inicial de memória heap da JVM.
/cassandra/jvm_memory_pool_bytes_used	Utilização de memória do conjunto JVM.
/cassandra/jvm_memory_pool_bytes_committed	Utilização de memória comprometida do conjunto de JVM.
/cassandra/clientrequest_latency	Latência do pedido de leitura no intervalo do 75.º percentil em microssegundos.
/cassandra/jvm_memory_bytes_committed	Utilização de memória comprometida do heap da JVM.

Trabalhar com métricas do Cassandra

A Apigee recomenda as seguintes métricas como essenciais para monitorizar a sua base de dados Cassandra:

• Taxa de pedidos do Cassandra: use esta métrica para monitorizar a taxa de pedidos de leitura e escrita do Cassandra.

  Métrica:	apigee.googleapis.com/cassandra/clientrequest_latency
  Etiquetas de recursos:	project_id, location, cluster_name, namespace_name, pod_name, container_name
  Etiquetas de métricas:	scope, unit Use estas etiquetas para filtrar o recurso específico ou para agrupar.

  Para monitorizar a taxa de pedidos de leitura do Cassandra, aplique o seguinte filtro.

  Filtros:

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

  Para monitorizar a taxa de pedidos de escrita do Cassandra, aplique o seguinte filtro.

  Filtros:

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

• Latência do pedido do Cassandra: use esta métrica para monitorizar a latência do pedido de leitura e escrita do Cassandra. Esta é a mesma métrica que a taxa de pedidos, apigee.googleapis.com/cassandra/clientrequest_latency com diferentes filtros aplicados.

  Para monitorizar a latência do pedido de leitura do Cassandra, aplique o seguinte filtro.

  Filtros:

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

  Para monitorizar a latência do pedido de escrita do Cassandra, aplique o seguinte filtro.

  Filtros:

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

• Utilização do pedido de CPU do pod do Cassandra
  Nota: as métricas de pedido de CPU do pod do Cassandra só estão disponíveis no GKE.

  Métrica:	kubernetes.io/container/cpu/request_utilization (GKE on Google Cloud) Para mais informações, consulte o artigo Métricas do Kubernetes. kubernetes.io/anthos/container/cpu/request_utilization (Google Distributed Cloud)
  Etiquetas de recursos:	project_id, location, cluster_name, namespace_name, pod_name, container_name Use estas etiquetas para filtrar o recurso específico ou para agrupar.

• Utilização do volume de dados do Cassandra
  Nota: as métricas de utilização do volume de dados do Cassandra só estão disponíveis no GKE.

  Métrica:	kubernetes.io/pod/volume/utilization (GKE on Google Cloud) Para mais informações, consulte o artigo Métricas do Kubernetes. kubernetes.io/anthos/pod/volume/utilization (Google Distributed Cloud)
  Etiquetas de recursos:	project_id, location, cluster_name, namespace_name, pod_name
  Etiquetas de métricas:	volume_name Use estas etiquetas para filtrar o recurso específico ou para agrupar.

Recomendações para dimensionar o cluster do Cassandra

As diretrizes seguintes podem servir como um cluster recomendado para a decisão de dimensionar o seu cluster do Cassandra. Em geral, se os pedidos de leitura ou escrita mostrarem consistentemente uma latência no percentil 99 ou a latência estiver a aumentar continuamente, e vir picos correspondentes no pico de utilização do pedido de CPU e nas taxas de pedidos de leitura ou escrita, pode considerar que o seu cluster do Cassandra está sob pressão. Pondere aumentar a escala do cluster. Para mais informações, consulte o artigo Dimensionar o Cassandra

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