Configurar a geração de registros e o monitoramento

Neste documento, mostramos como configurar a geração de registros e o monitoramento de componentes do sistema no Google Distributed Cloud (somente software) para VMware.

Por padrão, o Cloud Logging, o Cloud Monitoring e o Google Cloud Managed Service para Prometheus estão ativados.

Para mais informações sobre as opções, consulte Visão geral da geração de registros e monitoramento.

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 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 de geração de registros e monitoramento do cluster. Você forneceu esse valor no campo stackdriver.projectID do arquivo de configuração do cluster.

• location: uma Google Cloud região em que você quer rotear e armazenar suas métricas do Cloud Monitoring. Você especifica a região durante a instalação no campo stackdriver.clusterLocation do arquivo de configuração do cluster. Recomendamos escolher uma região próxima ao seu data center local.

  Você especifica o roteamento e o local de armazenamento dos registros do Cloud Logging na configuração do roteador de registros. Para mais informações sobre o roteamento de registros, consulte Visão geral de roteamento e armazenamento.

• 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.

Roteamento de registros e métricas

O encaminhador de registros do Stackdriver (stackdriver-log-forwarder) envia registros de cada máquina de nó para o Cloud Logging. Da mesma forma, o agente de métricas do GKE (gke-metrics-agent) envia métricas de cada máquina de nó para o Cloud Monitoring. Antes do envio dos registros e métricas, o operador do Stackdriver (stackdriver-operator) anexa o valor do campo clusterLocation no recurso personalizado stackdriver a cada entrada de registro e métrica antes do roteamento para Google Cloud. Além disso, os registros e as métricas são associados ao projeto Google Cloud especificado na especificação do recurso personalizado stackdriver (spec.projectID).

Todas as métricas e entradas de registro enviadas pelos agentes do Stackdriver são encaminhadas para um endpoint de ingestão global. De lá, os dados são encaminhados para o endpoint regional Google Cloud mais próximo para garantir a confiabilidade do transporte de dados.

Depois que o endpoint global recebe a métrica ou a entrada de registro, o que acontece em seguida depende do serviço:

• Como o roteamento de registros é configurado: quando o endpoint de geração de registros recebe uma mensagem de registro, o Cloud Logging passa a mensagem pelo roteador de registros. Os coletores e filtros na configuração do roteador de registros determinam como rotear a mensagem. É possível rotear entradas de registro para destinos como buckets regionais do Logging, que armazenam a entrada de registro, ou para o Pub/Sub. Para mais informações sobre como o roteamento de registros funciona e como configurá-lo, consulte Visão geral de roteamento e armazenamento.

  Nem o campo clusterLocation no recurso personalizado stackdriver nem o campo clusterOperations.location na especificação do cluster são considerados nesse processo de roteamento. Para registros, clusterLocation é usado apenas para rotular entradas de registro, o que pode ser útil para filtrar na Análise de registros.

• Como o encaminhamento de métricas é configurado: quando o endpoint de métricas recebe uma entrada de métrica, ela é encaminhada automaticamente para ser armazenada no local especificado pela métrica. O local na métrica veio do campo clusterLocation no recurso personalizado stackdriver.

• Planeje sua configuração: ao configurar o Cloud Logging e o Cloud Monitoring, configure o roteador de registros e especifique um clusterLocation adequado com locais que atendam melhor às suas necessidades. Por exemplo, se você quiser que os registros e as métricas sejam enviados para o mesmo local, defina clusterLocation como a mesma região Google Cloud que o Gravador de registros está usando para seu projeto Google Cloud .

• Atualize sua configuração quando necessário: você pode fazer mudanças a qualquer momento nas configurações de destino de registros e métricas devido a requisitos comerciais, como planos de recuperação de desastres. As mudanças na configuração do Roteador de registros emGoogle Cloud entram em vigor rapidamente. Os campos location e projectID na seção clusterOperations do recurso Cluster são imutáveis. Portanto, não podem ser atualizados depois que o cluster é criado. Não recomendamos que você mude valores diretamente no recurso stackdriver. Esse recurso é revertido ao estado original de criação do cluster sempre que uma operação de cluster, como um upgrade, aciona uma reconciliação.

Usar o Cloud Logging.

Você não precisa fazer nada para ativar o Cloud Logging em um cluster. No entanto, é preciso especificar o projeto Google Cloud em que você quer ver os registros. No arquivo de configuração do cluster, especifique o projeto Google Cloud na seção stackdriver.

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

