Como migrar para o Cloud Operations para GKE

Há duas opções para o suporte de monitoramento e geração de registro no Google Kubernetes Engine (GKE):

• Logging e Monitoring legados: para ver a documentação, consulte as páginas Monitoring legado e Logging legado.

• Cloud Operations para GKE: para documentação, consulte Cloud Operations para GKE..

Nesta página, você aprenderá as diferenças entre essas duas opções e o que alterar para migrar do Logging e do Monitoring legados para o Cloud Operations para GKE.

Aviso: após 31 de março de 2021, o Logging e o Monitoring legados não serão mais compatíveis. Após essa data, os clusters que usam o Logging e o Monitoring legados serão migrados de forma automática e gradual para o Cloud Operations para GKE. No entanto, o suporte ao Logging e Monitoring legados e o suporte a Cloud Operations para GKE são incompatíveis. Para concluir a atualização do Cloud Operations para GKE, altere suas configurações do Monitoring e Logging, incluindo, entre outras, políticas de alerta, gráficos, filtros de grupo, consultas de registro, coletores de registros, exclusões de registros e métricas com base em registros.

Observação: este tópico se aplica somente aos clusters padrão do GKE. O Logging e o Monitoring legados não estão disponível para clusters do piloto automático.

Quando preciso migrar?

É possível migrar as configurações atuais do Cloud Monitoring e do Cloud Logging do Logging e do Monitoring legados para o Cloud Operations para GKE a qualquer momento. No entanto, lembre-se de que o Logging e o Monitoring legados não são compatíveis com a versão 1.20 do GKE.

Observação: a alteração da versão do GKE do seu cluster não altera o monitoramento configurado e o suporte à geração de registro. Consulte Qual suporte a monitoramento e geração de registro meu cluster usa? para determinar o suporte atual para seu cluster.

Veja na tabela a seguir um resumo das opções de monitoramento e geração de registros disponíveis em cada versão de lançamento do GKE:

GKE version	Legacy Logging and Monitoring	Cloud Operations for GKE
1.14	Available	Default
1.15	Available	Default
1.16	Available	Default
1.17	Available	Default
1.18	Available	Default
1.19	Available	Default
1.20	Not Available	Default

For information on the deprecation of Legacy Logging and Monitoring, refer to the Legacy support for GKE deprecation guide.

Quais são os benefícios de usar o Cloud Operations para GKE?

O Cloud Operations para GKE oferece benefícios importantes, incluindo:

• Monitoramento de infraestrutura aprimorado. O painel do GKE inclui mais métricas prontas para uso no nível gratuito, um aumento de 17 métricas legadas para 44 novas métricas.

• Mais tipos de recurso para diferenciar melhor os recursos do Kubernetes, mais metadados para filtrar e agrupar métricas.

• Compatibilidade com o Monitoramento orientado a serviços com o Monitoramento do SLO para GKE.

• Modelos de recursos consistentes no Cloud Logging e no Cloud Monitoring.

• Melhorias de desempenho para todas as novas métricas do GKE.

O que vai mudar?

O Cloud Operations para GKE usa um modelo de recursos diferente do Logging e Monitoring legados para organizar as métricas, os registros e os metadados. Veja algumas alterações específicas para seus clusters usando o Cloud Operations para GKE:

• Alteração da navegação: o painel do Cloud Monitoring é chamado de GKE. Esse painel não aparecerá se você não tiver clusters que usam o Cloud Operations para GKE.

• Mudanças nos nomes dos tipos de recursos monitorados: por exemplo, seus nós do Kubernetes estão listados no tipo de recurso monitorado k8s_node, que é um nó do Kubernetes, em vez de em gce_instance (instância de VM do Compute Engine).

• Mudanças nos nomes de métricas do Kubernetes: no Cloud Operations para GKE, nomes de tipos de métricas agora começam com o prefixo kubernetes.io/ em vez do prefixo container.googleapis.com/.

• Mudanças nos metadados de logEntry: as entradas de registro do Cloud Operations para GKE mudaram os nomes de alguns dos campos resource.label e labels. Por exemplo, o campo resource.labels.namespace_id foi alterado para resource.labels.namespace_name enquanto o valor não mudou.

• mudanças de logName: as entradas de registro do Cloud Operations para GKE usamstdout ou stderr nos nomes de registro, enquanto o Logging e o Monitoring legados usam uma variedade maior de nomes, incluindo o nome do contêiner. O nome do contêiner ainda está disponível no Cloud Operations para GKE como um rótulo de recurso em resource.labels.container_name.

A seguinte tabela resume as mudanças anteriores:

Alterar	(Antigo) Logging e Monitoring legados	(Novo) Cloud Operations para GKE.
Menus do painel	Painéis > Clusters do GKE	Painéis > GKE
Prefixos métricos	container.googleapis.com	kubernetes.io
Tipos de recurso de métricas	gke_container gce_instance (nenhum)	k8s_container k8s_node k8s_pod
Tipos de recursos de registro	container gke_cluster gce_instance gke_nodepool	k8s_container k8s_cluster gke_cluster (somente registros de auditoria) k8s_node k8s_pod

Mudanças de tipo de recurso

O Cloud Operations para GKE têm novos nomes de tipo de recurso, novos nomes de exibição de tipo de recurso e novos nomes para os rótulos que identificam recursos específicos. Essas mudanças estão listadas na tabela a seguir.

Mudanças de tipo de recurso

