Como usar a geração de registros e o monitoramento

Version 1.14 

• Versão mais recente
• Versão 1.16
• Versões anteriores (sem suporte)

Nesta página, explicamos como usar o Cloud Logging, o Cloud Monitoring, o Prometheus e o Grafana para gerar registros e monitorar a implementação do GKE no VMware. Para um resumo das opções de configuração disponíveis, consulte Visão geral de geração de registros e monitoramento.

Como usar o Cloud Logging e o Cloud Monitoring

As seções a seguir explicam como usar o Cloud Logging e o Cloud Monitoring com clusters do GKE no VMware.

Recursos monitorados

Os recursos monitorados são a forma como o Google representa recursos, como clusters, nós, pods e contêineres. Para saber mais, consulte a documentação dos tipos de recursos monitorados do Cloud Monitoring.

Para consultar registros e métricas, você precisa conhecer pelo menos estes rótulos de recursos:

• project_id: ID do projeto do projeto logging-monitoring do ID do cluster. Você forneceu esse valor no campo stackdriver.projectID do arquivo de configuração do cluster.

• location: uma região do Google Cloud em que você quer armazenar registros do Cloud Logging e métricas do Cloud Monitoring. É recomendável escolher uma região próxima ao seu data center local. Você forneceu esse valor durante a instalação no campo stackdriver.clusterLocation do arquivo de configuração do cluster.

• cluster_name: nome que você escolheu quando criou o cluster.

  É possível recuperar o valor cluster_name do administrador ou do cluster de usuário inspecionando o recurso personalizado do Stackdriver:

  kubectl get stackdriver stackdriver --namespace kube-system \
  --kubeconfig CLUSTER_KUBECONFIG --output yaml | grep 'clusterName:'
  

  onde

  • CLUSTER_KUBECONFIG é o caminho para o arquivo kubeconfig do cluster de administrador ou do cluster de usuário para o qual o nome do cluster é necessário.

Como acessar dados de registro

É possível acessar registros usando o Explorador de registros no console do Google Cloud. Por exemplo, para acessar os registros de um contêiner:

1. Abra o Visualizador de registros do seu projeto no console do Google Cloud.
2. Encontre registros de um contêiner:
   1. Clique na caixa suspensa do catálogo de registros no canto superior esquerdo e selecione Contêiner do Kubernetes.
   2. Selecione o nome do cluster, o namespace e um contêiner da hierarquia.

Como ver registros de controladores no cluster de inicialização

1. Encontre o nome do pod onprem-admin-cluster-controller / clusterapi-controllers

   Por padrão, o nome do cluster de tipo é gkectl-bootstrap-cluster.

   "ADMIN_CLUSTER_NAME"
   resource.type="k8s_container"
   resource.labels.cluster_name="gkectl-bootstrap-cluster"
   

2. Modifique a consulta usando o nome do pod encontrado e receba o registro

   resource.type="k8s_container"
   resource.labels.cluster_name="gkectl-bootstrap-cluster"
   resource.labels.pod_name="POD_NAME"
   

Como criar painéis para monitorar a integridade do cluster

Por padrão, os clusters do GKE no VMware são configurados para monitorar as métricas do sistema e do contêiner. Depois de criar um cluster (de administrador ou de usuário), uma prática recomendada é criar os seguintes painéis com o Cloud Monitoring para permitir que a equipe de operações do GKE no VMware monitore a integridade do cluster:

• Painel de tempo de atividade do plano de controle
• Painel de status do pod
• Painel de status do nó
• Painel de status de integridade da VM
• Painel de utilização do nó
• Painel de utilização do Anthos

Se o cluster também executa nós do Windows Server OS, crie os seguintes painéis para monitorar o status dos nós e pods do Windows:

• Painel de status de nós do Windows
• Painel de status do pod do Windows

Os painéis serão criados automaticamente durante a instalação do cluster de administrador se o Cloud Monitoring estiver ativado.

Nesta seção, você verá como criar esses painéis. Para mais informações sobre o processo de criação de painéis descrito nas seções a seguir, consulte Como gerenciar painéis por API.

