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_containerpara métricas ao nível do sistema.ProxyV2para métricas do proxy de API da Apigee.TargetV2para 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
Contagem de pedidos de proxy
Exemplo de utilização: use o elemento proxyv2/request_count para monitorizar a contagem de pedidos de proxy. O gráfico proxyv2/request_count apresenta a taxa de pedidos de 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 | ProxyV2 |
| Métrica | proxyv2/request_count |
| Agrupar por | method e todas as etiquetas do tipo de recurso ProxyV2 |
| 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/ProxyV2 | metric 'apigee.googleapis.com/proxyv2/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 targetv2/request_count para monitorizar a contagem de pedidos do destino de tempo de execução do Apigee. O gráfico targetv2/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 | TargetV2 |
| Métrica | targetv2/request_count |
| Agrupar por | method e todas as etiquetas do tipo de recurso TargetV2 |
| 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/TargetV2 | metric 'apigee.googleapis.com/targetv2/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 proxyv2/response_count para monitorizar a taxa de respostas de erro do proxy. O gráfico proxyv2/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 | ProxyV2 |
| Métrica | proxyv2/response_count |
| Filtrar por | response_code != 200
Use uma regex para excluir todos os códigos 2xx e 3xx "response_code !=~ 1.*| 2.*|3.*" |
| Agrupar por | method, response_code, fault_code,
fault_source, apigee_fault,
e todas as etiquetas do tipo de recurso ProxyV2
|
| Agregador | soma |
| Consideração de alertas | A proporção de erros de resposta do proxy: total de erros de resposta / total de respostas.
|
| 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/ProxyV2 | metric 'apigee.googleapis.com/proxyv2/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/ProxyV2::apigee.googleapis.com/proxyv2/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 elemento targetv2/response_count para monitorizar a taxa de resposta de erros do destino da API. O gráfico targetv2/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 | TargetV2 |
| Métrica | targetv2/response_count |
| Filtrar por | response_code != 200
Use uma regex para excluir todos os códigos 2xx e 3xx "response_code !=~ 1.*| 2.*|3.*" |
| Agrupar por | method e todas as etiquetas do tipo de recurso TargetV2 |
| 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.
|
| 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/TargetV2 | metric 'apigee.googleapis.com/targetv2/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
Percentil de latências de proxy
Exemplo de utilização: use proxyv2/latencies_percentile para monitorizar o percentil de latência (p50, p90, p95 e p99) de todas as respostas de proxy da API a um pedido. O gráfico proxyv2/latencies_percentile pode ser útil para identificar a latência no proxy de API do Apigee em relação à latência geral do pedido do proxy de API.
| Tipos de recursos | ProxyV2 |
| Métrica | proxyv2/latencies_percentile |
| Filtrar por | percentile = p99 |
| Agrupar por | method, percentil e todas as etiquetas do tipo de recurso ProxyV2 |
| Agregador | p99 (percentil 99) |
| Consideração de alertas | Valor elevado do percentil de latências_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 de proxy p99 latencies_percentile for de 5 segundos durante 5 minutos. |
Consulta MQL do painel de controlo do Cloud Monitoring:
fetch apigee.googleapis.com/ProxyV2
| metric 'apigee.googleapis.com/proxyv2/latencies_percentile'
| filter (metric.percentile == 'p99')
| group_by 1m,
[value_latencies_percentile_mean: mean(value.latencies_percentile)]
| every 1m
| group_by [metric.method, metric.percentile],
[value_latencies_percentile_mean_percentile:
percentile(value_latencies_percentile_mean, 99)]
|
|
Percentil de latências alvo
Exemplo de utilização: use targetv2/latencies_percentile para monitorizar o percentil de latência (p50, p90, p95 e p99) de todas as respostas de destino do proxy de API a um pedido. O gráfico targetv2/latencies_percentile identifica o tempo total que o destino do proxy da API Apigee demora a responder a um pedido. Este valor não inclui a sobrecarga do proxy da API Apigee.
| Tipos de recursos | TargetV2 |
| Métrica | targetv2/latencies_percentile |
| Filtrar por | percentile = p99 |
| Agrupar por | method, percentil e todas as etiquetas do tipo de recurso TargetV2 |
| Agregador | p99 (percentil 99) |
| Consideração de alertas | Valor elevado do percentil de latências_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 de target p99 latencies_percentile for de 5 segundos durante 5 minutos. |
Consulta MQL do painel de controlo do Cloud Monitoring:
fetch apigee.googleapis.com/ProxyV2
| metric 'apigee.googleapis.com/proxyv2/latencies_percentile'
| filter (metric.percentile == 'p99')
| group_by 1m,
[value_latencies_percentile_mean: mean(value.latencies_percentile)]
| every 1m
| group_by [metric.method, metric.percentile],
[value_latencies_percentile_mean_percentile:
percentile(value_latencies_percentile_mean, 99)]
|
|
Percentil de latências de políticas
Exemplo de utilização: use o policyv2/latencies_percentile para monitorizar o percentil de latência de processamento (p50, p90, p95 e p99) de todas as políticas do Apigee. O gráfico policyv2/latencies_percentile pode ser útil para identificar a latência na política da API Apigee para a latência do pedido de proxy da API geral do cliente.
| Tipos de recursos | ProxyV2 |
| Métrica | proxyv2/latencies_percentile |
| Filtrar por | percentile = p99 |
| Agrupar por | method, percentil e todas as etiquetas do tipo de recurso ProxyV2 |
| Agregador | p99 (percentil 99) |
| Consideração de alertas | Valor elevado do percentil de latências_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 de proxy p99 latencies_percentile for de 5 segundos durante 5 minutos. |
Consulta MQL do painel de controlo do Cloud Monitoring:
fetch apigee.googleapis.com/ProxyV2
| metric 'apigee.googleapis.com/policyv2/latencies_percentile'
| filter (metric.percentile == 'p99')
| group_by 1m,
[value_latencies_percentile_mean: mean(value.latencies_percentile)]
| every 1m
| group_by [metric.policy_name, metric.percentile],
[value_latencies_percentile_mean_aggregate:
aggregate(value_latencies_percentile_mean)]
|
|
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 de funcionamento 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 escrita do Cassandra
Exemplo de utilização: a métrica SLI 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, no percentil 95 ou no 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 99.º percentil 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
Contagem 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 |
| Synchronizer | apigee-synchronizer |
| Telemetria | apigee-prometheus-appapigee-prometheus-proxyapigee-prometheus-aggapigee-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,
o disco de dados estar 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 em 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)] |
|