Ver métricas

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:

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.

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.

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 e os rótulos usados pelo coletor do Open Telemetry. Esses rótulos são usados nas entradas do registro de métricas.

Nome da métrica Rótulo Usar
/proxy/request_count method Número de solicitações para o proxy da Apigee desde o registro da última amostra.
/proxy/response_count method

response_code

fault_code

fault_source

apigee_fault

 Número de respostas enviadas pelo proxy da API Apigee.
/proxy/latencies method 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.
/proxyv2/request_count method O número total de solicitações de proxy de API recebidas.
/proxyv2/response_count method

response_code

fault_code

fault_source

apigee_fault

 O número total de respostas de proxy da API recebidas.
/proxyv2/latencies_percentile method Porcentagem de todas as respostas da política da API a uma solicitação.
/target/request_count method

type

target_endpoint

 Número de solicitações enviadas para a meta da Apigee desde o registro da última amostra.
/target/response_count method

response_code

type

 Número de respostas recebidas da meta da Apigee desde que a última amostra foi registrada.
/target/latencies method

type

 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.
/targetv2/request_count method

target_type

target_endpoint

 O número total de solicitações enviadas ao destino do proxy.
/targetv2/response_count method

response_code

target_type

target_endpoint

 O número total de respostas recebidas do destino do proxy.
/server/fault_count source

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 state O número de soquetes abertos.
/server/num_threads O número de linhas de execução não daemon ativas no servidor.
/server/request_count method

type

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 method

response_code

type

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 method

response_code

type

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 method

type

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 method

response_code

type

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 method

response_code

type

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 e os rótulos que o coletor do Open Telemetry usa nos dados de métricas do UDCA. Esses rótulos são usados nas entradas do registro de métricas.

Nome da métrica Rótulo Usar
/udca/server/local_file_oldest_ts dataset

state

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 dataset

state

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 dataset

state

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 dataset

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 dataset

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 service

dataset

response_code

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 service

dataset

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 dataset

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 dataset 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 dataset

state

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 dataset

state

 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 dataset

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 e os rótulos que o coletor do Open Telemetry usa nos dados de métricas do Cassandra. Esses rótulos são usados nas entradas do registro de métricas.

Nome da métrica (excluindo o domínio) Rótulo 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 pool Uso máximo de memória do JVM para o pool.
/cassandra/jvm_memory_pool_bytes_init pol Uso inicial de memória da JVM para o pool.
/cassandra/jvm_memory_bytes_max area 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 area Uso de memória de heap do JVM
/cassandra/compaction_pendingtasks unit Compactação pendente para sstables do Cassandra. Consulte Compactação para saber mais.
/cassandra/jvm_memory_bytes_init area Uso de memória inicial de heap da JVM.
/cassandra/jvm_memory_pool_bytes_used pool Uso de memória do pool JVM.
/cassandra/jvm_memory_pool_bytes_committed pool Uso de memória confirmada do pool JVM.
/cassandra/clientrequest_latency scope

unit

 Latência da solicitação de leitura no intervalo de 75º percentil em microssegundos.
/cassandra/jvm_memory_bytes_committed area 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étricaLimiteDuração do gatilho
kubernetes.io/pod/volume/utilization85%5 min
kubernetes.io/container/cpu/request_utilization85%3 min
Read request Latency 99thPercentile5 s3 min
Write request Latency 99thPercentile5 s3 min