Pré-requisitos

Sua Conta do Google precisa ter as seguintes permissões para criar painéis:

• monitoring.dashboards.create
• monitoring.dashboards.delete
• monitoring.dashboards.update

Você terá essas permissões se sua conta tiver um dos papéis a seguir. É possível verificar suas permissões (no console do Google Cloud):

• monitoring.dashboardEditor
• monitoring.editor
• Projeto editor
• Projeto owner

Além disso, para usar a gcloud (gcloud CLI) para criar painéis, a Conta do Google precisa ter a permissão serviceusage.services.use.

Sua conta terá essa permissão se tiver um dos seguintes papéis:

• roles/serviceusage.serviceUsageConsumer
• roles/serviceusage.serviceUsageAdmin
• roles/owner
• roles/editor
• Projeto editor
• Projeto owner

Criar um painel de tempo de atividade do plano de controle

O plano de controle do GKE no VMware consiste no servidor de API, no programador, no gerenciador do controlador e no etcd. Para monitorar o status do plano de controle, crie um painel que monitore o estado desses componentes.

1. Faça o download da configuração do painel: control-plane-uptime.json.

2. Crie um painel personalizado com o arquivo de configuração executando o seguinte comando:

   gcloud monitoring dashboards create --config-from-file=control-plane-uptime.json

3. No Console do Google Cloud, selecione Monitoring ou use o seguinte botão:

   Acessar Monitoring

4. Selecione Recursos > Painéis e veja o painel chamado Tempo de atividade do plano de controle do GKE On-Prem. O tempo de atividade do plano de controle de cada cluster de usuário é coletado de namespaces separados no cluster de administrador. O campo namespace_name é o nome do cluster de usuário.

5. Como opção, crie políticas de alertas.

   Clique para ver um painel de exemplo.

   

Criar um painel de status do pod

Para criar um painel que inclua a fase de cada pod, além dos tempos de reinicialização e do uso de recursos de cada contêiner, execute as etapas a seguir.

1. Faça o download da configuração do painel: pod-status.json.

2. Crie um painel personalizado com o arquivo de configuração executando o seguinte comando:

   gcloud monitoring dashboards create --config-from-file=pod-status.json

3. No Console do Google Cloud, selecione Monitoring ou use o seguinte botão:

   Acessar Monitoring

4. Selecione Recursos > Painéis e veja o painel chamado Status do pod do GKE On-Prem.

5. Como opção, crie políticas de alertas.

   Clique para ver um painel de exemplo.

   

Criar um painel de status do nó

Para criar um painel de status do nó para monitorar a condição do nó, a CPU, a memória e o uso do disco, execute as seguintes etapas:

1. Faça o download da configuração do painel: node-status.json.

2. Crie um painel personalizado com o arquivo de configuração executando o seguinte comando:

   gcloud monitoring dashboards create --config-from-file=node-status.json

3. No Console do Google Cloud, selecione Monitoring ou use o seguinte botão:

   Acessar Monitoring

4. Selecione Recursos > Painéis e veja o painel chamado Status do nó do GKE On-Prem.

5. Como opção, crie políticas de alertas.

   Clique para ver um painel de exemplo.

   

Crie um painel de status de integridade da VM

Um painel de status de integridade da VM monitora sinais de contenção de recursos de CPU, memória e disco para VMs no cluster de administrador e em clusters de usuário.

Para criar um painel de status de integridade da VM:

1. Verifique se stackdriver.disableVsphereResourceMetrics está definido como falso. Consulte Arquivo de configuração do cluster do usuário.

2. Faça o download da configuração do painel: vm-health-status.json.

3. Crie um painel personalizado com o arquivo de configuração executando o seguinte comando:

   gcloud monitoring dashboards create --config-from-file=vm-health-status.json

4. No Console do Google Cloud, selecione Monitoring ou use o seguinte botão:

   Acessar Monitoring

5. Selecione Recursos > Painéis e veja o painel chamado Status de integridade da VM do GKE On-Prem.