1. Abra o Análise de registros no console do Google Cloud para seu projeto.
2. Encontre registros de um contêiner da seguinte maneira:
   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.

Ver registros de controladores no cluster de inicialização

1. No console do Google Cloud , acesse a página segmento Análise de registros:

   Acessar a Análise de registros

   Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Logging.

2. Para ver todos os registros dos controladores no cluster de inicialização, execute a seguinte consulta no editor de consultas:

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

3. Para ver os registros de um pod específico, edite a consulta para incluir o nome dele:

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

Usar o Cloud Monitoring

Você não precisa fazer nada para ativar o Cloud Monitoring em um cluster. No entanto, é preciso especificar o projeto Google Cloud em que você quer ver as métricas. No arquivo de configuração do cluster, especifique o projeto Google Cloud na seção stackdriver.

É 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 botão a seguir:

   Acessar Monitoring

2. Selecione Recursos > Metrics Explorer.

Também é possível ver as métricas nos painéis do console Google Cloud . Para informações sobre como criar painéis e visualizar métricas, consulte Como criar painéis.

Conferir 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 seus clusters do Google Distributed Cloud, use a visão geral do Google Kubernetes Engine no console Google Cloud . Consulte Gerenciar clusters pelo console do Google Cloud para saber mais.

Limites de cota padrão do Cloud Monitoring

O monitoramento do Google Distributed Cloud 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 pelo console do Google Cloud .

Configurar o recurso personalizado do Stackdriver

Ao criar um cluster, o Google Distributed Cloud 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.

Modificar as solicitações e os limites padrão de CPU e memória para um componente do Stackdriver

Os clusters com alta densidade de pods introduzem sobrecarga de geração de registros e monitoramento. Em casos extremos, os componentes do Stackdriver podem relatar perto do limite de CPU e de utilização de memória ou podem estar sujeitos a reinicializações constantes devido a limites de recursos. Nesse caso, para substituir os valores padrão de solicitações e limites de CPU e memória de um componente do Stackdriver, use as seguintes etapas:

1. Execute o comando a seguir para abrir o recurso personalizado do Stackdriver em um editor de linha de comando:

   kubectl -n kube-system edit stackdriver stackdriver

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

   resourceAttrOverride:
         DAEMONSET_OR_DEPLOYMENT_NAME/CONTAINER_NAME:
           LIMITS_OR_REQUESTS:
             RESOURCE: RESOURCE_QUANTITY

   Observe que a seção resourceAttrOverride substitui todos os limites e solicitações padrão existentes do componente que você especificar. Os seguintes componentes são compatíveis com resourceAttrOverride:

   • gke-metrics-agent/gke-metrics-agent
   • stackdriver-log-forwarder/stackdriver-log-forwarder
   • stackdriver-metadata-agent-cluster-level/metadata-agent
   • node-exporter/node-exporter
   • kube-state-metrics/kube-state-metrics

   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:
       gke-metrics-agent/gke-metrics-agent:
         requests:
           cpu: 110m
           memory: 240Mi
         limits:
           cpu: 200m
           memory: 4.5Gi

3. Para salvar as mudanças no recurso personalizado do Stackdriver, salve e saia do editor de linha de comando.

4. Para verificar a integridade do pod:

   kubectl -n kube-system get pods -l "managed-by=stackdriver"

   Uma resposta para um pod íntegro é semelhante a esta:

   gke-metrics-agent-4th8r                1/1     Running   1   40h

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

   kubectl -n kube-system describe pod POD_NAME

   Substitua POD_NAME pelo nome do pod que você acabou de alterar. Por exemplo, gke-metrics-agent-4th8r.

   A resposta é semelhante a esta:

     Name:         gke-metrics-agent-4th8r
     Namespace:    kube-system
     ...
     Containers:
       gke-metrics-agent:
         Limits:
           cpu: 200m
           memory: 4.5Gi
         Requests:
           cpu: 110m
           memory: 240Mi
         ...

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, kubelet e kube-state-metrics ao Google Cloud Observability (antigo Stackdriver). Se você precisar de mais métricas, recomendamos que encontre um substituto na lista de métricas do Google Distributed Cloud.

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

Para desativar a configuração padrão de métricas otimizadas (não recomendado), faça o seguinte:

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

   kubectl -n kube-system edit stackdriver stackdriver

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
     optimizedMetrics: false

