[Atualização de componente] Novos recursos e método de atualização do Helm v1.1.17 ou Prometheus agent v4.0.0 - Application Real-Time Monitoring Service: Central de Documentação do Alibaba Cloud

O Prometheus agent foi atualizado para a v4.0.0. A versão correspondente do Helm é a v1.1.17. O Prometheus agent v4.0.0 traz diversos novos recursos, melhora a estabilidade da coleta de dados, corrige bugs e otimiza o consumo de recursos.

Importante

Se você utiliza o Prometheus agent v3.x.x, atualize o agente assim que possível. Essas versões possuem recursos não otimizados e podem apresentar riscos de interrupção na coleta de dados.

Alterações da v4.0.0

Tipo de alteração	Descrição
Novo recurso	Crie jobs de coleta de métricas para eventos do cluster. Os eventos do cluster agora aparecem no painel Kubernetes Deployment.
Novo recurso	Instrumente métricas de automonitoramento com base no acordo de nível de serviço (SLA) para estabilizar os dados do painel. Visualize os dados de estabilidade do SLA no painel de automonitoramento.
Novo recurso	O ServiceMonitor agora suporta o método de autenticação BasicAuth. Os Secrets devem estar no mesmo namespace do ServiceMonitor.
Novo recurso	Utilize os recursos de Metrics Metadata para exibir descrições de métricas específicas.
Novo recurso	Envie a versão do Agent Chart ao servidor para inicializar ou atualizar o painel conforme essa versão.
Novo recurso	Monitore métricas de remote write para calcular o tempo gasto no envio de dados em cada lote.
Novo recurso	Colete métricas sobre erros e latência na coleta básica de métricas.
Novo recurso	Obtenha métricas referentes a erros e latência das tarefas fundamentais de coleta.
Otimização	O parâmetro queue_config nas configurações de remote write adota os seguintes valores padrão: min_shards=10, max_samples_per_send=5000 e capacity=10000. Isso aumenta a adaptabilidade em clusters de grande porte.
Otimização	Aprimoramento nos métodos de descoberta de serviços, especialmente nas configurações de PV para coleta de dados via Container Storage Interface (CSI).
Otimização	Ajuste na frequência de distribuição do senderLoop e modificação na frequência do syncWorkersSeries para reduzir interferências desnecessárias.
Otimização	Simplificação de alguns logs. Informações detalhadas, como o tempo consumido na captura de rastreamento, passam a ser exibidas em determinados logs.
Otimização	Configure independentemente o período e o tempo limite de coleta para jobs básicos de métricas, sem depender mais das definições globais. Isso diminui interferências indevidas na coleta de dados essenciais.
Otimização	Melhoria na lógica de interação no modo multi-réplica master-slave. Masters e Workers deixam de se afetar mutuamente, aumentando a estabilidade do sistema.
Otimização	Refinamento da política de distribuição de Targets pelo Master. Essa mudança economiza cerca de 30% de utilização de CPU e 40% de memória, além de melhorar o desempenho da coleta de dados.
Otimização	Aperfeiçoamento do metrics_relabel, reduzindo a utilização de CPU em 70%.
Otimização	Ajuste na lógica de escuta multilocatário do Informer para economizar 20% de CPU em cenários com múltiplos locatários.
Otimização	Uso automático de endereços IP em cache quando o CoreDNS falha na resolução de nomes de domínio em tempo real, elevando a taxa de sucesso na transmissão de dados.
Otimização	Reestruturação da lógica de configuração e distribuição do SendConfig para garantir maior estabilidade nas configurações.
Otimização	Aprimoramento da política de pré-busca do Master para reduzir a sobrecarga de recursos, melhorando a descoberta de serviços e o agendamento de targets.
Otimização	Implementação de controle adaptativo em pacotes de dados que ultrapassam 1 MB por lote, minimizando perdas causadas por restrições do backend.
Correção de bug	Solução para o problema de coleta duplicada em alguns Targets do ScrapeLoop.
Correção de bug	Em cenários multilocatário, os caches de Label dos pods não eram atualizados rapidamente, gerando linhas do tempo duplicadas. Esse comportamento foi corrigido.
Correção de bug	Alguns targets relacionados a erros de falta de memória (OOM) ou reinicialização de réplicas não eram coletados. A falha foi resolvida.
Correção de bug	Corrigidos problemas na análise de Secret e na transmissão de Header via remote write.
Correção de bug	Falha ocasional no encerramento do kubernetes-pods solucionada.
Correção de bug	Os parâmetros padrão globais e o parâmetro external_labels não estavam surtindo efeito. Agora é possível modificá-los corretamente.