(Antigo) Tipo de recurso do Logging e Monitoring legados	(Novo) Tipo de recurso do Cloud Operations para GKE
Notas de rodapé da tabela: ^1 No novo tipo de recurso usado (apenas) para monitoramento, instance_id torna-se node_name em metadata.system_labels. ^2 zone refere-se ao local desse contêiner ou instância. location refere-se ao local do nó do mestre do cluster. ^3 metadata.system_labels.node_name não está disponível em tipos de recurso k8s_container usados para geração de registros. Não é possível pesquisar registros por nome de nó. ^4 O gce_instance O tipo de recurso pode representar nós do Kubernetes, bem como instâncias de VM que não são do Kubernetes. Ao fazer upgrade para o Cloud Operations para GKE, os usos relacionados ao nó serão alterados para usar o novo tipo de recurso, k8s_node, incluindo registros no nível do nó com os seguintes nomes: kubelet, docker, kube-proxy, startupscript e node-problem-detector. ^5 Os nós k8s_pod e k8s_cluster podem incluir registros que não estão presentes no suporte ao Logging e Monitoring legados.
Somente Monitoring: gke_container (Contêiner do GKE) Rótulos:   cluster_name   container_name   instance_id^1   namespace_id   pod_id   project_id   zone^2 Somente Logging: container (Contêiner do GKE) Rótulos:   cluster_name   container_name   instance_id^1   namespace_id   pod_id   project_id   zone^2	Monitoring e Logging: k8s_container (Contêiner do Kubernetes) Rótulos:   cluster_name   container_name   metadata.system_labels.node_name^3   namespace_name   pod_name   project_id   location^2
Somente Logging:: gce_instance (Instância de VM do Compute Engine)^4 Rótulos:   cluster_name   instance_id   project_id   zone^2	Monitoring e Logging k8s_node^4 (Nó do Kubernetes) Rótulos:   cluster_name   node_name   project_id   location^2
(nenhum)	Monitoring e Logging: k8s_pod^5 (Pod do Kubernetes) Rótulos:   cluster_name   namespace_name   pod_name   project_id   location^2
Somente Logging gke_cluster (GKE_cluster) Rótulos:   cluster_name   project_id   location	Monitoring e Logging: k8s_cluster^5 (Cluster do Kubernetes) Rótulos:   cluster_name   project_id   location

O que preciso fazer?

Nesta seção, você verá informações mais específicas sobre as alterações do modelo de recursos no Cloud Operations para GKE e o impacto delas nas configurações de monitoramento e geração de registros atuais.

Execute as etapas a seguir para migrar seu cluster para o Cloud Operations para GKE:

1. Identifique as configurações do Logging e do Monitoring: identifique as configurações do Logging e do Monitoring que possam estar usando valores que foram alterados entre o Logging e o Monitoring legados e o Cloud Operations para GKE.

2. Atualize suas configurações do Logging e do Monitoring: atualize quaisquer configurações do Logging e do Monitoring para refletir as alterações presentes no Cloud Operations para GKE.

3. Atualize a configuração do cluster do GKE: atualize seu cluster do GKE para usar a configuração do Cloud Operations para GKE.

Como os modelos de recursos e os logNames foram alterados entre o Logging e o Monitoring legados e o Cloud Operations para GKE, todas as configurações do Logging ou Monitoring que fazem referência às alterações nos modelos de recursos também precisam ser atualizadas. A migração pode exigir que você atualize as configurações do Logging e do Monitoring, incluindo, entre outras:

• painéis personalizados
• gráficos
• filtros do grupo
• políticas de alertas
• coletores de registros
• exclusões de registro
• métricas com base em registros no Cloud Logging e no Cloud Monitoring

Observação: depois de migrar um cluster para o Cloud Operations para GKE, encontre seus dados de monitoramento e geração de registros usando apenas os novos nomes de tipos de recurso. Talvez você ainda veja os tipos de recursos legados, mas eles mantêm apenas dados de monitoramento e registro anteriores à atualização dos clusters.

Como identificar clusters usando o Logging e o Monitoring legados

Há duas maneiras de identificar quais clusters em um projeto estão usando o Logging e o Monitoring legados.

1. Usar a ferramenta de linha de comando gcloud por projeto

   Você pode usar o seguinte comando gcloud para listar os valores de loggingService e monitoringService para cada cluster no projeto atual.

   gcloud container clusters list | tail +2 | while read name loc rest ; do echo $name ; gcloud container clusters describe $name --zone $loc | egrep 'loggingService|monitoringService' ; echo ; done
   

   O resultado será semelhante ao do texto abaixo.

     cluster-1
     loggingService: logging.googleapis.com
     monitoringService: monitoring.googleapis.com
   
     cluster-2
     loggingService: logging.googleapis.com/kubernetes
     monitoringService: monitoring.googleapis.com/kubernetes
   
     cluster-3
     loggingService: logging.googleapis.com/kubernetes
     monitoringService: none
   

   Se a saída de um cluster tiver loggingService: logging.googleapis.com ou monitoringService: monitoring.googleapis.com, significa que o cluster está usando o Logging e o Monitoring legado.

   Se a saída de um cluster tiver loggingService: logging.googleapis.com/kubernetes ou monitoringService:monitoring.googleapis.com/kubernetes, significa que o cluster está usando o Cloud Operations para GKE.

2. Usar o painel de clusters do GKE do Cloud Monitoring

   1. Clique no painel Clusters do Cloud Monitoring para GKE.
   2. Selecione o espaço de trabalho que inclui o projeto do Google Cloud que você quer analisar para encontrar clusters que executam o Logging e o Monitoring legados.

   3. Veja a lista de clusters no painel. Somente os clusters que usam o Logging e o Monitoring legados aparecem no painel.

      Por exemplo, na captura de tela a seguir, há quatro clusters usando o Logging e o Monitoring legados.

      

Como migrar recursos de monitoramento