6. Como opção, crie políticas de alertas.

   Clique para ver um painel de exemplo.

   

Criar um painel de utilização de nós

Um painel de utilização de nós mostra a seguinte utilização no cluster:

• Proporção de alocação de CPU do nó
• vCPUs disponíveis para programar a carga de trabalho do Kubernetes
• Proporção de alocação de memória do nó
• Memória disponível para programar a carga de trabalho do k8s
• Proporção de utilização do disco do nó

Para criar um painel de utilização de nós:

1. Faça o download da configuração do painel: node-utilization.json.

2. Use esse arquivo de configuração para criar um painel personalizado executando o seguinte comando:

   gcloud monitoring dashboards create --config-from-file=node-utilization.json

3. No Console do Google Cloud, selecione Monitoring ou use este botão:

   Acessar Monitoring

4. Selecione Recursos > Painéis e veja o painel chamado Uso do nó do GKE On-Prem.

5. Como opção, crie políticas de alertas.

Criar um painel de medição de uso do Anthos

Um painel de medição de uso do Anthos mostra o uso de CPU e memória nos clusters por namespace e rótulos de pod.

Para criar um painel de medição de uso do Anthos:

1. Faça o download da configuração do painel: anthos-utilization.json.

2. Use esse arquivo de configuração para criar um painel personalizado executando o seguinte comando:

   gcloud monitoring dashboards create --config-from-file=anthos-utilization.json

3. No Console do Google Cloud, selecione Monitoring ou use este botão:

   Acessar Monitoring

4. Selecionar Recursos > Painéis e ver o painel chamado Medição de utilização do Anthos.

5. Como opção, crie políticas de alertas.

   Clique para ver um painel de exemplo.

   

Como visualizar dados de monitoramento no nível da frota

Para ter uma visão geral da utilização de recursos da sua frota usando dados do Cloud Monitoring, incluindo o GKE no VMware, use a visão geral do GKE Enterprise no console do Google Cloud. Consulte Usar a visão geral do GKE Enterprise para saber mais.

Como configurar recursos do componente Stackdriver

Quando você cria um cluster, o GKE no VMware cria automaticamente um recurso personalizado do Stackdriver. É possível editar a especificação no recurso personalizado para substituir os valores padrão das solicitações e limites de CPU e memória de um componente do Stackdriver, além de substituir separadamente o tamanho de armazenamento e a classe de armazenamento padrão.

Substituir valores padrão para solicitações e limites para CPU e memória

Para substituir esses padrões, faça o seguinte:

1. Abra o recurso personalizado do Stackdriver em um editor de linha de comando:

   kubectl --kubeconfig=KUBECONFIG -n kube-system edit stackdriver stackdriver

   KUBECONFIG é o caminho para o arquivo kubeconfig do cluster. Pode ser um cluster de administrador ou um cluster de usuário.

2. No recurso personalizado do Stackdriver, adicione o campo resourceAttrOverride na seção spec:

   resourceAttrOverride:
         POD_NAME_WITHOUT_RANDOM_SUFFIX/CONTAINER_NAME:
           LIMITS_OR_REQUESTS:
             RESOURCE: RESOURCE_QUANTITY

   Observe que o campo resourceAttrOverride substitui todos os limites e solicitações padrão existentes do componente que você especificar. Um arquivo de exemplo será parecido com o seguinte:

   apiVersion: addons.gke.io/v1alpha1
   kind: Stackdriver
   metadata:
     name: stackdriver
     namespace: kube-system
   spec:
     projectID: my-project
     clusterName: my-cluster
     clusterLocation: us-west-1a
     resourceAttrOverride:
       stackdriver-prometheus-k8s/prometheus-server:
         limits:
           cpu: 500m
           memory: 3000Mi
         requests:
           cpu: 300m
           memory: 2500Mi

3. Salve as alterações e saia do editor da linha de comando.

4. Verifique a integridade dos pods:

   kubectl --kubeconfig=KUBECONFIG -n kube-system get pods | grep stackdriver

   Por exemplo, um pod íntegro se parece com o seguinte:

   stackdriver-prometheus-k8s-0                                2/2     Running   0          5d19h

