Diretrizes de monitorização de clusters

Vista geral

Este guia fornece diretrizes sobre o que monitorizar e como monitorizar uma implementação do Apigee Hybrid. Destina-se a administradores de clusters híbridos e administradores da organização.

Se for um utilizador recente do Google Cloud Monitoring, consulte a documentação do Google Cloud Monitoring para: criar gráficos com o explorador de métricas e como funcionam os alertas.

Os clusters do Apigee Hybrid fornecem métricas de INS (indicador do nível de serviço) para ajudar a compreender o desempenho dos serviços de aplicações e de sistemas em qualquer altura. Pode ver uma lista completa de métricas disponíveis.

O Google Cloud Monitoring usa o tipo de recurso para identificar todas as métricas de SLI. Existem três tipos de recursos comuns usados para todas as métricas do Apigee Hybrid.

  • k8s_container para métricas ao nível do sistema.
  • Proxy para métricas do proxy de API do Apigee.
  • Target para métricas de destino da API Apigee

Os tipos de recursos têm etiquetas comuns que se aplicam a todas as métricas associadas. Por exemplo, todas as métricas com o tipo de recurso k8s_container têm as etiquetas cluster_name, pod_name e container_name disponíveis para utilização, além das etiquetas de métricas. Deve usar uma combinação de etiquetas de tipo de recurso e etiquetas de métricas para monitorizar eficazmente o estado e o desempenho do cluster.

Limite de alerta: num mundo perfeito, os limites de alerta seriam óbvios e a documentação fornecida indicaria os valores que devem acionar alertas. Na realidade, é menos óbvio para o Apigee definir o que é um desempenho aceitável e o que é uma utilização perigosa de recursos de serviços e infraestruturas. Os valores de limite de alerta variam muito consoante os padrões de tráfego específicos e os contratos de SLO/SLA.

A otimização e a determinação do limite de alerta são um processo contínuo, uma vez que podem mudar com a utilização do serviço e da infraestrutura. Use o limite de aviso e crítico para notificações e alertas.

  • Em bom estado: o valor é inferior ao limite de aviso.
  • Preocupante: valor superior ao limite de aviso, mas inferior ao limite crítico.
  • Crítico: valor > limite crítico.

Os clientes devem usar as ferramentas fornecidas para determinar o limite ideal, quer sejam os painéis de controlo do Cloud Monitoring que os clientes podem criar com o MQL fornecido abaixo ou as estatísticas do Apigee, para identificar o que é "normal" e, em seguida, ajustar os limites dos alertas em conformidade.

A monitorização de clusters híbridos pode ser categorizada em quatro grupos gerais diferentes, por exemplo, monitorização de tráfego, base de dados, plano de controlo do Apigee e infraestrutura. As secções seguintes descrevem estes grupos em detalhe:

Trânsito

As métricas SLI de proxy e destino do Apigee fornecem contagens de pedidos/respostas e latências para o proxy e os destinos da API. A métrica SLI de latência da política do Apigee fornece latências de resposta da política. Estas métricas de SLI oferecem cobertura para a monitorização do tráfego da API Apigee.

Taxa de pedidos

Quantidade de pedidos de proxy

Exemplo de utilização: use o elemento proxy/request_count para monitorizar a contagem de pedidos de proxy. O gráfico proxy/request_count apresenta a taxa de pedidos para proxies. Este gráfico é útil para identificar que proxy está a receber uma taxa de pedidos mais elevada, padrões de taxa de pedidos e qualquer pico anormal em chamadas de pedidos para um proxy específico. Qualquer pico anormal inesperado no tráfego da API pode ser um problema de segurança relacionado com um bot ou um ataque a proxies de API. Da mesma forma, uma grande diminuição no tráfego geral da nuvem indica problemas com os clientes ou a conetividade dos componentes upstream do Apigee.

Tipos de recursos Proxy
Métrica proxy/request_count
Agrupar por method e todas as etiquetas do tipo de recurso Proxy
Agregador soma
Consideração de alertas Eventos como alertas de aumento/diminuição anormal de request_count
Limite de alerta Nenhum
Consulta MQL do painel de controlo do Cloud Monitoring: 
fetch apigee.googleapis.com/Proxy
| metric 'apigee.googleapis.com/proxy/request_count'
| align rate(1m)
| every 1m
| group_by [metric.method],
  [value_request_count_aggregate: aggregate(value.request_count)]

Contagem de pedidos de segmentação