Se você estiver usando o Logging and Monitoring legados com um cluster do GKE em que a versão do plano de controle é 1.15 ou mais recente, as métricas do cluster estarão disponíveis nos modelos de recurso legados do Monitoring e do Cloud Operations para GKE. Isso significa que, mesmo antes de migrar os clusters para o Cloud Operation para o GKE, seus clusters começam a gerar métricas usando o novo modelo de dados sem custo adicional.

A partir de janeiro de 2021, seus painéis e alertas personalizados serão atualizados automaticamente para fazer referência às novas métricas de modelo de recursos. Se você quiser migrar suas próprias configurações do Cloud Monitoring (gráficos em painéis, alertas e grupos personalizados), precisará atualizar cada configuração para refletir o novo modelo de recursos.

Também será necessário migrar as configurações se você mantiver a configuração no Terraform ou em outro gerenciador de implantação e sincronizar as alterações automaticamente.

Como identificar configurações do modelo de dados antigo

Para identificar as configurações do Cloud Monitoring que você precisa atualizar como parte da migração para o Cloud Operations for GKE, veja o painel de status de migração do Kubernetes:

1. No Console do Cloud, acesse o Monitoramento:

   Acessar o Monitoramento

2. No painel de navegação do Monitoring, clique em Configurações e selecione a guia Status da Migração do Kubernetes.

O painel de exemplo a seguir mostra que uma política de alertas precisa ser atualizada:

Como atualizar as configurações do Cloud Monitoring

Se o cluster estiver usando o GKE versão 1.15 ou posterior e estiver usando o Monitoring legado, ele está publicando nos dois modelos de dados. Nesse caso, você tem duas opções de como migrar as configurações.

• Clone as configurações e atualize os clones. Com essa opção, você cria uma cópia dos painéis, das políticas de alerta e dos grupos e migra as cópias para o novo modelo de recurso. Dessa forma, você pode continuar usando o Monitoring para o cluster com o modelo de dados antigo e o novo modelo de dados simultaneamente. Por exemplo, com essa opção, você teria dois painéis: o original que continua a usar o modelo de recursos original e um clone de painel original que usa o novo modelo de recurso.

• Atualize as configurações afetadas. Essa opção muda para o novo modelo de dados no Cloud Monitoring imediatamente.

As seções a seguir fornecem instruções para migrar suas configurações para painéis, políticas de alertas e grupos.

Ponto-chave: se você quiser confirmar que uma configuração está funcionando conforme esperado usando as operações do Cloud para métricas do GKE, primeiro clone e compare as configurações antigas com as novas. No entanto, se você já confirmou que a configuração está funcionando conforme o esperado, usando as métricas do Cloud Operations para GKE, ou se pretende planejar isso depois do upgrade da configuração, faça o upgrade agora.

Uma consideração para decidir qual opção escolher é a quantidade de histórico de monitoramento que você quer ter disponível. Atualmente, o Cloud Monitoring oferece seis semanas de dados históricos para os clusters. Após o upgrade do cluster do GKE que começa a gravar duas vezes nos modelos de dados, o modelo de dados antigo ainda tem as métricas históricas do cluster, enquanto o novo modelo de dados tem apenas as métricas que começam no momento do upgrade.

Se você não precisa dos dados históricos, pode fazer upgrade das configurações no local para o novo modelo de dados a qualquer momento. Se os dados históricos forem importantes, você poderá clonar as configurações e atualizar os clones para usar os novos tipos de modelo de recursos.

Também é possível aguardar seis semanas a partir do início da gravação nos dois modelos de dados. Após seis semanas, os dois modelos de dados têm os mesmos dados históricos, para que você possa fazer o upgrade das configurações em vigor e mudar para o novo modelo de dados.

Como atualizar painéis

Para visualizar os painéis, siga estas etapas:

1. No Console do Cloud, acesse o Monitoramento:

   Acessar o Monitoramento

2. Selecione Painéis.

Para clonar um painel e atualizar o clone, siga estas etapas:

1. Localize o painel que você quer clonar.

2. Clique em Copiar painel () e insira um nome para o painel clonado.

3. Atualize as configurações do novo painel conforme necessário.

Para atualizar as definições de gráfico no painel, siga estas etapas:

1. Clique em Mais opções de gráfico (⋮) do gráfico que você quer editar.

2. Selecione Editar para abrir o painel Editar gráfico.

3. Mude o tipo de recurso e o nome da métrica para que eles sejam traduzidos para o novo modelo de dados. Você também pode atualizar os campos Filter e Group by conforme necessário.

Como atualizar políticas de alertas

Para ver suas políticas de alertas, siga estas etapas:

1. No Console do Cloud, acesse o Monitoramento:

   Acessar o Monitoramento

2. Selecione Alertas.

Para clonar e atualizar uma política de alertas, siga estas etapas:

1. Selecione a política que você quer clonar na tabela Políticas.

2. Clique em Copiar para iniciar o fluxo de criação da cópia da política de alertas.

3. Edite as condições que se referem ao modelo de dados antigo para atualizar o tipo de recurso e o nome da métrica.

   A última etapa do fluxo permite inserir um nome para a política clonada.

Para editar uma política de alertas em vigor, conclua as etapas a seguir:

1. Selecione a política que você quer editar na tabela Políticas.

2. Clique em Editar para atualizar a política.

3. Atualize todas as condições referentes ao modelo de dados antigo.

Atualizando grupos

Não é possível clonar um grupo por meio do Console do Google Cloud. Portanto, se você quiser duplicar um grupo, crie um novo grupo com o mesmo filtro.

Um filtro de grupo pode referenciar o modelo de dados antigo de várias maneiras.