5. Para verificar a especificação do pod do componente para garantir que os recursos estão configurados corretamente:

   kubectl --kubeconfig=KUBECONFIG -n kube-system describe pod POD_NAME

   em que POD_NAME é o nome do pod que você acabou de alterar. Por exemplo, stackdriver-prometheus-k8s-0

   A resposta é semelhante a esta:

     Name:         stackdriver-prometheus-k8s-0
     Namespace:    kube-system
     ...
     Containers:
       prometheus-server:
         Limits:
           cpu: 500m
           memory: 3000Mi
         Requests:
           cpu: 300m
           memory: 2500Mi
         ...
         

Modificar padrões de tamanho do armazenamento

Para substituir esses padrões, faça o seguinte:

1. Abra o recurso personalizado do Stackdriver em um editor de linha de comando:

   kubectl --kubeconfig=KUBECONFIG -n kube-system edit stackdriver stackdriver

2. Adicione o campo storageSizeOverride na seção spec. É possível usar o componente stackdriver-prometheus-k8s ou stackdriver-prometheus-app. A seção tem este formato:

   storageSizeOverride:
   STATEFULSET_NAME: SIZE
   

   Este exemplo usa o statefulset stackdriver-prometheus-k8s e o tamanho 120Gi.

   apiVersion: addons.gke.io/v1alpha1
   kind: Stackdriver
   metadata:
     name: stackdriver
     namespace: kube-system
   spec:
     projectID: my-project
     clusterName: my-cluster
     clusterLocation: us-west-1a
     storageSizeOverride:
       stackdriver-prometheus-k8s: 120Gi
     

3. Salve e saia do editor da linha de comando.

4. Verifique a integridade dos pods:

   kubectl --kubeconfig=KUBECONFIG -n kube-system get pods | grep stackdriver

   Por exemplo, um pod íntegro se parece com o seguinte:

   stackdriver-prometheus-k8s-0                                2/2     Running   0          5d19h

5. Verifique a especificação do pod do componente para garantir que o tamanho do armazenamento seja modificado corretamente.

   kubectl --kubeconfig=KUBECONFIG -n kube-system describe statefulset STATEFULSET_NAME

   A resposta é semelhante a esta:

   Volume Claims:
    Name:          my-statefulset-persistent-volume-claim
    StorageClass:  my-storage-class
    Labels:
    Annotations:
    Capacity:      120Gi
    Access Modes:  [ReadWriteOnce]          

Substituir os padrões da classe de armazenamento

Pré-requisito

Primeiro, é preciso criar um StorageClass que você queira usar.

Para modificar a classe de armazenamento padrão nos volumes permanentes reivindicados pelos componentes do Logging e do Monitoring:

1. Abra o recurso personalizado do Stackdriver em um editor de linha de comando:

   kubectl --kubeconfig=KUBECONFIG -n kube-system edit stackdriver stackdriver

   KUBECONFIG é o caminho para o arquivo kubeconfig do cluster. Pode ser um cluster de administrador ou um cluster de usuário.

2. Adicione o campo storageClassName à seção spec:

   storageClassName: STORAGECLASS_NAME

   Observe que o campo storageClassName modifica a classe de armazenamento padrão atual e se aplica a todos os componentes do Logging e do Monitoring com volumes permanentes reivindicados. Um arquivo de exemplo será parecido com o seguinte:

   apiVersion: addons.gke.io/v1alpha1
   kind: Stackdriver
   metadata:
     name: stackdriver
     namespace: kube-system
   spec:
     projectID: my-project
     clusterName: my-cluster
     clusterLocation: us-west-1a
     proxyConfigSecretName: my-secret-name
     enableVPC: 
     optimizedMetrics: true
     storageClassName: my-storage-class

3. Salve as alterações.

4. Verifique a integridade dos pods:

   kubectl --kubeconfig=KUBECONFIG -n kube-system get pods | grep stackdriver

   Por exemplo, um pod íntegro se parece com o seguinte:

   stackdriver-prometheus-k8s-0                                1/1     Running   0          5d19h