Exemplo de utilização: use o target/request_count para monitorizar a contagem de pedidos do destino de tempo de execução do Apigee. O gráfico target/request_count apresenta a taxa de pedidos recebida pelo destino do Apigee. Este gráfico pode ser útil para ver que alvo está a receber uma taxa de pedidos mais elevada, o padrão da taxa de pedidos e qualquer pico anormal nas chamadas de pedidos para um alvo específico.

Tipos de recursos Alvo
Métrica target/request_count
Agrupar por method e todas as etiquetas do tipo de recurso Target
Agregador soma
Consideração de alertas Eventos como alertas de aumento/diminuição anormal de request_count
Limite de alerta Nenhum
Consulta MQL do painel de controlo do Cloud Monitoring: 
fetch apigee.googleapis.com/Target
| metric 'apigee.googleapis.com/target/request_count'
| align rate(1m)
| every 1m
| group_by [metric.method, metric.type, metric.endpoint],
  [value_request_count_aggregate: aggregate(value.request_count)]

Taxa de erros

Contagem de respostas de erro de proxy

Exemplo de utilização: use o elemento proxy/response_count para monitorizar a taxa de respostas de erro do proxy. O gráfico proxy/response_count apresenta a taxa de pedidos do proxy de API. Este gráfico é útil para compreender que proxy está a receber uma taxa de erro de pedido mais elevada ou qualquer pico de erro anormal nas chamadas de pedido para um proxy específico.

Tipos de recursos Proxy
Métrica proxy/response_count
Filtrar por response_code != 200
Agrupar por method, response_code, fault_code, fault_source, apigee_fault, e todas as etiquetas do tipo de recurso Proxy
Agregador soma
Consideração de alertas A proporção de erros de resposta do proxy: total de erros de resposta / total de respostas.
  • Total de erros de resposta = Soma de proxy/response_count com o filtro response_code != 200
  • Número total de respostas = Soma de proxy/response_count
Limite de alerta Depende do SLO para a instalação. As instalações de produção e não produção podem ter limites diferentes. Por exemplo: para produção, acione uma notificação de evento se a taxa de erro 500 de resposta do proxy for de 5% durante 5 minutos.
Consulta MQL do painel de controlo do Cloud Monitoring: 
fetch apigee.googleapis.com/Proxy
| metric 'apigee.googleapis.com/proxy/response_count'
| filter (metric.response_code != 200)
| align rate(1m)
| every 1m
| group_by
  [metric.method, metric.response_code, metric.fault_code,
   metric.fault_source, metric.apigee_fault],
  [value_response_count_aggregate: aggregate(value.response_count)]
Exemplo de MQL da política de alerta de operação do Google Cloud: 
fetch apigee.googleapis.com/Proxy::apigee.googleapis.com/proxy/response_count
| {
   filter (metric.response_code == 500)
   ;
   ident
}
| group_by drop[metric.response_code ], sliding(5m), .sum
| ratio
| scale '%'
| every (30s)
| condition val() > 5'%'

Contagem de respostas de erro de destino

Exemplo de utilização: use o target/response_count para monitorizar a taxa de resposta de erros de destino da API. O gráfico target/response_count apresenta a taxa de pedidos da API Target. Este gráfico pode ser útil para identificar que alvo está a receber uma taxa de pedidos mais elevada ou qualquer pico de erros anormal nas chamadas de pedidos.

Tipos de recursos Alvo
Métrica target/response_count
Filtrar por response_code != 200
Agrupar por method e todas as etiquetas do tipo de recurso Target
Agregador soma
Consideração de alertas A proporção de erros de resposta do proxy, por exemplo: total de erros de resposta / total de respostas.
  • Total de erros de resposta = Soma de target/response_count com o filtro response_code != 200
  • Número total de respostas = Soma de target/response_count
Limite de alerta Depende do SLO para a instalação. Por exemplo: para produção, acione uma notificação de evento se a taxa de erro de resposta alvo for de 5% durante 3 minutos.
Consulta MQL do painel de controlo do Cloud Monitoring: 
fetch apigee.googleapis.com/Target
| metric 'apigee.googleapis.com/target/response_count'
| filter (metric.response_code != 200)
| align rate(1m)
| every 1m
| group_by
  [metric.method, metric.type, metric.endpoint,
   metric.response_code],
  [value_response_count_aggregate: aggregate(value.response_count)]

Latências

Latências de proxy

Exemplo de utilização: use proxy/latencies para monitorizar as latências de todas as respostas de proxy da API a um pedido. O gráfico de proxy/latências pode ser útil para identificar a latência no proxy de API do Apigee para a latência do pedido de proxy de API geral.