• Tipo de recurso: um grupo pode definir um filtro resource.type="gke_container". Como o tipo gke_container pode ser usado para se referir a vários tipos diferentes de entidades do GKE, é necessário atualizar o filtro para o tipo de recurso que você pretende corresponder: k8s_container,k8s_pod ou k8s_node. Se você quiser corresponder vários tipos, defina um filtro com várias cláusulas combinadas com o operador OR.

• Rótulo cloud_account, um grupo pode definir um filtro resource.metadata.cloud_account="<var>CLOUD_ACCOUNT_ID</<var>". Como parte de uma suspensão de uso separada, o campo de metadados cloud_account não está mais disponível. Use o rótulo resource.labels.project_id.

• Rótulo region, um grupo pode definir um filtro resource.metadata.region="<var>REGION_NAME</<var>". O campo de metadados region não está mais disponível no novo modelo de dados. Se você quiser corresponder entidades do GKE com base na localização geográfica, use o rótulo resource.labels.location.

Como mapear métricas entre modelos de dados

Nesta seção, descrevemos como mapear métricas do modelo de dados antigo para as métricas no novo modelo de dados. O modelo de dados antigo publicou 17 métricas diferentes, listadas nas tabelas abaixo. Algumas dessas métricas foram publicadas em vários tipos de entidades do GKE, o que resulta em mais de 17 mapeamentos para traduzir todas as métricas.

Ao mapear métricas, lembre-se do seguinte:

• O prefixo das métricas antigas é container.googleapis.com/. O prefixo das novas métricas é kubernetes.io/.

• No modelo de dados antigo, o único tipo de recurso é gke_container. Dependendo de como você definiu os rótulos de recursos, esse tipo de recurso pode se referir a contêineres, pods, daemons de sistema e máquinas do GKE, que correspondem aos nós do GKE.

• É possível consultar a API Monitoring usando combinações de pod_id e container_name que não correspondam àquelas listadas na tabela a seguir. Os dados retornados por essas consultas são indefinidos e nenhum mapeamento desses estados indefinidos é fornecido.

  Tipo de entidade do GKE	Filtro
  Contêiner	pod_id != '' e container_name != '' (pod_id não é uma string vazia e container_name não é uma string vazia)
  Pod	pod_id != '' e container_name == '' (pod_id não é a string vazia e container_name é a string vazia)
  Daemon do sistema	pod_id == '' and container_name != 'machine' (pod_id é a string vazia e container_name é docker-daemon, kubelets ou pods)
  Máquina	ppod_id == '' e container_name == 'machine' (pod_id é a string vazia e container_name é a string machine)

As tabelas listam três tipos de mapeamentos:

• Mapeamento direto entre os modelos de dados antigos e os novos.

• Mapeamentos que exigem configuração.

• Mapeamentos de métricas antigas que não têm um equivalente direto no novo modelo.

Mapeamento direto

As métricas a seguir são convertidas diretamente entre os modelos de dados antigos e os novos.

Nome antigo da métrica	Tipo de entidade do GKE antigo	Nome da nova métrica	Novo tipo de recurso do GKE	Observações
container/accelerator/ duty_cycle	Contêiner	container/accelerator/ duty_cycle	k8s_container
container/accelerator/ memory_total	Contêiner	container/accelerator/ memory_total	k8s_container
container/accelerator/ memory_used	Contêiner	container/accelerator/ memory_used	k8s_container
container/accelerator/ request	Contêiner	container/accelerator/ request	k8s_container
container/cpu/ reserved_cores	Contêiner	container/cpu/ limit_cores	k8s_container	Consulte Mapeamentos que exigem configuração para mapeamento quando o recurso é pod
container/cpu/ usage_time	Contêiner	container/cpu/ core_usage_time	k8s_container	Consulte Mapeamentos que exigem configuração para mapeamento quando o recurso é pod
container/cpu/ usage_time	Daemon do sistema	node_daemon/cpu/ core_usage_time	k8s_node	No modelo de dados antigo, gke_container.container_name é docker-daemon, kubelets ou pods. Esses valores de filtro correspondem aos valores no novo campo de modelo de dados metric.component.
container/cpu/ utilization	Contêiner	container/cpu/ limit_utilization	k8s_container
container/disk/ bytes_total	Pod	pod/volume/ total_bytes	k8s_pod	gke_container.device_name (Volume:config-volume) é convertido em k8s_pod.volume_name (config-volume) removendo o Volume: que foi anexado.
container/disk/bytes_used	Pod	pod/volume/ used_bytes	k8s_pod	gke_container.device_name (Volume:config-volume) é convertido em k8s_pod.volume_name (config-volume) removendo o Volume: que foi anexado.
container/memory/ bytes_total	Contêiner	container/memory/ limit_bytes	k8s_container
container/memory/ bytes_used	Contêiner	container/memory/ used_bytes	k8s_container
container/memory/ bytes_used	Daemon do sistema	node_daemon/memory/ used_bytes	k8s_node	No modelo de dados antigo, gke_container.container_name é docker-daemon, kubelets ou pods. Esses valores de filtro correspondem aos valores no novo campo de modelo de dados metric.component.
container/disk/ inodes_free	Máquina	node/ephemeral_storage/ inodes_free	k8s_node	O modelo de dados antigo tem o campo instance_id, um código de número aleatório. O novo modelo de dados tem node_name, um nome legível.
container/disk/ inodes_total	Máquina	node/ephemeral_storage/ inodes_total	k8s_node	O modelo de dados antigo tem o campo instance_id, um código de número aleatório. O novo modelo de dados tem node_name, um nome legível.
container/pid_limit	Máquina	node/pid_limit	k8s_node	O modelo de dados antigo tem o campo instance_id, um código de número aleatório. O novo modelo de dados tem node_name, um nome legível.
container/pid_used	Máquina	node/pid_used	k8s_node	O modelo de dados antigo tem o campo instance_id, um código de número aleatório. O novo modelo de dados tem node_name, um nome legível.

