Usar o registo e a monitorização para componentes do sistema

Este documento mostra como configurar o registo e a monitorização de componentes do sistema no Google Distributed Cloud (apenas software) para VMware.

Por predefinição, o Cloud Logging, o Cloud Monitoring e o Google Cloud Managed Service for Prometheus estão ativados.

Para mais informações sobre as opções, consulte o artigo Descrição geral do registo e da monitorização.

Recursos monitorizados

Os recursos monitorizados são a forma como a Google representa recursos como clusters, nós, pods e contentores. Para saber mais, consulte a documentação Tipos de recursos monitorizados do Cloud Monitoring.

Para consultar registos e métricas, tem de conhecer, pelo menos, estas etiquetas de recursos:

• project_id: ID do projeto do projeto de registo e monitorização do cluster. Facultou este valor no campo stackdriver.projectID do ficheiro de configuração do cluster.

• location: Uma Google Cloud região onde quer encaminhar e armazenar as suas métricas do Cloud Monitoring. Especifica a região durante a instalação no campo stackdriver.clusterLocation do ficheiro de configuração do cluster. Recomendamos que escolha uma região próxima do seu centro de dados no local.

  Especifica o encaminhamento de registos e a localização de armazenamento do Cloud Logging na configuração do Log Router. Para mais informações sobre o encaminhamento de registos, consulte o artigo Vista geral do encaminhamento e armazenamento.

• cluster_name: nome do cluster que escolheu quando criou o cluster.

  Pode obter o valor cluster_name para o cluster de administrador ou de utilizador 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 ficheiro kubeconfig do cluster de administrador ou do cluster de utilizador para o qual o nome do cluster é obrigatório.

Encaminhamento de registos e métricas

O encaminhador de registos do Stackdriver (stackdriver-log-forwarder) envia registos 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 de os registos e as métricas serem enviados, o operador do Stackdriver (stackdriver-operator) anexa o valor do campo clusterLocation no recurso personalizado stackdriver a cada entrada de registo e métrica antes de serem encaminhados para Google Cloud. Além disso, os registos e as métricas estão associados ao Google Cloud projetostackdriver especificado na especificação do recurso personalizado spec.projectID. O recurso stackdriver recebe valores para os campos clusterLocation e projectID dos campos stackdriver.clusterLocation e stackdriver.projectID na secção clusterOperations do recurso de cluster no momento da criação do cluster.

Todas as métricas e entradas de registo enviadas pelos agentes do Stackdriver são encaminhadas para um ponto final de carregamento global. A partir daí, os dados são encaminhados para o ponto final Google Cloud regional Google Cloud acessível mais próximo para garantir a fiabilidade do transporte de dados.

Assim que o ponto final global recebe a métrica ou a entrada do registo, o que acontece a seguir depende do serviço:

• Como o encaminhamento de registos está configurado: quando o ponto final de registo recebe uma mensagem de registo, o Cloud Logging passa a mensagem através do encaminhador de registos. Os destinos e os filtros na configuração do Log Router determinam como encaminhar a mensagem. Pode encaminhar as entradas de registo para destinos como contentores de registo regionais, que armazenam a entrada de registo, ou para o Pub/Sub. Para mais informações sobre como funciona o encaminhamento de registos e como o configurar, consulte a vista geral do encaminhamento e armazenamento.

  Nem o campo clusterLocation no recurso personalizado stackdriver nem o campo clusterOperations.location na especificação do cluster são considerados neste processo de encaminhamento. Para os registos, clusterLocation é usado apenas para etiquetar entradas de registo, o que pode ser útil para filtrar no Explorador de registos.

• Como o encaminhamento de métricas está configurado: quando o ponto final de métricas recebe uma entrada de métricas, o Cloud Monitoring encaminha a entrada automaticamente para a localização especificada pela métrica. A localização na métrica veio do campo clusterLocation no recurso personalizado stackdriver.

• Planeie a sua configuração: quando configurar o Cloud Logging e o Cloud Monitoring, configure o Log Router e especifique um clusterLocation adequado com localizações que melhor satisfaçam as suas necessidades. Por exemplo, se quiser que os registos e as métricas sejam enviados para a mesma localização, defina clusterLocationregion Google Cloud para a mesma região que o Log Router está a usar para o seu projeto. Google Cloud

• Atualize a configuração quando necessário: pode fazer alterações em qualquer altura às definições de destino para registos e métricas devido a requisitos empresariais, como planos de recuperação de desastres. As alterações à configuração do Log Router no campo Google Cloud e clusterLocation no recurso personalizado stackdriver entram em vigor rapidamente.