Tipos de recursos Proxy
Métrica proxy/latencies
Agrupar por method e todas as etiquetas do tipo de recurso Proxy
Agregador p99 (percentil 99)
Consideração de alertas Valor elevado do percentil de latência p99.
Limite de alerta Depende do SLO para a instalação. Por exemplo: para produção, acione uma notificação de evento se o valor do percentil de latência p99 do proxy for de 5 segundos durante 5 minutos.
Consulta MQL do painel de controlo do Cloud Monitoring: 
fetch apigee.googleapis.com/Proxy
| metric 'apigee.googleapis.com/proxy/latencies'
| align delta(1m)
| every 1m
| group_by [metric.method],
    [value_latencies_percentile: percentile(value.latencies, 99)]

Latências alvo

Exemplo de utilização: use o elemento target/latencies para monitorizar as latências de todas as respostas de destino do proxy de API a um pedido. O gráfico de destino/latências identifica o tempo total que o destino do proxy de API do Apigee demora a responder a um pedido. Este valor não inclui a sobrecarga do proxy da API Apigee.

Tipos de recursos Alvo
Métrica target/latencies
Agrupar por method, percentil e todas as etiquetas do tipo de recurso Target
Agregador p99 (percentil 99)
Consideração de alertas Valor elevado do percentil de latência p99.
Limite de alerta Depende do SLO para a instalação. Por exemplo: para produção, acione uma notificação de evento se o valor do percentil de latência p99 de destino for de 5 segundos durante 5 minutos.
Consulta MQL do painel de controlo do Cloud Monitoring: 
fetch apigee.googleapis.com/Target
| metric 'apigee.googleapis.com/target/latencies'
| align delta(1m)
| every 1m
| group_by [metric.method],
    [value_latencies_percentile: percentile(value.latencies, 99)]

Bases de dados

Cassandra

O serviço de base de dados do Apigee Cassandra tem várias métricas de INS do Cassandra. Estas métricas de SLI podem fornecer uma monitorização abrangente para o serviço Apigee Cassandra. No mínimo, juntamente com a utilização de recursos do Cassandra (CPU, memória e volume de disco), a latência de pedidos de leitura e escrita do cliente deve ser monitorizada para verificar o estado do serviço Cassandra.

Taxa de pedidos de leitura do Cassandra

Exemplo de utilização: a métrica do INS cassandra/clientrequest_rate (com scope=Read) fornece estatísticas sobre a taxa média de pedidos de leitura dos serviços Cassandra em qualquer momento. Esta métrica ajuda a compreender as tendências do nível de atividade dos pedidos de leitura dos clientes.

Tipos de recursos k8s_container
Métrica cassandra/clientrequest_rate
Filtrar por scope = Read e unit = OneMinuteRate
Agrupar por scope, unit e todas as etiquetas do tipo de recurso k8s_container
Agregador soma
Consideração de alertas Para quaisquer potenciais problemas ou alterações significativas nos padrões de consulta dos clientes; por exemplo, um aumento ou uma diminuição repentina e inesperada na taxa de pedidos de leitura.
Limite de alerta Nenhum
Consulta MQL do painel de controlo do Cloud Monitoring: 
fetch k8s_container
| metric 'apigee.googleapis.com/cassandra/clientrequest_latency'
| filter (metric.scope == 'Read' && metric.unit == 'OneMinuteRate')
| group_by 1m,
  [value_clientrequest_latency_mean: mean(value.clientrequest_latency)]
| every 1m
| group_by [metric.scope, metric.unit],
  [value_clientrequest_latency_mean_aggregate:
     aggregate(value_clientrequest_latency_mean)]

Taxa de pedidos de gravação do Cassandra

Exemplo de utilização: a métrica do INS cassandra/clientrequest_rate (com scope=Write) fornece informações sobre a taxa média de pedidos de gravação dos serviços Cassandra em qualquer momento. Esta métrica ajuda a compreender as tendências do nível de atividade dos pedidos de gravação dos clientes.

Tipos de recursos k8s_container
Métrica cassandra/clientrequest_rate
Filtrar por scope = Read e unit = OneMinuteRate
Agrupar por scope, unit e todas as etiquetas do tipo de recurso k8s_container
Agregador soma
Consideração de alertas Para quaisquer potenciais problemas ou alterações significativas nos padrões de consulta dos clientes; por exemplo, um aumento ou uma diminuição súbita e inesperada nos pedidos de gravação que justifiquem uma investigação mais aprofundada.
Limite de alerta Nenhum
Consulta MQL do painel de controlo do Cloud Monitoring: 
fetch k8s_container
| metric 'apigee.googleapis.com/cassandra/clientrequest_latency'
| filter (metric.scope == 'Write' && metric.unit == 'OneMinuteRate')
| group_by 1m,
  [value_clientrequest_latency_mean: mean(value.clientrequest_latency)]