Mapeamentos que exigem configuração

As métricas a seguir são convertidas do novo modelo de dados para o novo modelo com manipulação básica.

Nome antigo da métrica	Tipo de entidade do GKE antigo	Nome da nova métrica	Novo tipo de recurso do GKE	Observações
container/cpu/ reserved_cores	Pod	SUM container/cpu/limit_cores GROUP BY pod_name	k8s_container	O modelo de dados antigo tem um campo pod_id, um UUID. O novo modelo de dados tem pod_name, um nome legível.
container/cpu/ usage_time	Pod	SUM container/cpu/core_usage_time GROUP BY pod_name	k8s_container	O modelo de dados antigo tem um campo pod_id, um UUID. O novo modelo de dados tem um pod_name, um nome legível.
container/disk/ bytes_total	Contêiner	node/ephemeral_storage/ total_bytes	k8s_container	gke_container.device_name é um dos campos / ou logs. Cada um desses valores é igual ao novo valor.
container/disk/ bytes_used	Contêiner	container/ephemeral_storage/ used_bytes	k8s_container	gke_container.device_name é um dos campos / ou logs. Esses dois valores devem ser somados para receber o novo valor. No novo modelo de dados, não é possível receber o valor de / e logs separadamente.
container/memory/ bytes_total	Pod	SUM container/memory/limit_bytes GROUP BY pod_name	k8s_container	O modelo de dados antigo tem um campo pod_id, um UUID. O novo modelo de dados tem pod_name, um nome legível.
container/memory/ bytes_used	Pod	SUM container/memory/used_bytes GROUP BY pod_name	k8s_container	O modelo de dados antigo tem um campo pod_id, um UUID. O novo modelo de dados tem pod_name, um nome legível.

Mapeamentos que não têm um equivalente direto no novo modelo

As métricas a seguir não têm um equivalente no novo modelo de dados.

Uso da CPU no pod

No modelo de dados antigo, essa métrica com base no limite da CPU para cada contêiner é uma média ponderada de utilização da CPU em todos os contêineres em um pod.

No novo modelo de dados, esse valor não existe e precisa ser calculado no lado do cliente com base no limite e na utilização de cada contêiner.

Tempo de atividade

No modelo de dados antigo, esta métrica é uma métrica cumulativa que representa a fração de tempo que um contêiner está disponível nas unidades ms/s. Para um contêiner sempre disponível, o valor é aproximadamente 1.000 ms/s.

No novo modelo de dados, essa métrica é uma medida em horas que informa quanto tempo cada parte do sistema está em execução sem interrupção.

Mudanças de grupo de recursos

Se você definir seus próprios grupos de recursos e usar qualquer um dos tipos de recursos do Logging e Monitoring legados mostrados na tabela anterior Mudanças no tipo de recurso, altere-os para serem os tipos de recursos correspondentes no Cloud Operations para GKE. Se o grupo de recursos incluir gráficos personalizados, talvez seja necessário mudá-los.

Observação: verifique se os grupos atualizados contêm o mesmo número de recursos que tinham antes do upgrade. É provável que poucos recursos indiquem que você perdeu algumas alterações.

Como migrar recursos de geração de registros

Para migrar seus recursos de registro, conclua as etapas nas seções a seguir.

Mudanças no conteúdo de entradas de registro

Quando você atualiza para o Cloud Operations no GKE, talvez descubra que determinadas informações nas entradas de registro foram movidas para campos com nomes diferentes. Essas informações podem ser exibidas em consultas de registros usadas em métricas baseadas em registros, coletores de registros e exclusões de registros.

A tabela a seguir, Mudanças na entrada de registro, lista os novos campos e rótulos. Aqui está um breve resumo:

• Verifique o campo logName nos seus filtros. As entradas de registro do Cloud Operations para GKE usam stdout ou stderr nos nomes de registro, enquanto o Logging e o Monitoring legados usavam uma variedade maior de nomes, incluindo o nome de contêiner. O nome de contêiner ainda está disponível como um rótulo de recurso.
• Verifique o campo labels nas entradas de registro. Esse campo pode conter informações que anteriormente estavam nos campos metadata de entrada de registro.
• Verifique o campo resource.labels nas entradas de registro. Os novos tipos de recursos têm valores de rótulo a mais.

Mudanças nas entradas de registro

(Antigo) Entradas de registro de Logging e Monitoring legados	(Novo) Entradas de registro do Cloud Operations para GKE
Notas de rodapé da tabela: ^1 Os rótulos de recurso identificam recursos específicos que geram métricas, como clusters e nós específicos. ^2 O campo labels é exibido em novas entradas de registro que fazem parte do Cloud Operations para GKE e, de vez em quando, em algumas entradas de registro do Logging e Monitoring legados. Nas operações do Cloud Operations para GKE, ele é usado para armazenar algumas informações anteriormente nos campos de entrada de registro metadata.
Recursos de entrada de registro (Rótulos de recursoresource.labels^1)	Recursos de entrada de registro (Rótulos de recursoresource.labels^1)
Metadados de entrada de registro labels (Rótulos de entrada de registro^2) Rótulos (Exemplos)   compute.googleapis.com/resource_name:     "fluentd-gcp-v3.2.0-d4d9p"   container.googleapis.com/namespace_name:     "kube-system"   container.googleapis.com/pod_name:     "fluentd-gcp-scaler-8b674f786-d4pq2"   container.googleapis.com/stream:     "stdout"	Metadados de entrada de registro labels rótulos (Exemplos)   k8s-pod/app:     "currencyservice"   k8s-pod/pod-template-hash:     "5a67f17c"

