No último artigo vimos o funcionamento básico do Prometheus e como configurar um servidor Prometheus em um cluster Kubernetes .

(lembrando que estou utilizando um cluster local com Docker Desktop for Mac )

Neste artigo, vamos explorar mais métricas para monitoramento:

Existem diversas fontes (sources) de dados para o Prometheus, mas vamos resumir aqui as principais para um cluster Kubernetes, nomeadamente:

cAdvisor é um agente de monitoramento para containers e tem suporte nativo ao Docker.

Em um cluster Kubernetes, temos a opção de instalar o cAdvisor como uma pod que coleta métricas dos containers.

Entretanto não precisamos disto, uma vez que o componente kubelet do Kubernetes já utiliza e exporta métricas do cAdvisor em um endpoint do cluster.

O node-exporter é um agente para monitoramento dos recursos do nó (máquina), tais como CPU, memória e armazenamento persistente.

Pode ser instalado em um cluster Kubernetes como uma pod que coleta métricas dos nodes do cluster.

Este agente é um add-on que fica à escuta de todos os eventos do Kubernetes API Server, ou seja, qualquer coisa que acontece no cluster é coletada e exportada como métrica.

Tal como os outros agentes, kube-state-metrics pode ser instalado no cluster através de uma pod que fica coletando métricas do API Server.

Após o resumo dos diferentes tipos de sources , vamos neste artigo focar no cAdvisor , deixando os outros para futuros artigos.

É extremamente importante conhecer os tipos de métricas que cada um oferece e fazer o balanço correto de quais sources o Prometheus deve fazer o scraping.

No caso do cAdvisor, que já é utilizando pelo kubelet , vamos criar outro job e utilizar uma configuração dinâmica que muda as labels em tempo de scraping, de forma a deixar mais simples nossas queries.

Como o kubelet exporta as métricas via https , precisamos definir o schema de acesso bem como configuração de tls_config e token de acesso:

  - job_name: kubernetes-nodes-cadvisor
    scheme: https
    tls_config:
      ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
    
Nota: /var/run/secrets/kubernetes.io/serviceaccount/ é o caminho padrão de secrets e certificados de acesso para componentes internos do Kubernetes.
Próximo passo é escolher o role, que é basicamente o tipo de "discover" que o Prometheus deve fazer nas métricas. O Kubernetes oferece vários tipos de roles:
node: informações de containers agrupados por nós (máquinas)
service: containers agrupados por service, bem como informações extras dos services
pod: informações dos containers das pods em si
endpoint: agrupamento por endpoint
ingress: e por fim, agrupamento por ingress, muito útil para monitoramento blackbox
Nosso exemplo passa por criar apenas uma role node, pois queremos informações baseadas no node (% de CPU, % de memória):

    kubernetes_sd_configs:
      - role: node
    - action: labelmap
        regex: __meta_kubernetes_node_label_(.+)
      - target_label: __address__
        replacement: kubernetes.default.svc:443
      - source_labels: [__meta_kubernetes_node_name]
        regex: (.+)
        target_label: __metrics_path__
        replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor
    
Importante: temos que colocar este yaml num configmap e montar no volume da Pod, mas este passo vou deixar como exercício para que o artigo não fique enorme.
Não há motivo para pânico entretanto, tudo o que faço aqui é compartilhado no Github_
Failed to watch *v1.Node: failed to list *v1.Node: nodes is forbidden: User \"system:serviceaccount:monitoring:default\" cannot list resource \"nodes\" in API group \ │
│ "\" at the cluster scope"
    - ingresses
  verbs: ["get", "list", "watch"]
- nonResourceURLs: ["/metrics"]
  verbs: ["get"]
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: prometheus
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus
subjects:
- kind: ServiceAccount
  name: default
  namespace: monitoring # <---- importante
    
Iniciar port-forward novamente e abrir a interface web buscando pela métrica machine_cpu_cores.
Que dia maravilhoso!

  Mais métricas no cAdvisor