Usar o Cloud Logging

Não tem de fazer nada para ativar o Cloud Logging para um cluster. No entanto, tem de especificar o Google Cloud projeto onde quer ver os registos. No ficheiro de configuração do cluster, especifica o Google Cloud projeto na secção stackdriver.

Pode aceder aos registos através do Explorador de registos na Google Cloud consola. Por exemplo, para aceder aos registos de um contentor:

1. Abra o Explorador de registos na Google Cloud consola do seu projeto.
2. Encontre registos de um contentor por:
   1. Clicando na caixa pendente do catálogo de registos na parte superior esquerda e selecionando Kubernetes Container.
   2. Selecionar o nome do cluster, o espaço de nomes e, de seguida, um contentor na hierarquia.

Visualizar registos de controladores no cluster de arranque

1. Na Google Cloud consola, aceda à página Explorador de registos:

   Aceda ao Explorador de registos

   Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cuja legenda é Registo.

2. Para ver todos os registos dos controladores no cluster de arranque, 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 registos de um pod específico, edite a consulta para incluir o nome desse pod:

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

Usar o Cloud Monitoring

Não tem de fazer nada para ativar o Cloud Monitoring para um cluster. No entanto, tem de especificar o Google Cloud projeto onde quer ver as métricas. No ficheiro de configuração do cluster, especifica o Google Cloud projeto na secção stackdriver.

Pode escolher entre mais de 1500 métricas através do Explorador de métricas. Para aceder ao Explorador de métricas, faça o seguinte:

1. Na Google Cloud consola, selecione Monitorização ou use o botão seguinte:

   Aceder a Monitorização

2. Selecione Recursos > Explorador de métricas.

Também pode ver métricas em painéis de controlo na Google Cloud consola. Para obter informações sobre a criação de painéis de controlo e a visualização de métricas, consulte Criar painéis de controlo.

Nota: os painéis de controlo do GKE apenas apresentam informações para clusters do GKE em execução no Google Cloud. Não apresentam informações sobre o Google Distributed Cloud.

Visualizar dados de monitorização ao nível da frota

Para uma vista geral da utilização de recursos da sua frota através dos dados do Cloud Monitoring, incluindo os clusters do Google Distributed Cloud, pode usar a vista geral do Google Kubernetes Engine na Google Cloud consola. Consulte o artigo Faça a gestão de clusters a partir da Google Cloud consola para saber mais.

Limites de quota predefinidos do Cloud Monitoring

A monitorização do Google Distributed Cloud tem um limite predefinido de 6000 chamadas de API por minuto para cada projeto. Se exceder este limite, as suas métricas podem não ser apresentadas. Se precisar de um limite de monitorização mais elevado, peça um através da Google Cloud consola.

Usar o Managed Service for Prometheus

O Google Cloud Managed Service for Prometheus faz parte do Cloud Monitoring e está disponível por predefinição. As vantagens do Managed Service for Prometheus incluem o seguinte:

• Pode continuar a usar a sua monitorização baseada no Prometheus sem alterar os seus alertas e painéis de controlo do Grafana.

• Se usar o GKE e o Google Distributed Cloud, pode usar o mesmo PromQL para métricas em todos os seus clusters. Também pode usar o separador PROMQL no Explorador de métricas na Google Cloud consola.

Ativar e desativar o Managed Service for Prometheus

A partir da versão 1.30.0-gke.1930 do Google Distributed Cloud, o serviço gerido para Prometheus está sempre ativado. Nas versões anteriores, pode editar o recurso do Stackdriver, stackdriver, para ativar ou desativar o Managed Service for Prometheus. Para desativar o Managed Service for Prometheus para versões de cluster anteriores a 1.30.0-gke.1930, defina spec.featureGates.enableGMPForSystemMetrics no recurso stackdriver como false.

Ver dados de métricas

Quando o Managed Service for Prometheus está ativado, as métricas dos seguintes componentes têm um formato diferente para a forma como são armazenadas e consultadas no Cloud Monitoring:

• kube-apiserver
• kube-scheduler
• kube-controller-manager
• kubelet e cadvisor
• kube-state-metrics
• node-exporter

No novo formato, pode consultar as métricas anteriores através da linguagem de consulta Prometheus (PromQL).

Exemplo de PromQL:

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

Configurar painéis de controlo do Grafana com o Managed Service for Prometheus

Para usar o Grafana com dados de métricas do Managed Service for Prometheus, siga os passos em Consultar com o Grafana para autenticar e configurar uma origem de dados do Grafana para consultar dados do Managed Service for Prometheus.

