Como usar o Prometheus

O Prometheus é uma ferramenta de monitoramento opcional usada com frequência no Kubernetes. Se você configurar o Stackdriver Kubernetes Monitoring com o suporte do Prometheus, os serviços que expuserem as métricas no modelo de dados do Prometheus poderão ser exportados do cluster e visualizados como métricas externas no Stackdriver.

Esta página apresenta um mecanismo para o Stackdriver coletar dados de clientes do Prometheus que funcionam com o Stackdriver Kubernetes Engine Monitoring. O código-fonte da integração está disponível publicamente.

Antes de começar

O suporte do Prometheus descrito aqui não funciona com o suporte ao Stackdriver descrito no Stackdriver Monitoring.

Como instalar o coletor

O Stackdriver oferece um coletor que precisa ser implantado como um arquivo secundário no mesmo pod do Kubernetes do servidor Prometheus. Use os comandos do shell a seguir para instalar o coletor do Stackdriver em um novo cluster usando o Stackdriver Kubernetes Engine Monitoring.

Faça login no cluster e execute o seguinte script com as variáveis de ambiente necessárias:

  • KUBE_NAMESPACE: namespace para executar o script.
  • KUBE_CLUSTER: parâmetro do nome do cluster do arquivo secundário.
  • GCP_REGION: parâmetro da região do GCP do arquivo secundário.
  • GCP_PROJECT: parâmetro do projeto do GCP do arquivo secundário.
  • DATA_DIR: diretório de dados do arquivo secundário.
  • DATA_VOLUME: nome do volume que contém dados do Prometheus.
  • SIDECAR_IMAGE_TAG: versão da imagem do Docker do arquivo secundário do Prometheus. É recomendável usar a versão mais recente do Container Registry.
#!/bin/sh

set -e
set -u

usage() {
  echo -e "Usage: $0 <deployment|statefulset> <name>\n"
}