Riscos

Risco: A atualização para o Helm v1.1.17 ou Prometheus agent v4.0.0 envolve perda temporária de dados. Pode haver interrupção nos dados de monitoramento. Quanto maior o volume de Targets e Series coletados, maior a probabilidade de desconexão. O tempo estimado de interrupção varia de 0 a 5 minutos, dependendo também das características do cluster.
Antes de atualizar o Helm ou o Prometheus agent, verifique antecipadamente os parâmetros relevantes para minimizar o impacto da atualização nos dados de monitoramento do cluster. Para mais informações, consulte a seção 1. Itens de verificação pré-atualização (obrigatório).
Caso identifique anomalias nos dados após atualizar o Helm ou o Prometheus agent, solucione o problema imediatamente. Para detalhes sobre os itens de verificação, veja a seção 3. Itens de verificação pós-atualização (opcional). Para orientações sobre solução de problemas, acesse a seção FAQ. Se o problema persistir, entre em contato com o suporte técnico (DingTalk ID: aliprometheus).

Método de atualização

1. Itens de verificação prévia (obrigatório)

Ao atualizar o Helm de uma versão anterior à 1.1.16 para a 1.1.17, alguns parâmetros modificados não serão mantidos. Por isso, anote-os e reconfigure-os manualmente.

Se a atualização partir da versão 1.1.16 ou superior para a 1.1.17, todos os parâmetros são preservados. Siga as etapas abaixo para conferir os parâmetros antes de prosseguir:

Faça login no console do Container Service for Kubernetes (ACK).
Clique no nome do cluster. No painel de navegação à esquerda, selecione Workloads > Deployments. Defina o parâmetro Namespace como arms-prom. Localize arms-prometheus-ack-arms-prometheus, escolha More > View in YAML na coluna Actions para visualizar o arquivo yaml completo.
Verifique os seguintes parâmetros:
- spec.replicas: quantidade de réplicas. O Helm v1.1.17 e o Prometheus agent v4.0.0 definem 1 como valor padrão. Caso o valor atual já seja 1, ignore este parâmetro.
- args de spec.containers: parâmetro de inicialização. Disponível apenas no modo multilocatário. Se houver um valor personalizado, informe-o novamente após a atualização.
  - tenant_userid
  - tenant_clusterid
  - tenant_token
- spec.containers.resources.limits e spec.containers.resources.requests: O limite padrão de CPU é 3 e o de memória é 4. As solicitações padrão de CPU e memória são ambas 1.
  
  Altere os valores padrão se necessário. Nesse caso, anote as modificações e reconfigure-as manualmente depois da atualização.
Caso precise ajustar e preservar os parâmetros acima, registre os valores. Após atualizar o Helm ou o Prometheus agent, execute a Etapa 2 para obter o arquivo yaml completo, faça as alterações necessárias e clique em Update.

2. Procedimento

Atualize a versão do Helm diretamente pelo console do ACK.

