Ajude a moldar o futuro das operações de software e compartilhe seu feedback com a pesquisa State of DevOps 2021.

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

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.

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.

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:

Versão GKE Logging e Monitoring legados Cloud Operations for GKE
1.14 Disponível Padrão
1.15 Disponível Padrão
1.16 Disponível Padrão
1.17 Disponível Padrão
1.18 Disponível Padrão
1.19 Disponível Padrão
1,20 Não disponível Padrão

Para mais informações sobre a suspensão de uso do Logging and Monitoring legados, consulte o guia Suporte ao uso da suspensão de uso do GKE legado.

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

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

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_id1
  namespace_id
  pod_id
  project_id
  zone2

Somente Logging:
container (Contêiner do GKE)

Rótulos:
  cluster_name
  container_name
  instance_id1
  namespace_id
  pod_id
  project_id
  zone2

Monitoring e Logging:
k8s_container (Contêiner do Kubernetes)

Rótulos:
  cluster_name
  container_name
  metadata.system_labels.node_name3
  namespace_name
  pod_name
  project_id
  location2

Somente Logging::
gce_instance (Instância de VM do Compute Engine)4

Rótulos:
  cluster_name
  instance_id
  project_id
  zone2 		Monitoring e Logging
k8s_node4 (Nó do Kubernetes)

Rótulos:
  cluster_name
  node_name
  project_id
  location2

(nenhum)
 Monitoring e Logging:
k8s_pod5 (Pod do Kubernetes)

Rótulos:
  cluster_name
  namespace_name
  pod_name
  project_id
  location2

Somente Logging
gke_cluster (GKE_cluster)

Rótulos:
  cluster_name
  project_id
  location

Monitoring e Logging:
k8s_cluster5 (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

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.

      Exibição de clusters usando as soluções legadas.

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:

Exibição do painel de migração.

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.

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.

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.labels1)
 Recursos de entrada de registro
(Rótulos de recursoresource.labels1)
Metadados de entrada de registro
labels (Rótulos de entrada de registro2)

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.

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.

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.

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] \
  --enable-stackdriver-kubernetes

A seguir