Poderíamos ficar o dia todo experimentando métricas, dentre elas:
  container_cpu_usage_seconds_total
Traz de forma multi-dimensional os segundos de utilização da CPU. Isto dá um poder enorme para agruparmos por soma:

sum(container_cpu_usage_seconds_total{namespace="monitoring"})
5.702207
    
Grafana é uma ferramenta de analytics desenvolvida pela Grafana Labs, que permite a criação de widgets em dashboards a partir de "conectores" que trazem métricas. 
Atualmente esta ferramenta suporta diversos conectores, dentre eles nosso amigo Prometheus, portanto esta combinação é poderosa para criarmos dashboards avançadas de monitoramento. 
              "access":"server",
              "editable": true,
              "url": "http://prometheus-svc.monitoring.svc.cluster.local",
              "version": 1
kind: ConfigMap
metadata:
  creationTimestamp: null
  name: grafana-config
  namespace: monitoring
    
E claro, não podemos esquecer de criar um Service para o Prometheus, pois assim a pod do Grafana consegue "conversar" com a pod do Prometheus. 
Nota: lembrando que Services no Kubernetes resolvem problema de discovery de Pods, ok?

apiVersion: v1
kind: Service
metadata:
  name: prometheus-svc
  labels:
    app: prometheus-svc
spec:
  type: NodePort
  selector:
    app: prometheus-pod
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9090
    
$ kubectl -n monitoring port-forward deploy/grafana-pod 3000:3000
Forwarding from 127.0.0.1:3000 -> 3000
Forwarding from [::1]:3000 -> 3000
    
Adicionar panels, widgets e dashboards é uma tarefa que requer bastante paciência e atenção ao detalhe, uma vez que os dados serão a "fonte da verdade". 
Entretanto a comunidade do Grafana vem fazendo um ótimo trabalho desenvolvendo dashboards com várias visualizações e tipos de widgets diferentes, facilitando a importação de dashboards apenas utilizando ID.
Para poupar tempo neste artigo, eu criei uma dashboard do zero com alguns widgets que mostram utilização de CPU e memória, e felizmente é possível exportar uma versão json completa do dashboard, que deixei neste Gist. 
Lembra que falei sobre ter uma dashboard persistida? Pois é, por padrão, containers não compartilham storage com o host, mas Kubernetes permite resolver isto com PersistentVolumes, para então atribuir estes PVs a containers. 
Parece complicado, mas não é. Vamos primeiro criar um StorageClass que representa o tipo de armazenamento.
Cada ambiente tem um tipo de storage provisioner, e no meu caso estou utilizando o Docker for Mac, que tem um provisioner chamado docker.io/hostpath.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
provisioner: docker.io/hostpath
    
Um PersistentVolumeClaim serve para, a partir de um Storage Class, "declarar" o modo de acesso, capacidade, etc. 
And nowww (com sotaque do Supla), "montar" o PVC como volume na Pod:

    spec:
      volumes:            <------ declaração dos volumes
        - name: grafana-persistent-volume
          persistentVolumeClaim:
            claimName: grafana-pvc <---- PVC
      containers:
        - image: ...
          name: grafana
          ports:
            - ...
          volumeMounts:  <--- montar volumes declarados na Pod
            - name: grafana-persistent-volume
              mountPath: /var/lib/grafana
    
Ótimo artigo Leandro. 
Apenas alguns pontos de atenção, na seção "Configurando o Grafana", você chamou o deployment de prometheus-pod.
Na explicação sobre o Grafana, tem um erro na definição da porta: "Abra localhost:300", deveria ser "Abra localhost:3000".
Por fim, uma dúvida que tenho sobre a utilização desse serviço num ambiente real. As métricas coletadas dos exporters devem ser armazenadas pelo Prometheus (usando um PV/PVC), ou na instância do Grafana?
      
Built on Forem — the open source software that powers DEV and other inclusive communities.
      
Made with love and Ruby on Rails. DEV Community © 2016 - 2025.