3. Salve as mudanças e saia do editor de linha de comando.

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]          

Usar o Google Cloud Managed Service para Prometheus

O Google Cloud Managed Service para Prometheus faz parte do Cloud Monitoring e está disponível como uma opção para componentes do sistema. Os benefícios do Managed Service para Prometheus incluem:

• É possível continuar usando o monitoramento atual baseado no Prometheus sem alterar os alertas e os painéis do Grafana.

• Se você usar o GKE e o Google Distributed Cloud, poderá usar a mesma linguagem de consulta do Prometheus (PromQL) para métricas em todos os clusters. Também é possível usar a guia PromQL no Metrics Explorer no console do Google Cloud .

Ativar e desativar o Managed Service para Prometheus

A partir da versão 1.30.0-gke.1930 do Google Distributed Cloud, o Managed Service para Prometheus está sempre ativado. Em versões anteriores, é possível editar o recurso do Stackdriver, stackdriver, para ativar ou desativar o Managed Service para Prometheus. Para desativar o Managed Service para Prometheus em versões de cluster anteriores a 1.30.0-gke.1930, defina spec.featureGates.enableGMPForSystemMetrics no recurso stackdriver como false.

Conferir dados da métrica

Quando enableGMPForSystemMetrics é definido como true, as métricas dos componentes a seguir têm um formato diferente de armazenamento e consulta no Cloud Monitoring:

• kube-apiserver
• kube-scheduler
• kube-controller-manager
• kubelet e cadvisor
• kube-state-metrics
• exportador de nós

No novo formato, é possível consultar as métricas anteriores usando a linguagem de consulta do Prometheus (PromQL).

Exemplo de consulta PromQL:

histogram_quantile(0.95, sum(rate(apiserver_request_duration_seconds_bucket[5m])) by (le))

Configurar painéis do Grafana com o Managed Service para Prometheus

Para usar o Grafana com dados de métricas do Managed Service para Prometheus, siga as etapas em Consultar usando o Grafana para autenticar e configurar uma fonte de dados do Grafana para consultar dados do Managed Service para Prometheus.

Um conjunto de painéis de amostra do Grafana é fornecido no repositório anthos-samples no GitHub. Para instalar os painéis de amostra, faça o seguinte:

1. Faça o download dos arquivos JSON de amostra:

   git clone https://github.com/GoogleCloudPlatform/anthos-samples.git
   cd anthos-samples/gmp-grafana-dashboards
   

2. Se a fonte de dados do Grafana tiver sido criada com um nome diferente de Managed Service for Prometheus, mude o campo datasource em todos os arquivos JSON:

   sed -i "s/Managed Service for Prometheus/[DATASOURCE_NAME]/g" ./*.json
   

   Substitua [DATASOURCE_NAME] pelo nome da fonte de dados no Grafana que foi apontada para o serviço frontend do Prometheus.

3. Acesse a interface do Grafana no navegador e selecione + Importar depois do menu Painéis.

   

4. Faça upload do arquivo JSON ou copie e cole o conteúdo do arquivo e selecione Carregar. Depois que o conteúdo do arquivo for carregado, selecione Importar. Também é possível alterar o nome do painel e o UID antes de importar.

   

5. O painel importado será carregado se o Google Distributed Cloud e a fonte de dados estiverem configurados corretamente. Por exemplo, a captura de tela a seguir mostra o painel configurado por cluster-capacity.json.

   

Outros recursos

Para mais informações sobre o Serviço gerenciado para Prometheus, consulte:

• Google Cloud Managed Service para Prometheus

• As métricas do plano de controle do GKE são compatíveis com PromQL

• Como usar o Managed Service para Prometheus em aplicativos de usuário no Google Distributed Cloud

Problema conhecido

Nos clusters de usuário, o Prometheus e o Grafana são desativados automaticamente durante os upgrades. 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.

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.

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.

Mudar 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

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 Prometheus e o Grafana

A partir da versão 1.16, o Prometheus e o Grafana não são mais controlados pelo campo enablePrometheus no objeto monitoring-sample. Consulte Como usar o Prometheus e o Grafana para mais detalhes.

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.

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.

Diagnosticar a falha 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"}

Recuperar-se 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 o pipeline de monitoramento PersistentVolumeClaims (PVCs):

   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