É disponibilizado um conjunto de painéis de controlo do Grafana de exemplo no repositório anthos-samples no GitHub. Para instalar os painéis de controlo de exemplo, faça o seguinte:

1. Transfira os ficheiros de exemplo .json:

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

2. Se a sua origem de dados do Grafana foi criada com um nome diferente de Managed Service for Prometheus, altere o campo datasource em todos os ficheiros .json:

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

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

3. Aceda à IU do Grafana a partir do navegador e selecione + Importar no menu Painéis de controlo.

   

4. Carregue o ficheiro .json ou copie e cole o conteúdo do ficheiro e selecione Carregar. Quando o conteúdo do ficheiro for carregado com êxito, selecione Importar. Opcionalmente, também pode alterar o nome e o UID do painel de controlo antes da importação.

   

5. O painel de controlo importado deve ser carregado com êxito se o Google Distributed Cloud e a origem de dados estiverem configurados corretamente. Por exemplo, a captura de ecrã seguinte mostra o painel de controlo configurado por cluster-capacity.json.

   

Recursos adicionais

Para mais informações sobre o Managed Service for Prometheus, consulte o seguinte:

• Google Cloud Managed Service for Prometheus

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

• Usar o Managed Service for Prometheus para aplicações de utilizadores no Google Distributed Cloud

Usar o Prometheus e o Grafana

A partir da versão 1.16, o Prometheus e o Grafana não estão disponíveis em clusters criados recentemente. Recomendamos que use o serviço gerido para Prometheus como substituição da monitorização no cluster.

Se atualizar um cluster 1.15 com o Prometheus e o Grafana ativados para a versão 1.16, o Prometheus e o Grafana continuam a funcionar como estão, mas não são atualizados nem recebem patches de segurança.

Se quiser eliminar todos os recursos do Prometheus e do Grafana após a atualização para a versão 1.16, execute o seguinte comando:

kubectl --kubeconfig KUBECONFIG delete -n kube-system \
    statefulsets,services,configmaps,secrets,serviceaccounts,clusterroles,clusterrolebindings,certificates,deployments \
    -l addons.gke.io/legacy-pg=true

Em alternativa à utilização dos componentes Prometheus e Grafana incluídos nas versões anteriores do Google Distributed Cloud, pode mudar para uma versão da comunidade de código aberto do Prometheus e do Grafana.

Problema conhecido

Nos clusters de utilizadores, o Prometheus e o Grafana são desativados automaticamente durante as atualizações. No entanto, os dados de configuração e métricas não são perdidos.

Para contornar este problema, após a atualização, abra monitoring-sample para edição e defina enablePrometheus como true.

Aceder às métricas de monitorização a partir de painéis de controlo do Grafana

O Grafana apresenta métricas recolhidas dos seus clusters. Para ver estas métricas, tem de aceder aos painéis de controlo do Grafana:

1. Obtenha o nome do pod do Grafana em execução no espaço de nomes kube-system de um cluster de utilizadores:

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

   onde [USER_CLUSTER_KUBECONFIG] é o ficheiro kubeconfig do cluster de utilizadores.

2. O pod do Grafana tem um servidor HTTP a escutar na porta 3000 do localhost TCP. Encaminhe uma porta local para a porta 3000 no pod, para que possa ver os painéis de controlo do Grafana a partir de um navegador de Internet.

   Por exemplo, suponhamos que o nome do Pod é grafana-0. Para encaminhar a porta 50000 para a porta 3000 no pod, introduza este comando:

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

3. Num navegador de Internet, navegue para http://localhost:50000.

4. Na página de início de sessão, introduza admin para o nome de utilizador e a palavra-passe.

5. Se o início de sessão for bem-sucedido, é apresentada uma mensagem para alterar a palavra-passe. Depois de alterar a palavra-passe predefinida, o painel de controlo inicial do Grafana do cluster de utilizadores deve ser carregado.

6. Para aceder a outros painéis de controlo, clique no menu pendente Página inicial no canto superior esquerdo da página.

Para ver um exemplo de utilização do Grafana, consulte o artigo Crie um painel de controlo do Grafana.

Aceder aos alertas

O Prometheus Alertmanager recolhe alertas do servidor Prometheus. Pode ver estes alertas num painel de controlo do Grafana. Para ver os alertas, tem de aceder ao painel de controlo:

1. O contentor no alertmanager-0 Pod escuta 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. Num navegador de Internet, navegue para http://localhost:50001.

Alterar a configuração do Prometheus Alertmanager

Pode alterar a configuração predefinida do Prometheus Alertmanager editando o ficheiro monitoring.yaml do cluster de utilizadores. Deve fazê-lo se quiser direcionar os alertas para um destino específico, em vez de os manter no painel de controlo. Pode saber como configurar o Alertmanager na documentação de configuração do Prometheus.