if [  $# -le 1 ]; then
  usage
  exit 1
fi

# Override to use a different Docker image name for the sidecar.
export SIDECAR_IMAGE_NAME=${SIDECAR_IMAGE_NAME:-'gcr.io/stackdriver-prometheus/stackdriver-prometheus-sidecar'}

kubectl -n "${KUBE_NAMESPACE}" patch "$1" "$2" --type strategic --patch "
spec:
  template:
    spec:
      containers:
      - name: sidecar
        image: ${SIDECAR_IMAGE_NAME}:${SIDECAR_IMAGE_TAG}
        imagePullPolicy: Always
        args:
        - \"--stackdriver.project-id=${GCP_PROJECT}\"
        - \"--prometheus.wal-directory=${DATA_DIR}/wal\"
        - \"--stackdriver.kubernetes.location=${GCP_REGION}\"
        - \"--stackdriver.kubernetes.cluster-name=${KUBE_CLUSTER}\"
        #- \"--stackdriver.generic.location=${GCP_REGION}\"
        #- \"--stackdriver.generic.namespace=${KUBE_CLUSTER}\"
        ports:
        - name: sidecar
          containerPort: 9091
        volumeMounts:
        - name: ${DATA_VOLUME}
          mountPath: ${DATA_DIR}
"

Como validar a configuração

Depois de configurar o Prometheus, execute o seguinte comando para validar a instalação:

kubectl -n "${KUBE_NAMESPACE}" get <deployment|statefulset> <name> -o=go-template='{{$output := "stackdriver-prometheus-sidecar does not exists."}}{{range .spec.template.spec.containers}}{{if eq .name "stackdriver-prometheus-sidecar"}}{{$output = (print "stackdriver-prometheus-sidecar exists. Image: " .image)}}{{end}}{{end}}{{printf $output}}{{"\n"}}'

Se o arquivo secundário do Prometheus for instalado com sucesso, a saída do script mostrará:

stackdriver-prometheus-sidecar exists. Image: gcr.io/stackdriver-prometheus/stackdriver-prometheus-sidecar:0.3.2

Se o arquivo secundário do Prometheus não for instalado com sucesso, a saída do script mostrará:

stackdriver-prometheus-sidecar does not exist.

Para verificar se uma carga de trabalho está atualizada e disponível, execute:

kubectl -n "${KUBE_NAMESPACE}" get <deployment|statefulset> <name>

Como atualizar a configuração

Depois de verificar se o coletor foi instalado com sucesso, atualize a configuração do cluster para tornar as alterações permanentes:

  1. Verifique se o servidor do Prometheus está gravando em um volume compartilhado:

    1. Verifique se há um volume compartilhado no pod do Prometheus:

      volumes:
        - name: data-volume
          emptyDir: {}
      
    2. Faça o Prometheus montar o volume em /data:

      volumeMounts:
      - name: data-volume
        mountPath: /data
      
    3. Instrua o servidor do Prometheus a gravar no volume compartilhado em /data. Adicione o seguinte ao contêiner args:

      --storage.tsdb.path=/data
      
  2. Adicione o contêiner do coletor como um arquivo secundário.

    - name: sidecar
      image: gcr.io/stackdriver-prometheus/stackdriver-prometheus-sidecar:[SIDECAR_IMAGE_TAG]
      args:
      - "--stackdriver.project-id=[GCP_PROJECT]"
      - "--prometheus.wal-directory=/data/wal"
      - "--stackdriver.kubernetes.location=[GCP_REGION]"
      - "--stackdriver.kubernetes.cluster-name=[KUBE_CLUSTER]"
      ports:
      - name: sidecar
        containerPort: 9091
      volumeMounts:
      - name: data-volume
        mountPath: /data
    

Para detalhes adicionais de configuração do coletor, consulte a documentação do arquivo secundário do Prometheus no Stackdriver.

Como ver métricas

O software Prometheus instalado está pré-configurado para começar a exportar métricas para o Monitoring como métricas externas. É possível vê-las em Stackdriver > Resources > Metrics Explorer:

ACESSAR O METRICS EXPLORER

No tipo de recurso monitorado Contêiner do Kubernetes (k8s_container), procure as métricas external/prometheus/.... Uma métrica que tem alguns dados interessantes é external/prometheus/go_memstats_alloc_bytes. Se houver mais de um cluster no seu espaço de trabalho, filtre o gráfico pelo nome do cluster, conforme mostrado na captura de tela a seguir:

Gráfico do Prometheus

Problemas de integração do Prometheus

Nenhum dado é mostrado no Stackdriver.

Se nenhum dado for mostrado no Stackdriver depois que você passar pelas etapas de instalação, consulte os registros do coletor em busca de mensagens de erro que possam indicar problemas.

Se os registros não contiverem mensagens de falha óbvias, passe a sinalização -log.level=debug para o coletor a fim de ativar a geração de registros de depuração. Depois de reiniciar o coletor, você começará a ver novas mensagens apontando para a origem do problema.

Estou usando regras de gravação, mas as métricas não são exibidas no Stackdriver.

As regras de gravação exigem processamento especial. Sempre que possível, é recomendável ingerir a métrica bruta nos recursos do Stackdriver e do Stackdriver Monitoring para agregar os dados no momento da consulta (um gráfico, um painel etc.)

Se ingerir a métrica não for uma opção, adicione uma entrada static_metadata na configuração do coletor (docs). Essa opção exige que você preserve job e os rótulos instance. Por exemplo, a configuração atual é válida:

Na configuração do Prometheus Server:

groups:
- name: my-groups
  rules:
  - record: backlog_avg_10m
    expr: avg_over_time(backlog_k8s[10m])
  - record: backlog_k8s
    expr: sum(total_lag) by (app, job, instance)

Na configuração do coletor do Prometheus no Stackdriver:

static_metadata:
  - metric: backlog_avg_10m
    type: gauge

Atualmente, as regras de gravação que alteram ou removem os rótulos job ou instance não são compatíveis.

Faltam os rótulos job e instance do Prometheus nas minhas métricas.

O coletor do Prometheus no Stackdriver cria um MonitoredResource do Stackdriver para seus objetos do Kubernetes a partir de rótulos conhecidos do Prometheus. Se você alterar acidentalmente os descritores de etiqueta, o coletor não poderá gravar as métricas no Stackdriver.

Aparecem os erros "série temporal duplicada" ou "gravações fora de ordem" nos registros.

Esses erros podem ser causados pela gravação de dados de métricas duas vezes na mesma série temporal. Eles poderão ocorrer se os endpoints do Prometheus expuserem os mesmos dados de métricas (o mesmo conjunto de valores de rótulos de métricas) duas vezes a partir de um único recurso monitorado pelo Stackdriver.

Por exemplo, um contêiner do Kubernetes pode expor métricas do Prometheus em várias portas. Como o recurso monitorado k8s_container do Stackdriver não diferencia recursos com base na porta, o Stackdriver detecta que você está gravando dois pontos na mesma série temporal. Uma solução é adicionar um rótulo de métrica ao Prometheus, diferenciando a série temporal. Por exemplo, convém usar o rótulo __meta_kubernetes_pod_annotation_prometheus_io_port, porque ele permanecerá constante nas reinicializações do contêiner.

Aparecem os erros "tipo de métrica precisa ser X, mas é Y" nos registros.

Esses erros são causados pela alteração do tipo de métrica do Prometheus no código-fonte entre o medidor, o contador e outros. As métricas do Stackdriver têm uma forma estrita, e isso é muito reforçado porque a semântica dos dados varia de acordo com o tipo.

Para alterar o tipo de uma métrica, é necessário excluir os descritores correspondentes, o que torna inacessíveis os dados da série temporal atual.

Tenho certeza de que já vi os tipos de métricas do Prometheus antes, mas agora não consigo encontrá-los.

O software Prometheus instalado está pré-configurado para exportar métricas para o Stackdriver Monitoring como métricas externas. Quando os dados são exportados, o Monitoring cria o descritor de métricas apropriado para a métrica externa. Se nenhum dado desse tipo de métrica for gravado posteriormente por pelo menos seis semanas, o descritor de métricas estará sujeito à exclusão.

Não há garantia de que descritores de métricas não utilizados sejam excluídos após seis semanas, mas o Monitoring se reserva o direito de excluir qualquer descritor de métrica do Prometheus que não tenha sido usado nas seis semanas anteriores.

Política de suspensão de uso

A integração do Stackdriver com o Prometheus está sujeita à política de suspensão de uso do Stackdriver.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Stackdriver Monitoring
Precisa de ajuda? Acesse nossa página de suporte.