Como migrar para as métricas de carga de trabalho do GKE a partir do arquivo secundário do Stackdriver Prometheus

Neste tutorial, descrevemos como migrar um pipeline de coleta de métricas com base no arquivo secundário do Stackdriver Prometheus para métricas de carga de trabalho do Google Kubernetes Engine (GKE) totalmente gerenciadas. Há muitos benefícios em usar as métricas de carga de trabalho do GKE em vez do arquivo secundário do Stackdriver Prometheus:

  • Configuração fácil: com um único comando kubectl para implantar um recurso personalizado do PodMonitor, você pode começar a coletar métricas.
  • Altamente configurável: ajuste os endpoints de raspagem de dados, a frequência e outros parâmetros.
  • Totalmente gerenciado: o Google mantém o pipeline, reduzindo o custo total de propriedade.
  • Controle de custos: gerencie os custos do Cloud Monitoring com facilidade com filtros de métricas flexíveis.
  • Padrão aberto: configure as métricas de carga de trabalho utilizando o recurso personalizado PodMonitor, que é modelado após o recurso PodMonitor do Operador Prometheus.
  • Compatibilidade com o HPA: compatível com o adaptador de métricas personalizadas do Stackdriver para ativar o escalonamento automático horizontal em métricas personalizadas.
  • Preços melhores: preços mais intuitivos, previsíveis e baixos.
  • Suporte ao Autopilot: as métricas de carga de trabalho do GKE estão disponíveis para clusters do GKE Standard e do GKE Autopilot.

Confirmar a utilização do arquivo secundário do Stackdriver Prometheus

Anteriormente, o arquivo secundário do Stackdriver Prometheus era a abordagem recomendada para coletar métricas no estilo do Prometheus a partir de clusters do GKE e processá-las no Cloud Monitoring. Nessa abordagem, uma instalação atual do Prometheus, normalmente executada como um StatefulSet ou implantação no GKE é corrigida com um arquivo secundário que exporta todas as métricas raspadas para o Cloud Monitoring. O gráfico Prometheus Helm oferece uma maneira conveniente de configurar essa integração.

Determinar se as métricas de carga de trabalho do GKE abrangem seu uso

A lista de verificação a seguir pode ajudar a determinar se você usa algum dos recursos da abordagem do arquivo secundário do Stackdriver Prometheus que não pode ser reproduzido usando métricas de carga de trabalho do GKE.

Recurso Suporte/soluções alternativas
O Prometheus está sendo usado para monitorar algo que não seja pods no mesmo cluster? Para determinar isso, busque pela utilização de:
  • static_config
  • qualquer plug-in de descoberta de serviços que não seja kubernetes_sd_config
  • qualquer papel kubernetes_sd_config diferente de endpoint ou pod
  • api_server ou kubeconfig sendo utilizado para apontar para um cluster diferente do Kubernetes
O papel pod é tem suporte imediato. O papel endpoint pode ser simulado ao expor e nomear a porta.
Os pods estão sendo selecionados com base em campos em vez de rótulos? Use um seletor de rótulo equivalente, que pode exigir a adição de novos rótulos aos pods desejados.
O Prometheus está configurado com qualquer forma de autorização HTTP ou TLS mútuo para raspagem de dados? Esse recurso não é compatível com as métricas de carga de trabalho do GKE.
O Prometheus está configurado com metric_relabel_configs que utilizam ações diferentes de keep e drop? Esse recurso não é compatível com as métricas de carga de trabalho do GKE.
Você usa os recursos Agregador de contagem ou renomeação de métricas do arquivo secundário do Stackdriver Prometheus? Esse recurso não é compatível com as métricas de carga de trabalho do GKE.
Sua configuração do Prometheus inclui alertas? Converta-as em alertas no Monitoring.
Sua configuração de arquivo secundário inclui static_metadata? As métricas de carga de trabalho do GKE coletam suas métricas, mas desconsideram a documentação.

Migrar a configuração do Prometheus para os recursos personalizados do PodMonitor

Para cada job (item na matriz scrape_configs) definido na configuração do Prometheus, crie um recurso personalizado do PodMonitor correspondente. Veja um exemplo ilustrativo:

Configuração do Prometheus CRD do PodMonitor

scrape_configs:
- job_name: example
  metrics_path: /metrics
  scheme: http
  scrape_interval: 20s
  kubernetes_sd_configs:
  - role: endpoints
    namespaces:
      names:
      - gke-workload-metrics
    selectors:
    - role: endpoints
      label: "app=prom-example"
      field: "port=metrics-port"

apiVersion: monitoring.gke.io/v1alpha1
kind: PodMonitor
metadata:
  name: example
spec:
  namespaceSelector:
    matchNames:
    - gke-workload-metrics
  selector:
    matchLabels:
      app: prom-example
  podMetricsEndpoints:
  - port: metrics-port
    path: /metrics
    scheme: http
    interval: 20s

Migrar a configuração do arquivo secundário para os recursos personalizados do PodMonitor

Os filtros configurados no nível do arquivo secundário se aplicam a todos os jobs de raspagem de dados. Como resultado, é necessário anexar essas configurações a cada CRD do PodMonitor criado na etapa anterior.

CLI do arquivo secundário CRD do PodMonitor

$ stackdriver-prometheus-sidecar \
--include='metric_name{label="foo"}'

apiVersion: monitoring.gke.io/v1alpha1
kind: PodMonitor
metadata:
  name: example
spec:
  namespaceSelector:
    matchNames:
    - gke-workload-metrics
  selector:
    matchLabels:
      app: prom-example
  podMetricsEndpoints:
  - port: metrics-port
    path: /metrics
    scheme: http
    interval: 20s
    metricRelabelings:
      - sourceLabels: [__name__, label]
        regex: "^metric_name;foo$"
        action: keep
      - sourceLabels: [__name__]

Ver métricas no Google Cloud Monitoring

Use o Metrics Explorer para verificar se a métrica foi ingerida pelo pipeline de métricas da carga de trabalho do GKE.

Se a métrica era anteriormente chamada de external.googleapis.com/prometheus/metric_name, agora se chama workload.googleapis.com/metric_name. Lembre-se de modificar todos os painéis ou alertas que dependem dessas métricas para usar o novo esquema de nomenclatura.