5. Verifique a especificação do pod de um componente para garantir que a classe de armazenamento esteja definida corretamente.

   kubectl --kubeconfig=KUBECONFIG -n kube-system describe statefulset STATEFULSET_NAME

   Por exemplo, usando o conjunto com estado stackdriver-prometheus-k8s, a resposta será assim:

   Volume Claims:
    Name:          stackdriver-prometheus-data
    StorageClass:  my-storage-class
    Labels:
    Annotations:
    Capacity:      120Gi
    Access Modes:  [ReadWriteOnce]          

Desativar métricas otimizadas

Por padrão, os agentes de métricas em execução no cluster coletam e informam um conjunto otimizado de métricas de contêiner, do kubelet e do kube-state-metrics para o Stackdriver. Se você precisar de mais métricas, recomendamos que encontre uma substituição na lista de métricas do GKE Enterprise.

Veja alguns exemplos de substituições que podem ser usadas:

Métrica desativada	Substituição
kube_pod_start_time	container/uptime
kube_pod_container_resource_requests	container/cpu/request_cores container/memory/request_bytes
kube_pod_container_resource_limits	container/cpu/limit_cores container/memory/limit_bytes

Para desativar a configuração padrão das métricas otimizadas do kube-state-metrics (não recomendado), faça o seguinte:

1. Abra o recurso personalizado do Stackdriver em um editor de linha de comando:

   kubectl --kubeconfig=KUBECONFIG -n kube-system edit stackdriver stackdriver

   KUBECONFIG é o caminho para o arquivo kubeconfig do cluster. Pode ser um cluster de administrador ou um cluster de usuário.

2. Defina o campo optimizedMetrics como false:

   apiVersion: addons.gke.io/v1alpha1
   kind: Stackdriver
   metadata:
     name: stackdriver
     namespace: kube-system
   spec:
     projectID: my-project
     clusterName: my-cluster
     clusterLocation: us-west-1a
     proxyConfigSecretName: my-secret-name
     enableVPC: 
     optimizedMetrics: false
     storageClassName: my-storage-class

3. Salve as alterações e saia do editor da linha de comando.

Como acessar dados de métricas

É possível escolher entre mais de 1.500 métricas usando o Metrics Explorer. Para acessar o Metrics Explorer, faça o seguinte:

1. No Console do Google Cloud, selecione Monitoring ou use o seguinte botão:

   Acessar Monitoring

2. Selecione Recursos > Metrics Explorer.

Como acessar os metadados do Monitoring

Os metadados são usados indiretamente por meio de métricas. Ao filtrar métricas no Metrics Explorer do Monitoring, você verá opções para filtrar métricas por metadata.systemLabels e metadata.userLabels. Os rótulos do sistema são rótulos como o nome do nó e o nome do serviço para os pods. Os rótulos de usuário são atribuídos a pods nos arquivos YAML do Kubernetes na seção "metadados" da especificação do pod.

Limites de cota padrão do Cloud Monitoring

O monitoramento do GKE no VMware tem um limite padrão de 6.000 chamadas de API por minuto para cada projeto. Se você exceder esse limite, suas métricas poderão não ser exibidas. Se você precisar de um limite de monitoramento maior, solicite um por meio do Console do Google Cloud.

Problema conhecido: condição de erro do Cloud Monitoring

(ID do problema 159761921)

Em determinadas condições, o pod padrão do Cloud Monitoring, implantado por padrão em cada novo cluster, pode não responder. Quando os clusters são atualizados, por exemplo, os dados de armazenamento podem ser corrompidos quando os pods em statefulset/prometheus-stackdriver-k8s forem reiniciados.

Especificamente, o pod de monitoramento stackdriver-prometheus-k8s-0 pode ser ativado em um loop quando dados corrompidos impedem a gravação de prometheus-stackdriver-sidecar no armazenamento do cluster PersistentVolume.

É possível diagnosticar e recuperar manualmente o erro seguindo as etapas abaixo.