Para alterar a configuração do Alertmanager, siga estes passos:

1. Crie uma cópia do ficheiro de manifesto monitoring.yaml do cluster de utilizadores:

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

2. Para configurar o Alertmanager, altere os campos em spec.alertmanager.yml. Quando terminar, guarde o manifesto alterado.

3. Aplique o manifesto ao cluster:

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

Crie um painel de controlo do Grafana

Implementou uma aplicação que expõe uma métrica, verificou se a métrica está exposta e verificou se o Prometheus extrai a métrica. Agora, pode adicionar a métrica ao nível da aplicação a um painel de controlo do Grafana personalizado.

Para criar um painel de controlo do Grafana, siga estes passos:

1. Se necessário, aceda ao Grafana.
2. No painel de controlo da página inicial, clique no menu pendente Página inicial no canto superior esquerdo da página.
3. No menu do lado direito, clique em Novo painel de controlo.
4. Na secção Novo painel, clique em Gráfico. É apresentado um painel de controlo de gráficos vazio.
5. Clique em Título do painel e, de seguida, em Editar. O painel Gráfico inferior é aberto no separador Métricas.
6. No menu pendente Origem de dados, selecione user. Clique em Adicionar consulta e introduza foo no campo pesquisar.
7. Clique no botão Voltar ao painel de controlo no canto superior direito do ecrã. É apresentado o painel de controlo.
8. Para guardar o painel de controlo, clique em Guardar painel de controlo no canto superior direito do ecrã. Escolha um nome para o painel de controlo e, de seguida, clique em Guardar.

Desativar o Prometheus e o Grafana

A partir da versão 1.16, o Prometheus e o Grafana já não são controlados pelo campo enablePrometheus no objeto monitoring-sample. Consulte o artigo Usar o Prometheus e o Grafana para ver detalhes.

Exemplo: adicionar métricas ao nível da aplicação a um painel de controlo do Grafana

As secções seguintes explicam como adicionar métricas para uma aplicação. Nesta secção, conclui as seguintes tarefas:

• Implemente uma aplicação de exemplo que exponha uma métrica denominada foo.
• Verifique se o Prometheus expõe e extrai a métrica.
• Crie um painel de controlo do Grafana personalizado.

Implemente a aplicação de exemplo

A aplicação de exemplo é executada num único pod. O contentor do Pod expõe uma métrica, foo, com um valor constante de 40.

Crie o seguinte manifesto de agrupamento, 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 utilizadores:

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

Verifique se a métrica está exposta e recolhida

1. O contentor no pod prometheus-example escuta 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 a aplicação expõe a métrica, execute o seguinte comando:

   curl localhost:50002/metrics | grep foo
   

   O comando devolve o seguinte resultado:

   # HELP foo Custom metric
   # TYPE foo gauge
   foo 40

3. O contentor no prometheus-0 Pod ouve na porta TCP 9090. Encaminhar 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á a extrair a métrica, navegue para http://localhost:50003/targets, que deve direcionar para o prometheus-0 Pod no grupo de destino prometheus-io-pods.

5. Para ver as métricas no Prometheus, navegue para http://localhost:50003/graph. No campo de pesquisa, introduza foo e, de seguida, clique em Executar. A página deve apresentar a métrica.

Configurar o recurso personalizado do Stackdriver

Quando cria um cluster, o Google Distributed Cloud cria automaticamente um recurso personalizado do Stackdriver. Pode editar a especificação no recurso personalizado para substituir os valores predefinidos dos pedidos e limites de CPU e memória de um componente do Stackdriver. Além disso, pode substituir separadamente o tamanho de armazenamento e a classe de armazenamento predefinidos.

Substitua os valores predefinidos dos pedidos e limites da CPU e da memória

Para substituir estas predefinições, faça o seguinte:

1. Abra o recurso personalizado do Stackdriver num editor de linha de comandos:

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

   em que KUBECONFIG é o caminho para o ficheiro kubeconfig do cluster. Pode ser um cluster de administrador ou um cluster de utilizador.

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

   resourceAttrOverride:
         POD_NAME_WITHOUT_RANDOM_SUFFIX/CONTAINER_NAME:
           LIMITS_OR_REQUESTS:
             RESOURCE: RESOURCE_QUANTITY

   Tenha em atenção que o campo resourceAttrOverride substitui todos os limites e pedidos predefinidos existentes para o componente especificado. Os seguintes componentes são suportados pelo 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 ficheiro de exemplo tem o seguinte aspeto:

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