Exemplos de registros:

Mudanças no tipo de recurso do contêiner:

O texto vermelho em negrito destaca as diferenças entre os modelos de recursos do Logging e Monitoring legados e do Cloud Operations para GKE.

Modelo de recurso	Exemplos de registros
Logging e Monitoring legados	{ "insertId": "fji4tsf1a8o5h", "jsonPayload": { "pid": 1, "name": "currencyservice-server", "v": 1, "message": "conversion request successful", "hostname": "currencyservice-6995d74b95-zjkmj" }, "resource": { "type": "container", "labels": { "project_id": "my-test-project", "cluster_name": "my-test-cluster", "pod_id": "currencyservice-6995d74b95-zjkmj", "zone": "us-central1-c", "container_name": "server", "namespace_id": "default", "instance_id": "1234567890" } }, "timestamp": "2020-10-02T19:02:47.575434759Z", "severity": "INFO", "labels": { "container.googleapis.com/pod_name": "currencyservice-6995d74b95-zjkmj", "compute.googleapis.com/resource_name": "gke-legacy-cluster-default-pool-c534acb8-hvxk", "container.googleapis.com/stream": "stdout", "container.googleapis.com/namespace_name": "default" }, "logName": "projects/my-test-project/logs/server", "receiveTimestamp": "2020-10-02T19:02:50.972304596Z" }
Cloud Operations for GKE	{ "insertId": "mye361s5zfcl55amj", "jsonPayload": { "v": 1, "name": "currencyservice-server", "pid": 1, "hostname": "currencyservice-5b69f47d-wg4zl", "message": "conversion request successful" }, "resource": { "type": "k8s_container", "labels": { "container_name": "server", "project_id": "my-test-project", "pod_name": "currencyservice-5b69f47d-wg4zl", "namespace_name": "onlineboutique", "location": "us-central1-c", "cluster_name": "my-prod-cluster" } }, "timestamp": "2020-10-02T18:41:55.359669767Z", "severity": "INFO", "labels": { "k8s-pod/app": "currencyservice", "k8s-pod/pod-template-hash": "5b69f47d", "compute.googleapis.com/resource_name": "gke-legacy-cluster-default-pool-c534acb8-hvxk" }, "logName": "projects/my-test-project/logs/stdout", "receiveTimestamp": "2020-10-02T18:41:57.930654427Z" }

Mudanças no tipo de recurso do cluster:

O texto vermelho em negrito destaca as diferenças entre os modelos de recursos do Logging e Monitoring legados e do Cloud Operations para GKE.

Modelo de recurso	Exemplos de registros
Logging e Monitoring legados	{ "insertId": "962szqg9uiyalt", "jsonPayload": { "type": "Normal", "involvedObject": { "apiVersion": "policy/v1beta1", "uid": "a1bc2345-12ab-12ab-1234-123456a123456", "resourceVersion": "50968", "kind": "PodDisruptionBudget", "namespace": "knative-serving", "name": "activator-pdb" }, "apiVersion": "v1", "reason": "NoPods", "source": { "component": "controllermanager" }, "message": "No matching pods found", "kind": "Event", "metadata": { "selfLink": "/api/v1/namespaces/knative-serving/events/activator-pdb.163a42fcb707c1fe", "namespace": "knative-serving", "name": "activator-pdb.163a42fcb707c1fe", "uid": "a1bc2345-12ab-12ab-1234-123456a123456", "creationTimestamp": "2020-10-02T19:17:50Z", "resourceVersion": "1917" } }, "resource": { "type": "gke_cluster", "labels": { "project_id": "my-test-project", "location": "us-central1-c", "cluster_name": "my-prod-cluster" } }, "timestamp": "2020-10-02T21:33:20Z", "severity": "INFO", "logName": "projects/my-test-project/logs/events", "receiveTimestamp": "2020-10-02T21:33:25.510671123Z" }
Cloud Operations for GKE	{ "insertId": "1qzipokg6ydoesp", "jsonPayload": { "involvedObject": { "uid": "a1bc2345-12ab-12ab-1234-123456a123456", "name": "istio-telemetry", "apiVersion": "autoscaling/v2beta2", "resourceVersion": "90505937", "kind": "HorizontalPodAutoscaler", "namespace": "istio-system" }, "source": { "component": "horizontal-pod-autoscaler" }, "kind": "Event", "type": "Warning", "message": "missing request for cpu", "metadata": { "resourceVersion": "3071416", "creationTimestamp": "2020-08-22T14:18:59Z", "name": "istio-telemetry.162d9ce2894d6642", "selfLink": "/api/v1/namespaces/istio-system/events/istio-telemetry.162d9ce2894d6642", "namespace": "istio-system", "uid": "a1bc2345-12ab-12ab-1234-123456a123456" }, "apiVersion": "v1", "reason": "FailedGetResourceMetric" }, "resource": { "type": "k8s_cluster", "labels": { "project_id": "my-test-project" "location": "us-central1-a", "cluster_name": "my-prod-cluster1", } }, "timestamp": "2020-10-02T21:39:07Z", "severity": "WARNING", "logName": "projects/my-test-project/logs/events", "receiveTimestamp": "2020-10-02T21:39:12.182820672Z" }

Mudanças no tipo de recurso do nó:

O texto vermelho em negrito destaca as diferenças entre os modelos de recursos do Logging e Monitoring legados e do Cloud Operations para GKE.

