Esta página foi traduzida pela API Cloud Translation.

Como usar a geração de registros e o monitoramento de componentes do sistema

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

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 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 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 usar o Cloud Logging

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

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

Abra o Visualizador de registros do seu projeto no console do Google Cloud.
Para encontrar os registros de um contêiner, faça o seguinte:
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

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"
```

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 usar o Cloud Monitoring

Você não precisa fazer nada para ativar o Cloud Monitoring em um cluster. No entanto, é preciso especificar o projeto do Google Cloud em que você quer ver as métricas. No arquivo de configuração do cluster, especifique o projeto do 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:

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

Acessar Monitoring
Selecione Recursos > Metrics Explorer.

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

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.

Limites de cota padrão do Cloud Monitoring

O Google Distributed Cloud Monitoring 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.

Como usar o serviço gerenciado para Prometheus

O Google Cloud Managed Service para Prometheus faz parte do Cloud Monitoring e está disponível por padrão. Os benefícios do Serviço gerenciado para o Prometheus incluem:

É possível continuar usando o monitoramento atual baseado no Prometheus sem alterar os alertas e os painéis do Grafana.
Se você usa o GKE e o Google Distributed Cloud, é possível utilizar o mesmo PromQL para métricas em todos os clusters. Também é possível usar a guia PROMQL no Metrics Explorer no console do Google Cloud.

Como ativar e desativar o serviço gerenciado para Prometheus

O Managed Service para Prometheus é ativado por padrão no Google Distributed Cloud.

Para desativar o serviço gerenciado para Prometheus em um cluster:

Abra o objeto Stackdriver chamado stackdriver para edição:

kubectl --kubeconfig CLUSTER_KUBECONFIG --namespace kube-system \
    edit stackdriver stackdriver

Adicione o portão de recurso enableGMPForSystemMetrics e defina-o como false:

apiVersion: addons.gke.io/v1alpha1
kind: Stackdriver
metadata:
  name: stackdriver
  namespace: kube-system
spec:
  featureGates:
    enableGMPForSystemMetrics: false

Feche a sessão de edição.

Como visualizar dados de métricas

Quando o Managed Service para Prometheus está ativado, 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 o PromQL ou a Linguagem de consulta do Monitoring (MQL).

Exemplo de PromQL:

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

Para usar o MQL, defina o recurso monitorado como prometheus_target e adicione o tipo Prometheus como um sufixo da métrica.

Exemplo de MQL:

fetch prometheus_target
| metric 'kubernetes.io/anthos/apiserver_request_duration_seconds/histogram'
| align delta(5m)
| every 5m
| group_by [], [value_histogram_percentile: percentile(value.histogram, 95)]

Como configurar painéis do Grafana com o Managed Service para Prometheus

Se quiser 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 (em inglês) no GitHub. Para instalar os painéis de amostra, faça o seguinte:

Faça o download dos arquivos de amostra .json:

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

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.
Acesse a IU do Grafana no navegador e selecione + Importar no menu Painéis.
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.
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.

Recursos adicionais

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

Como 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 recém-criados. Recomendamos que você use o serviço gerenciado para Prometheus como um substituto para o monitoramento no cluster.

Se você fizer upgrade de um cluster 1.15 com o Prometheus e o Grafana ativados para a versão 1.16, o Prometheus e o Grafana continuarão funcionando, mas não serão atualizados ou recebeu patches de segurança.

Se você quiser excluir todos os recursos do Prometheus e do Grafana após fazer upgrade 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

Como alternativa ao uso dos componentes do Prometheus e do Grafana incluídos nas versões anteriores do Google Distributed Cloud, é possível mudar para uma versão de código aberto da comunidade do Prometheus e do Grafana.

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:

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.
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
```
Em um navegador da Web, acesse http://localhost:50000.
Na página de login, digite admin para nome de usuário e senha.
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.
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:

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
```
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:

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

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

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:

Se necessário, tenha acesso ao Grafana.
No painel inicial, clique no menu suspenso Início no canto superior esquerdo da página.
No menu lateral direito, clique em Novo painel.
Na seção Novo painel, clique em Gráfico. Um painel de gráfico vazio é exibido.
Clique em Título do painel e, depois, em Editar. O painel inferior Gráfico é aberto na guia Métricas.
No menu suspenso Fonte de dados, selecione usuário. Clique em Adicionar consulta e insira foo no campo pesquisa.
Clique no botão Voltar para o painel no canto superior direito da tela. O painel é exibido.
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

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

Como configurar o recurso personalizado do 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:

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.
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. Os seguintes componentes têm suporte do 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

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

Verifique a integridade dos pods:

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

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

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

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:         gke-metrics-agent-4th8r
  Namespace:    kube-system
  ...
  Containers:
    gke-metrics-agent:
      Limits:
        cpu: 200m
        memory: 4.5Gi
      Requests:
        cpu: 110m
        memory: 240Mi
      ...

Modificar padrões de tamanho do armazenamento

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

Abra o recurso personalizado do Stackdriver em um editor de linha de comando:
```
kubectl --kubeconfig=KUBECONFIG -n kube-system edit stackdriver stackdriver
```

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

Salve e saia do editor da linha de comando.

Verifique a integridade dos pods:

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

Por exemplo, um pod íntegro é semelhante ao seguinte:

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

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:

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.

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

Salve as alterações.

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

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:

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.

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

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

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:

Interrompa o monitoramento do cluster. Reduza a escala vertical do operador stackdriver para evitar o monitoramento da reconciliação:
```
kubectl --kubeconfig /ADMIN_CLUSTER_KUBCONFIG --namespace kube-system scale deployment stackdriver-operator --replicas 0
```

Exclua as cargas de trabalho do pipeline de monitoramento:

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

Exclua o pipeline de monitoramento PersistentVolumeClaims (PVCs):

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

Reinicie o monitoramento do cluster. Escalone verticalmente 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
```