Neste documento, mostramos como configurar a geração de registros e o monitoramento de componentes do sistema no GKE no VMware.
As opções incluem:
- Cloud Logging e Cloud Monitoring
- Google Cloud Managed Service para Prometheus (pré-lançamento)
- Prometheus e Grafana
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 campostackdriver.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 campostackdriver.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 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.
- Encontre registros de um contêiner:
- Clique na caixa suspensa do catálogo de registros no canto superior esquerdo e selecione Contêiner do Kubernetes.
- 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:
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 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.
Como usar o Managed Service para Prometheus (visualização)
O Google Cloud Managed Service para Prometheus faz parte do Cloud Monitoring e está disponível como opçã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ê usar o GKE e o GKE no VMware, poderá usar 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 o Managed Service para Prometheus
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 true
:
apiVersion: addons.gke.io/v1alpha1 kind: Stackdriver metadata: name: stackdriver namespace: kube-system spec: featureGates: enableGMPForSystemMetrics: true
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
Para usar o Grafana com dados de métricas do serviço gerenciado para Prometheus, siga as etapas em Consultar usando o Grafana para autenticar e configurar uma fonte de dados do Grafana e consultar dados do serviço gerenciado para o 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:
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 campodatasource
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 vai ser carregado se o GKE no VMware 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:
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ários no GKE no VMware
Como usar o Prometheus e o Grafana
Para ativar o Prometheus e o Grafana, abra o objeto do Monitoring chamado monitoring-sample
para edição:
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] edit \ monitoring monitoring-sample --namespace kube-system
Defina enablePrometheus
como true
:
apiVersion: addons.gke.io/v1alpha1 kind: Monitoring metadata: labels: k8s-app: monitoring-operator name: monitoring-sample namespace: kube-system spec: channel: stable ... enablePrometheus: false
Feche 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:
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
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:
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 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
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:
- 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
Para desativar o monitoramento no cluster, reverta as alterações feitas no
objeto monitoring-sample
:
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.
Para desativar o Prometheus e o Grafana, defina
enablePrometheus
comofalse
:apiVersion: addons.gke.io/v1alpha1 kind: Monitoring metadata: labels: k8s-app: monitoring-operator name: monitoring-sample namespace: kube-system spec: channel: stable ... enablePrometheus: false
Salve as alterações fechando a sessão de edição.
Confirme se os statefulsets
prometheus-0
,prometheus-1
egrafana-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
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çãospec
: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
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 stackdriver
Por exemplo, um pod íntegro se parece com o seguinte:
stackdriver-prometheus-k8s-0 2/2 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: 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:
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çãospec
. É possível usar o componentestackdriver-prometheus-k8s
oustackdriver-prometheus-app
. A seção tem este formato:storageSizeOverride: STATEFULSET_NAME: SIZE
Este exemplo usa o statefulset
stackdriver-prometheus-k8s
e o tamanho120Gi
.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 se parece com o 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çãospec
: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
comofalse
: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 o operador
stackdriver
para evitar a reconciliação do monitoramento: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 os PersistentVolumeClaims (PVCs) do pipeline de monitoramento:
kubectl --kubeconfig /ADMIN_CLUSTER_KUBCONFIG --namespace kube-system delete pvc -l app=stackdriver-prometheus-k8s
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