Modelo de recurso	Exemplos de registros
Logging e Monitoring legados	{ "insertId": "16qdegyg9t3n2u5", "jsonPayload": { "SYSLOG_IDENTIFIER": "kubelet", [...] "PRIORITY": "6", "_COMM": "kubelet", "_GID": "0", "_MACHINE_ID": "9565f7c82afd94ca22612c765ceb1042", "_SYSTEMD_UNIT": "kubelet.service", "_EXE": "/home/kubernetes/bin/kubelet" }, "resource": { "type": "gce_instance", "labels": { "instance_id": "1234567890", "zone": "us-central1-a", "project_id": "my-test-project" } }, "timestamp": "2020-10-02T21:43:14.390150Z", "labels": { "compute.googleapis.com/resource_name": "gke-legacy-monitoring-default-pool-b58ff790-29rr" }, "logName": "projects/my-test-project/logs/kubelet", "receiveTimestamp": "2020-10-02T21:43:20.433270911Z" }
Cloud Operations for GKE	{ "insertId": "kkbgd6e5tmkpmvjji", "jsonPayload": { "SYSLOG_IDENTIFIER": "kubelet", [...] "_CAP_EFFECTIVE": "3fffffffff", "_HOSTNAME": "gke-standard-cluster-1-default-pool-f3929440-f4dy", "PRIORITY": "6", "_COMM": "kubelet", "_TRANSPORT": "stdout", "_GID": "0", "MESSAGE": "E1002 21:43:14.870346 1294 pod_workers.go:190] Error syncing pod 99ba1919-d633-11ea-a5ea-42010a800113 (\"stackdriver-metadata-agent-cluster-level-65655bdbbf-v5vjv_kube-system(99ba1919-d633-11ea-a5ea-42010a800113)\"), skipping: failed to \"StartContainer\" for \"metadata-agent\" with CrashLoopBackOff: \"Back-off 5m0s restarting failed container=metadata-agent pod=stackdriver-metadata-agent-cluster-level-65655bdbbf-v5vjv_kube-system(99ba1919-d633-11ea-a5ea-42010a800113)\"" }, "resource": { "type": "k8s_node", "labels": { "cluster_name": "my-prod-cluster-1", "location": "us-central1-a", "node_name": "gke-standard-cluster-1-default-pool-f3929440-f4dy" "project_id": "my-test-project", } }, "timestamp": "2020-10-02T21:43:14.870426Z", "logName": "projects/my-test-project/logs/kubelet", "receiveTimestamp": "2020-10-02T21:43:20.788933199Z" }

Atualizações de configuração do Logging

Nesta seção, descrevemos as alterações que você pode precisar fazer na configuração do Cloud Logging como parte de uma migração para o Cloud Operations para GKE. Também será necessário migrar as configurações se você mantiver a configuração no Terraform ou em outro gerenciador de implantação e sincronizar as alterações automaticamente.

Como gerar registros de consultas

Se você usa consultas para encontrar e filtrar seus registros Cloud Logging e usa qualquer um dos tipos de recursos de Logging e Monitoring legados mostrados na tabela Mudanças de tipo de recurso anterior, altere-os para os tipos do Cloud Operations para GKE correspondentes.

Por exemplo, no Logging e Monitoring legados, você consulta registros de contêiner usando o tipo de recurso container, e no Cloud Operations para GKE você usa o tipo de recurso k8s_container para consultar registros de contêineres.

  resource.type="k8s_container"

Como outro exemplo, no Logging e Monitoring legados, você consulta nomes de registro específicos de contêineres usando o nome do contêiner e, no Cloud Operations para GKE, você usa os registros de nome stdout e stderr para consultar registros do contêiner.

  resource.type="k8s_container"
  log_name="projects/YOUR_PROJECT_NAME/logs/stdout"
  resource.labels.container_name="CONTAINER_NAME"

Métricas com base em registros

Se você definir suas métricas com base em registros e usar tipos de recursos e métricas do Logging e Monitoring legados mostrados nas tabelas de Mudanças nos nomes das métricas ou Mudanças de tipo de recurso anteriores, altere essas métricas e tipos de recursos para os correspondentes do Cloud Operations para GKE.

Observação: se você não vir amostras de suas métricas com base em registros após a atualização para o Cloud Operations para GKE, talvez ainda esteja usando métricas ou tipos de recursos do Logging e Monitoring legados.

Use o comando da ferramenta gcloud a seguir para encontrar as métricas com base em registros:

  gcloud logging metrics list --filter='filter~resource.type=\"container\" OR filter~resource.type=container'

  gcloud logging metrics list --filter='filter~resource.labels.namespace_id'

  gcloud logging metrics list --filter='filter~resource.labels.pod_id'

  gcloud logging metrics list --filter='filter~resource.labels.zone'

Use o comando da ferramenta gcloud a seguir para atualizar as métricas com base em registros:

  gcloud logging metrics update YOUR_LOGS_BASED_METRIC_NAME --log-filter='resource.type=\"container\" OR resource.type=\"k8s_container\"'

  gcloud logging metrics update YOUR_LOGS_BASED_METRIC_NAME --log-filter='resource.labels.namespace_id=\"YOUR_NAMESPACE\" OR resource.labels.namespace_name=\"YOUR_NAMESPACE\"'

  gcloud logging metrics update YOUR_LOGS_BASED_METRIC_NAME --log-filter='resource.labels.pod_id=\"YOUR_POD_NAME\" OR resource.labels.pod_name=\"YOUR_NAME\"'

  gcloud logging metrics update YOUR_LOGS_BASED_METRIC_NAME --log-filter='resource.labels.zone=\"YOUR_ZONE\" OR resource.labels.location=\"YOUR_ZONE\"'