Como diagnosticar o erro do Cloud Monitoring

Quando o pod de monitoramento falha, os registros informam o seguinte:

{"log":"level=warn ts=2020-04-08T22:15:44.557Z caller=queue_manager.go:534 component=queue_manager msg=\"Unrecoverable error sending samples to remote storage\" err=\"rpc error: code = InvalidArgument desc = One or more TimeSeries could not be written: One or more points were written more frequently than the maximum sampling period configured for the metric.: timeSeries[0-114]; Unknown metric: kubernetes.io/anthos/scheduler_pending_pods: timeSeries[196-198]\"\n","stream":"stderr","time":"2020-04-08T22:15:44.558246866Z"}

{"log":"level=info ts=2020-04-08T22:15:44.656Z caller=queue_manager.go:229 component=queue_manager msg=\"Remote storage stopped.\"\n","stream":"stderr","time":"2020-04-08T22:15:44.656798666Z"}

{"log":"level=error ts=2020-04-08T22:15:44.663Z caller=main.go:603 err=\"corruption after 29032448 bytes: unexpected non-zero byte in padded page\"\n","stream":"stderr","time":"2020-04-08T22:15:44.663707748Z"}

{"log":"level=info ts=2020-04-08T22:15:44.663Z caller=main.go:605 msg=\"See you next time!\"\n","stream":"stderr","time":"2020-04-08T22:15:44.664000941Z"}

Como se recuperar do erro do Cloud Monitoring

Para recuperar o Cloud Monitoring manualmente:

1. Interrompa o monitoramento do cluster. Reduza o operador stackdriver para evitar a reconciliação do monitoramento:

   kubectl --kubeconfig /ADMIN_CLUSTER_KUBCONFIG --namespace kube-system scale deployment stackdriver-operator --replicas 0

2. Exclua as cargas de trabalho do pipeline de monitoramento:

   kubectl --kubeconfig /ADMIN_CLUSTER_KUBCONFIG --namespace kube-system delete statefulset stackdriver-prometheus-k8s

3. Exclua os PersistentVolumeClaims (PVCs) do pipeline de monitoramento:

   kubectl --kubeconfig /ADMIN_CLUSTER_KUBCONFIG --namespace kube-system delete pvc -l app=stackdriver-prometheus-k8s

4. Reinicie o monitoramento do cluster. Aumente o operador do Stackdriver para reinstalar um novo pipeline de monitoramento e retomar a reconciliação:

   kubectl --kubeconfig /ADMIN_CLUSTER_KUBCONFIG --namespace kube-system scale deployment stackdriver-operator --replicas=1

Prometheus e Grafana

Nas seções a seguir, explicamos como usar o Prometheus e o Grafana com clusters do GKE no VMware.

Como ativar o Prometheus e o Grafana

A partir da versão 1.2 do GKE no VMware, é possível escolher se você quer ativar ou desativar o Prometheus e o Grafana. Em novos clusters de usuários, o Prometheus e o Grafana são desativados por padrão.

1. Seu cluster de usuário tem um objeto do Monitoring chamado monitoring-sample. Abra o objeto para edição:

   kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] edit \
      monitoring monitoring-sample --namespace kube-system

   em que [USER_CLUSTER_KUBECONFIG] é o arquivo kubeconfig do cluster de usuário.

2. Para ativar o Prometheus e o Grafana, defina enablePrometheus como true. Para desativar o Prometheus e o Grafana, defina enablePrometheus como false:

   apiVersion: addons.gke.io/v1alpha1
   kind: Monitoring
   metadata:
    labels:
      k8s-app: monitoring-operator
    name: monitoring-sample
    namespace: kube-system
   spec:
    channel: stable
    ...
    enablePrometheus: true

3. Salve as alterações fechando a sessão de edição.

Problema conhecido

Nos clusters do usuário, o Prometheus e o Grafana são desativados automaticamente durante o upgrade. No entanto, os dados de configuração e métricas não são perdidos.

Para contornar esse problema, depois do upgrade, abra monitoring-sample para edição e defina enablePrometheus como true.