| every 1m
| group_by [metric.scope, metric.unit],
  [value_clientrequest_latency_mean_aggregate:
     aggregate(value_clientrequest_latency_mean)]

Latência do pedido de leitura do Cassandra

Exemplo de utilização: a métrica SLI cassandra/clientrequest_latency (com scope=Read) fornece a latência do pedido de leitura dos serviços Cassandra (no percentil 99, percentil 95 ou percentil 75). Estas métricas ajudam a ter uma vista geral do desempenho do Cassandra e podem indicar alterações nos padrões de utilização ou um problema que se manifeste ao longo do tempo.

Tipos de recursos k8s_container
Métrica cassandra/clientrequest_latency
Filtrar por scope = Read e unit = 99thPercentile
Agrupar por scope, unit e todas as etiquetas do tipo de recurso k8s_container
Agregador soma
Consideração de alertas Se o SLI de latência dos pedidos de leitura mostrar consistentemente uma tendência de aumento da latência do percentil 99 de forma contínua.
Limite de alerta Depende do seu SLO para os serviços Cassandra. Por exemplo: em produção, acionar uma notificação de evento se o valor de leitura clientrequest_latency do percentil 99 for de 5 segundos durante 3 minutos
Consulta MQL do painel de controlo do Cloud Monitoring: 
fetch k8s_container
| metric 'apigee.googleapis.com/cassandra/clientrequest_latency'
| filter (metric.scope == 'Read' && metric.unit == '99thPercentile')
| group_by 1m,
  [value_clientrequest_latency_mean: mean(value.clientrequest_latency)]
| every 1m
| group_by [metric.scope, metric.unit],
  [value_clientrequest_latency_mean_aggregate:
     aggregate(value_clientrequest_latency_mean)]

Latência do pedido de gravação do Cassandra

Exemplo de utilização: a métrica SLI cassandra/clientrequest_latency (com scope=Write) fornece a latência do pedido de gravação dos serviços Cassandra (no 99.º percentil, 95.º percentil ou 75.º percentil). Estas métricas ajudam a ter uma vista geral do desempenho do Cassandra e podem indicar alterações nos padrões de utilização ou um problema que se manifeste ao longo do tempo.

Tipos de recursos k8s_container
Métrica cassandra/clientrequest_latency
Filtrar por scope = Write e unit = 99thPercentile
Agrupar por scope, unit e todas as etiquetas do tipo de recurso k8s_container
Agregador soma
Consideração de alertas Se o SLI de latência dos pedidos de gravação mostrar consistentemente uma tendência de aumento contínuo da latência do percentil 99.
Limite de alerta Depende do seu SLO para os serviços Cassandra. Por exemplo: em produção, acionar uma notificação de evento se o valor de gravação clientrequest_latency do percentil 99 for de 5 segundos durante 3 minutos
Consulta MQL do painel de controlo do Cloud Monitoring: 
fetch k8s_container
| metric 'apigee.googleapis.com/cassandra/clientrequest_latency'
| filter (metric.scope == 'Write' && metric.unit == '99thPercentile')
| group_by 1m,
  [value_clientrequest_latency_mean: mean(value.clientrequest_latency)]
| every 1m
| group_by [metric.scope, metric.unit],
  [value_clientrequest_latency_mean_aggregate:
     aggregate(value_clientrequest_latency_mean)]

Plano de controlo do Apigee

As métricas SLI do serviço Apigee Synchronizer fornecem contagens de pedidos e respostas, bem como latências entre o plano de controlo do Apigee e o plano de tempo de execução híbrido. Espera-se que as instâncias do sincronizador em execução no plano de execução consultem o plano de controlo regularmente, transfiram os contratos e disponibilizem os mesmos às instâncias de execução locais.

Taxa de pedidos

Quantidade de pedidos a montante

Exemplo de utilização: as métricas upstream/request_count indicam o número de pedidos feitos pelo serviço Synchronizer ao plano de controlo do Apigee.

Tipos de recursos k8s_container
Métrica upstream/request_count
Filtrar por container_name = apigee-synchronizer e type = CONTRACT
Agrupar por method, type, container_name e todas as etiquetas do tipo de recurso k8s_container
Agregador soma
Consideração de alertas Use esta opção para anomalias de tráfego, como um pico anormal de request_count ou um alerta de diminuição.
Limite de alerta Nenhum
Consulta MQL do painel de controlo do Cloud Monitoring: 
fetch k8s_container
| metric 'apigee.googleapis.com/upstream/request_count'
| filter
  (resource.container_name == 'apigee-synchronizer')
  && (metric.type == 'CONTRACT')