Como alternativa, é possível atualizar suas métricas com base em registros no Console do Cloud.

Exportações de registros

Se você exportar qualquer um dos registros e se a exportação usar os tipos de recursos de Logging e Monitoring legados mostrados na tabela anterior Mudanças de tipo de recurso, altere sua exportação para usar os tipos correspondentes do Cloud Operations para GKE. As entradas de registro do Cloud Operations para GKE usam stdout ou stderr nos nomes de registro, enquanto o Logging and Monitoring legados usam o nome do contêiner.

Há duas considerações importantes para a mudança do nome do registro:

1. Alterações para exportar locais e tabelas de arquivos de destino: os valores do nome de registro no Cloud Operations para GKE incluem stdout ou stderr, em vez do nome do contêiner. O nome do contêiner ainda fica disponível como um rótulo de recurso. O processamento do nome de registro nas exportações ou consultas do Cloud Storage nas tabelas do BigQuery precisa ser alterado para usar os nomes de registro stdout e stderr.
2. Valores de logName – os valores de nome de registro são usados para determinar a estrutura de arquivos exportada no Cloud Storage e a estrutura da tabela no BigQuery. O uso dos arquivos do Cloud Storage e das tabelas do BigQuery precisa ser ajustado para considerar a estrutura de pasta no Cloud Storage e as estruturas de tabela no BigQuery.

Observação: antes de atualizar para o Cloud Operations para GKE, anote o número aproximado de entradas de registro que você está exportando do projeto do GCP. Dessa maneira, é possível verificar se você ainda está recebendo um número apropriado.

Use os seguintes comandos da ferramenta de linha de comando gcloud para localizar os coletores do Logging afetados:

  gcloud logging sinks list --filter='filter~resource.type=\"container\" OR filter~resource.type=container'

  gcloud logging sinks list --filter='filter~resource.labels.namespace_id'

  gcloud logging sinks list --filter='filter~resource.labels.pod_id'

  gcloud logging sinks list --filter='filter~resource.labels.zone'

Use o comando de ferramenta gcloud a seguir para atualizar os coletores do Logging.

  gcloud logging sinks update YOUR_SINK_NAME --log-filter='resource.type=\"container\" OR resource.type=\"k8s_container\"'

  gcloud logging sinks update YOUR_SINK_NAME --log-filter='resource.labels.namespace_id=\"YOUR_NAMESPACE\" OR resource.labels.namespace_name=\"YOUR_NAMESPACE\"'

  gcloud logging sinks update YOUR_SINK_NAME --log-filter='resource.labels.pod_id=\"YOUR_POD_NAME\" OR resource.labels.pod_name=\"YOUR_NAME\"'

  gcloud logging sinks update YOUR_SINK_NAME --log-filter='resource.labels.zone=\"YOUR_ZONE\" OR resource.labels.location=\"YOUR_ZONE\"'

Como alternativa, é possível atualizar suas métricas com base em registros no Console do Cloud.

Exclusões de registros

Se você excluir algum dos registros e os filtros de exclusão usarem os tipos de recurso de geração do Logging e Monitoring legados mostrados na tabela Mudanças de tipo de recurso anterior, alterar os filtros de exclusão para usar os tipos de recurso correspondentes do Cloud Operations para GKE.

Para informações sobre como visualizar suas exclusões de registros, consulte o guia Como visualizar filtros de exclusão.

Observação: antes de atualizar para o Cloud Operations para GKE, anote o número aproximado de entradas de registro que você está excluindo do projeto do GCP. Dessa maneira, é possível verificar se você ainda está recebendo um número apropriado.

Mudanças em locais de registro

No Cloud Logging, os registros são armazenados com o tipo de recurso que os gerou. Como esses tipos foram alterados no Cloud Operations para GKE, procure seus registros nos novos tipos de recursos, como Kubernetes Container, não nos tipos de Logging e Monitoring legados, como GKE Container.

Atualizar a configuração do cluster

Depois que você migrou qualquer registro e recursos de monitoramento para usar o formato de dados do Cloud Operations para GKE, a última etapa é atualizar seu cluster do GKE para usar o Cloud Operations para GKE.

Para atualizar a configuração de geração de registros e monitoramento do cluster do GKE, siga estas etapas:

CONSOLE

1. Acesse a página Clusters do GKE do seu projeto. Clique no botão a seguir para acessar:

   Acessar os clusters do Kubernetes

2. Clique no cluster que você quer atualizar para usar o Cloud Operations para GKE.

3. Na linha Cloud Operations para GKE, clique no ícone Editar.

4. Na caixa de diálogo exibida, confirme se a opção Ativar o Cloud Operations para GKE está selecionada.

5. No menu suspenso dentro da caixa de diálogo, selecione quais registros e métricas você quer coletar. A configuração padrão (recomendado) do Cloud Operations para GKE é geração de registros e monitoramento do sistema e de cargas de trabalho. Selecionar qualquer valor nesse menu suspenso que não seja "Logging e Monitoring legados" atualizará o cluster para começar a usar o Cloud Operations para GKE em vez de Logging e Monitoring legados.

6. Clique em Salvar alterações.

GCLOUD

1. Execute este comando:

   gcloud container clusters update [CLUSTER_NAME] \
     --zone=[ZONE] \
     --project=[PROJECT_ID] \
     --logging=SYSTEM,WORKLOAD \
     --monitoring=SYSTEM
   

A seguir

• Para saber mais sobre o novo painel do Cloud Operations para GKE, consulte Como observar o sistema.
• Para informações sobre a visualização dos registros, consulte Como visualizar os registros do GKE.