Como acessar métricas de monitoramento nos painéis do Grafana

O Grafana exibe métricas coletadas dos clusters. Para visualizar essas métricas, acesse os painéis do Grafana:

1. Receba o nome do pod do Grafana em execução no namespace kube-system de um cluster de usuário:

   kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] -n kube-system get pods

   em que [USER_CLUSTER_KUBECONFIG] é o arquivo kubeconfig do cluster de usuário.

2. O pod do Grafana tem um servidor HTTP usando a porta TCP localhost 3000. Encaminhe uma porta local para a porta 3000 no pod a fim de visualizar os painéis do Grafana em um navegador da Web.

   Por exemplo, suponha que o nome do pod seja grafana-0. Para encaminhar a porta 50000 para a porta 3000 no pod, digite este comando:

   kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] -n kube-system port-forward grafana-0 50000:3000

3. Em um navegador da Web, acesse http://localhost:50000.

4. Na página de login, digite admin para nome de usuário e senha.

5. Se o login for concluído, você verá uma solicitação para alterar a senha. Depois de alterar a senha padrão, o painel inicial do Grafana do cluster de usuário será carregado.

6. Para acessar outros painéis, clique no menu suspenso Página inicial no canto superior esquerdo da página.

Para um exemplo de uso do Grafana, consulte Criar um painel do Grafana.

Como acessar alertas

O Prometheus Alertmanager coleta alertas do servidor do Prometheus. É possível ver esses alertas em um painel do Grafana. Para ver os alertas, acesse o painel:

1. O contêiner no pod alertmanager-0 detecta atividade na porta TCP 9093. Encaminhe uma porta local para a porta 9093 no pod:

   kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] port-forward \
      -n kube-system alertmanager-0 50001:9093

2. Em um navegador da Web, acesse http://localhost:50001.

Como alterar a configuração do Prometheus Alertmanager

É possível alterar a configuração padrão do Prometheus Alertmanager editando o arquivo monitoring.yaml do cluster de usuário. Faça isso se quiser direcionar alertas para um destino específico, em vez de mantê-los no painel. Saiba como configurar o Alertmanager na documentação de Configuração do Prometheus.

Para alterar a configuração do Alertmanager, execute as seguintes etapas:

1. Faça uma cópia do arquivo de manifesto monitoring.yaml do cluster de usuário:

   kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] -n kube-system \
      get monitoring monitoring-sample -o yaml > monitoring.yaml

2. Para configurar o Alertmanager, faça alterações nos campos em spec.alertmanager.yml. Quando terminar, salve o manifesto alterado.

3. Aplique o manifesto ao cluster:

   kubectl apply --kubeconfig [USER_CLUSTER_KUBECONIFG] -f monitoring.yaml

Como escalonar recursos do Prometheus

A configuração de monitoramento padrão é compatível com até cinco nós. Para clusters maiores, é possível ajustar os recursos do servidor do Prometheus. A recomendação é de 50 milhões de núcleos de CPU e 500 Mi de memória por nó de cluster. Verifique se o cluster contém dois nós, cada um com recursos suficientes para caber no Prometheus. Para mais informações, consulte Como redimensionar um cluster de usuário.

Para alterar os recursos do servidor do Prometheus, execute as seguintes etapas:

1. Faça uma cópia do arquivo de manifesto monitoring.yaml do cluster de usuário:

   kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] -n kube-system get monitoring monitoring-sample -o yaml > monitoring.yaml

2. Para modificar recursos, faça alterações nos campos em spec.resourceOverride. Quando terminar, salve o manifesto alterado. Exemplo:

   spec:
     resourceOverride:
     - component: Prometheus
       resources:
         requests:
           cpu: 300m
           memory: 3000Mi
         limits:
           cpu: 300m
           memory: 3000Mi
   

3. Aplique o manifesto ao cluster:

   kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] apply -f monitoring.yaml

Criar um painel do Grafana