1. Guarde as alterações e saia do editor de linha de comandos.

2. Verifique o estado dos seus pods:

   kubectl --kubeconfig=KUBECONFIG -n kube-system get pods | grep gke-metrics-agent

   Por exemplo, um Pod saudável tem o seguinte aspeto:

   gke-metrics-agent-4th8r                                1/1     Running   0          5d19h

3. Verifique a especificação do pod do componente para se certificar de que os recursos estão definidos corretamente.

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

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

   A resposta tem o seguinte aspeto:

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

Substitua as predefinições do tamanho de armazenamento

Para substituir estas predefinições, faça o seguinte:

1. Abra o recurso personalizado do Stackdriver num editor de linha de comandos:

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

2. Adicione o campo storageSizeOverride na secção spec. Pode usar o componente stackdriver-prometheus-k8s ou stackdriver-prometheus-app. A secçã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. Guarde e saia do editor de linha de comandos.

4. Verifique o estado dos seus pods:

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

   Por exemplo, um agrupamento em bom estado tem o seguinte aspeto:

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

5. Verifique a especificação do pod do componente para se certificar de que o tamanho do armazenamento é substituído corretamente.

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

   A resposta tem o seguinte aspeto:

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

Substitua as predefinições da classe de armazenamento

Pré-requisito

Primeiro, tem de criar uma StorageClass que quer usar.

Para substituir a classe de armazenamento predefinida para volumes persistentes reivindicados por componentes de registo e monitorização:

1. Abra o recurso personalizado do Stackdriver num editor de linha de comandos:

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

   em que KUBECONFIG é o caminho para o ficheiro kubeconfig do cluster. Pode ser um cluster de administrador ou um cluster de utilizador.

2. Adicione o campo storageClassName na secção spec:

   storageClassName: STORAGECLASS_NAME

   Tenha em atenção que o campo storageClassName substitui a classe de armazenamento predefinida existente e aplica-se a todos os componentes de registo e monitorização com volumes persistentes reivindicados. Um ficheiro de exemplo tem o seguinte aspeto:

   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. Guarde as alterações.

4. Verifique o estado dos seus pods:

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

   Por exemplo, um Pod saudável tem o seguinte aspeto:

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

5. Verifique a especificação do pod de um componente para se certificar de que a classe de armazenamento está definida corretamente.

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

   Por exemplo, usando o conjunto com estado stackdriver-prometheus-k8s, a resposta tem o seguinte aspeto:

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

Desative as métricas otimizadas

Por predefinição, os agentes de métricas em execução no cluster recolhem e comunicam um conjunto otimizado de métricas de contentores, kubelet e kube-state-metrics ao Stackdriver. Se precisar de métricas adicionais, recomendamos que encontre uma substituição na lista de métricas do Google Distributed Cloud.

Seguem-se alguns exemplos de substituições que pode usar:

Métrica desativada	Substituições
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 predefinição das métricas kube-state-metrics otimizadas (não recomendado), faça o seguinte:

1. Abra o recurso personalizado do Stackdriver num editor de linha de comandos:

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

   em que KUBECONFIG é o caminho para o ficheiro kubeconfig do cluster. Pode ser um cluster de administrador ou um cluster de utilizador.

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. Guarde as alterações e saia do editor de linha de comandos.

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

(ID do problema: 159761921)

Em determinadas condições, o pod do Cloud Monitoring predefinido, implementado por predefinição em cada novo cluster, pode deixar de responder. Quando os clusters são atualizados, por exemplo, os dados de armazenamento podem ficar danificados quando os pods no statefulset/prometheus-stackdriver-k8s são reiniciados.

Especificamente, o pod de monitorização stackdriver-prometheus-k8s-0 pode ficar preso num ciclo quando os dados danificados impedem que o prometheus-stackdriver-sidecar escreva no armazenamento do cluster PersistentVolume.

Pode diagnosticar e recuperar manualmente o erro seguindo os passos abaixo.

Diagnosticar a falha do Cloud Monitoring

Quando o pod de monitorização falha, os registos comunicam 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 do erro do Cloud Monitoring

Para recuperar o Cloud Monitoring manualmente:

1. Parar a monitorização do cluster. Reduza o operador stackdriver para evitar a conciliação da monitorização:

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

2. Elimine as cargas de trabalho do pipeline de monitorização:

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

3. Elimine os PersistentVolumeClaims (PVCs) do pipeline de monitorização:

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

4. Reinicie a monitorização de clusters. Aumente a escala do operador do Stackdriver para reinstalar um novo pipeline de monitorização e retomar a conciliação:

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