Acesse o console do ACK.
Clique no nome do cluster. No painel de navegação à esquerda, selecione Operations > Add-ons. Clique na aba Logs and Monitoring. Localize ack-arms-prometheus e clique em Upgrade.
Após concluir a atualização, selecione Operations > Prometheus Monitoring no painel de navegação à esquerda. Clique em Go to ARMS Prometheus no canto superior direito. Você será redirecionado ao painel da instância correspondente do Prometheus no console do Managed Service for Prometheus.

No painel de navegação à esquerda, clique em Settings. Na aba Settings, confirme se o Helm foi atualizado para a versão 1.1.17.

3. Itens de verificação pós-atualização (opcional)

Faça login no console do ARMS.
No painel de navegação à esquerda, selecione Managed Service for Prometheus > Instances.
Acesse o console do Cloud Monitor.
No painel de navegação à esquerda, selecione Managed Service for Prometheus > Instances para abrir a lista de instâncias do Managed Service for Prometheus.
Clique no nome da instância do Prometheus. No painel de navegação à esquerda, clique em Service Discovery. Selecione a aba Targets para confirmar se os jobs de coleta foram concluídos conforme esperado.
No painel de navegação à esquerda, clique em Settings. Na aba Self-Monitoring, clique em View Grafana Dashboard. Acompanhe o status do Prometheus agent verificando os seguintes pontos: se a taxa de transmissão de dados está dentro do esperado, se há exceções no envio, se o consumo de recursos segue o padrão previsto e se a quantidade de réplicas está correta.
Na aba Agent self-monitoring, dentro da seção Self-Monitoring, visualize o painel de automonitoramento do agente do Managed Service for Prometheus.

Monitore o andamento dos jobs de coleta observando as métricas básicas: _arms/kubelet/cadvisor, _arms/kubelet/metric, _kube-state-metrics e node-exporter. No canto superior direito da página, selecione um intervalo de tempo para comparar o comportamento antes e depois da atualização e identificar possíveis anomalias.

FAQ

Por que a quantidade real de réplicas em execução após a atualização difere do número esperado?

Verifique se todas as réplicas estão ativas. Caso uma ou mais estejam pendentes, o Prometheus agent não funcionará adequadamente. Para checar o status das réplicas no console do ACK: na página de detalhes do cluster, acesse o painel de navegação à esquerda e selecione Workloads > Deployments. Defina o parâmetro Namespace como arms-prom. Em seguida, visualize o status das réplicas.

Por que o agente do ARMS consome muita memória e CPU após a atualização?

Confira se existem exceções durante o envio de dados. Quando ocorrem falhas nessa etapa, o agente do ARMS armazena informações na memória, elevando o consumo de recursos. Acesse o console do ACK. No painel de navegação à esquerda da página de detalhes do cluster, selecione Operations > Prometheus Monitoring. Na página Prometheus Monitoring, clique na aba Others e, em seguida, na aba Prometheus Agent para verificar o uso de memória e a utilização de CPU.

Por que as métricas básicas apresentam interrupção ou descontinuidade após a atualização?

Suponha que node_ (ícone 1), container_ (ícone 2), kubelet_ (ícone 3) e kube_ (ícone 4) sofram interrupção ou descontinuidade, conforme ilustrado na figura a seguir. Nesse caso, verifique se há mensagens de erro durante a execução dos jobs de coleta de dados. Consulte o status dessas métricas na aba Targets da página Service Discovery no console do Managed Service for Prometheus. Se houver mensagens de erro, entre em contato com o suporte técnico (DingTalk ID: aliprometheus).

Por que o tráfego remoto diminuiu e há perda de dados no remote write?

O campo write_relabel_configs nas configurações de remote write do Prometheus agent v4.0.0 entra em vigor automaticamente, mas não estava disponível na versão anterior. Se você configurar ações como drop e keep, o tráfego cairá proporcionalmente. Ajuste esse campo conforme suas necessidades de negócio. Para editá-lo, clique em Edit Prometheus.yaml na aba Settings da página Settings no console do Managed Service for Prometheus. Modifique o campo na caixa de diálogo exibida.