Você implantou um aplicativo que expõe uma métrica, verificou se ela foi exposta e verificou se o Prometheus extrai a métrica. Agora é possível adicionar a métrica no nível do aplicativo a um painel personalizado do Grafana.

Para criar um painel do Grafana, siga estas etapas:

1. Se necessário, tenha acesso ao Grafana.
2. No painel inicial, clique no menu suspenso Início no canto superior esquerdo da página.
3. No menu lateral direito, clique em Novo painel.
4. Na seção Novo painel, clique em Gráfico. Um painel de gráfico vazio é exibido.
5. Clique em Título do painel e, depois, em Editar. O painel inferior Gráfico é aberto na guia Métricas.
6. No menu suspenso Fonte de dados, selecione usuário. Clique em Adicionar consulta e insira foo no campo pesquisa.
7. Clique no botão Voltar para o painel no canto superior direito da tela. O painel é exibido.
8. Para salvar o painel, clique em Salvar painel no canto superior direito da tela. Escolha um nome para o painel e clique em Salvar.

Como desativar o monitoramento no cluster

Para desativar o monitoramento no cluster, reverta as alterações feitas no objeto monitoring-sample:

1. Abra o objeto monitoring-sample para edição:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG edit \
      monitoring monitoring-sample --namespace kube-system

   Substitua USER_CLUSTER_KUBECONFIG pelo arquivo kubeconfig do cluster de usuário.

2. Para desativar o Prometheus e o Grafana, defina enablePrometheus como false:

      apiVersion: addons.gke.io/v1alpha1
      kind: Monitoring
      metadata:
        labels:
          k8s-app: monitoring-operator
        name: monitoring-sample
        namespace: kube-system
      spec:
        channel: stable
        ...
        enablePrometheus: false
   

3. Salve as alterações fechando a sessão de edição.

4. Confirme se os statefulsets prometheus-0, prometheus-1 e grafana-0 foram excluídos:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods --namespace kube-system

Exemplo: como adicionar métricas no nível do aplicativo a um painel do Grafana

As seções a seguir explicam como adicionar métricas em um aplicativo. Nesta seção, você concluirá as seguintes tarefas:

• Implantar um aplicativo de exemplo que exponha uma métrica chamada foo.
• Verificar se o Prometheus expõe e extrai a métrica.
• Criar um painel personalizado do Grafana.

Implantar o aplicativo de exemplo

O aplicativo de exemplo é executado em um único pod. O contêiner do pod expõe uma métrica, foo, com um valor constante de 40.

Crie o seguinte manifesto do pod, pro-pod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: prometheus-example
  annotations:
    prometheus.io/scrape: 'true'
    prometheus.io/port: '8080'
    prometheus.io/path: '/metrics'
spec:
  containers:
  - image: registry.k8s.io/prometheus-dummy-exporter:v0.1.0
    name: prometheus-example
    command:
    - /bin/sh
    - -c
    - ./prometheus_dummy_exporter --metric-name=foo --metric-value=40 --port=8080

Em seguida, aplique o manifesto do pod ao cluster de usuário:

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] apply -f pro-pod.yaml

Verificar se a métrica foi exposta e extraída

1. O contêiner no pod prometheus-example detecta atividade na porta TCP 8080. Encaminhe uma porta local para a porta 8080 no pod:

   kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] port-forward prometheus-example 50002:8080

2. Para verificar se o aplicativo expõe a métrica, execute o seguinte comando:

   curl localhost:50002/metrics | grep foo
   

   O comando retorna a seguinte saída:

   # HELP foo Custom metric
   # TYPE foo gauge
   foo 40

3. O contêiner no pod prometheus-0 detecta atividade na porta TCP 9090. Encaminhe uma porta local para a porta 9090 no pod:

   kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] port-forward prometheus-0 50003:9090

4. Para verificar se o Prometheus está extraindo a métrica, acesse http://localhost:50003/targets, que levará você ao pod prometheus-0 no grupo de destino .prometheus-io-pods

5. Para visualizar métricas no Prometheus, acesse http://localhost:50003/graph. No campo pesquisa, digite foo e clique em Executar. A página deve exibir a métrica.