| align rate(1m)
| every 1m
| group_by [metric.method, metric.type, resource.container_name],
  [value_request_count_aggregate: aggregate(value.request_count)]

Taxa de erros

Quantidade de respostas a montante

Exemplo de utilização: a métrica SLI upstream/response_count indica o número de respostas que os serviços do sincronizador receberam do plano de controlo do Apigee. Este gráfico pode ser útil para identificar problemas de conetividade ou configuração entre o plano de tempo de execução do Apigee Hybrid e o plano de controlo.

Tipos de recursos k8s_container
Métrica upstream/request_count
Filtrar por method, response_type, container_name e todas as etiquetas do tipo de recurso k8s_container
Agrupar por
Agregador soma
Consideração de alertas Se existirem erros nas métricas upstream/response_count com códigos de resposta diferentes de 200 devolvidos pelo plano de controlo do Apigee, é necessária uma investigação mais aprofundada desses erros.
Limite de alerta Depende do seu SLO para os serviços Cassandra. Por exemplo: em produção, acione uma notificação de evento se o sincronizador tiver mais de um erro de response_code a cada 3 minutos.
Consulta MQL do painel de controlo do Cloud Monitoring: 
fetch k8s_container
| metric 'apigee.googleapis.com/upstream/response_count'
| filter
  (resource.container_name == 'apigee-synchronizer')
  && (metric.response_code != '200' && metric.type == 'CONTRACT')
| align rate(1m)
| every 1m
| group_by
  [metric.method, metric.response_code, metric.type, resource.container_name],
  [value_response_count_aggregate: aggregate(value.response_count)]

Infraestrutura

O GKE e outras plataformas Kubernetes fornecem métricas SLI ao nível do sistema. As etiquetas das métricas de SLI podem ser filtradas e agrupadas para monitorizar um contentor específico e a respetiva utilização de recursos. Para monitorizar o estado de funcionamento e a disponibilidade da infraestrutura do cluster do Apigee Runtime, um administrador do cluster pode monitorizar a utilização de recursos comuns de contentores e pods, como CPU, memória, disco e contagens de reinícios de contentores. Siga a documentação do GKE para ver mais detalhes sobre as métricas e as etiquetas disponíveis.

A tabela seguinte apresenta alguns dos serviços e os contentores que pode monitorizar para cada serviço.

Nome do serviço Nome do contentor
Cassandra apigee-cassandra
Processador de mensagens(MP) apigee-runtime
Sincronizador apigee-synchronizer
Telemetria apigee-prometheus-app
apigee-prometheus-proxy
apigee-prometheus-agg
apigee-stackdriver-exporter

Contentores / agrupamentos

Contagem de reinícios

Exemplo de utilização: a métrica SLI do sistema kubernetes.io/container/restart_count indica o número de vezes que um contentor foi reiniciado. Este gráfico pode ser útil para identificar se um contentor está a falhar/ser reiniciado com frequência. O contentor de serviço específico pode ser filtrado por etiquetas de métricas para a monitorização do contentor de um serviço específico.

O exemplo seguinte mostra a utilização da métrica kubernetes.io/container/restart_count para o contentor do Cassandra. Pode usar esta métrica para qualquer um dos contentores na tabela acima.

Tipos de recursos k8s_container
Métrica kubernetes.io/container/restart_count
Filtrar por namespace_name = apigee e container_name =~ .*cassandra.*
Agrupar por cluster_name, namespace_name, pod_name, container_name e todos os etiquetas do tipo de recurso k8s_container
Agregador soma
Consideração de alertas Se um contentor for reiniciado com frequência, é necessária uma investigação mais detalhada para determinar a causa principal. Existem vários motivos pelos quais um contentor pode ser reiniciado, como OOMKilled, disco de dados cheio e problemas de configuração, entre outros.
Limite de alerta Depende do SLO para a instalação. Por exemplo: para produção, acione uma notificação de evento se um contentor for reiniciado mais de 5 vezes no espaço de 30 minutos.
Consulta MQL do painel de controlo do Cloud Monitoring: 
fetch k8s_container
| metric 'kubernetes.io/container/restart_count'
| filter
  (resource.container_name =~ '.*cassandra.*'
   && resource.namespace_name == 'apigee')
| align rate(1m)
| every 1m
| group_by
  [resource.cluster_name, resource.namespace_name, resource.pod_name,
   resource.container_name],
  [value_restart_count_aggregate: aggregate(value.restart_count)]