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.
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:
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 prefixocontainer.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
elabels
. Por exemplo, o camporesource.labels.namespace_id
foi alterado pararesource.labels.namespace_name
enquanto o valor não mudou.mudanças de logName: as entradas de registro do Cloud Operations para GKE usam
stdout
oustderr
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 emresource.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.
(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:
container
(Contêiner do GKE)
Rótulos:
|
Monitoring e Logging:
k8s_container
(Contêiner do Kubernetes)
Rótulos:
|
|||
Somente Logging::
gce_instance
(Instância de VM do Compute Engine)4Ró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:
|
|||
Somente Logging
gke_cluster (GKE_cluster)
Rótulos:
|
Monitoring e Logging:
k8s_cluster 5 (Cluster do Kubernetes)
Rótulos:
|
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:
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.
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.
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
Use o painel de GKE Clusters do Cloud Monitoring para identificar quais clusters em um projeto ainda estão usando o Logging e o Monitoring legados:
- Clique no painel Clusters do Cloud Monitoring para GKE.
- Verifique se o "Escopo das métricas" selecionado inclui o projeto do Google Cloud que você quer analisar para os clusters que executam o Logging e o Monitoring legados.
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:
No console, acesse o Monitoring:
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.
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 estes passos:
No Console, acesse o Monitoring:
Selecione Painéis.
Para clonar um painel e atualizar o clone, siga estas etapas:
Localize o painel que você quer clonar.
Clique em Copiar painel (
) e insira um nome para o painel clonado.Atualize as configurações do novo painel conforme necessário.
Para atualizar as definições de gráfico no painel, siga estas etapas:
Clique em Mais opções de gráfico (⋮) do gráfico que você quer editar.
Selecione Editar para abrir o painel Editar gráfico.
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 estes passos:
No Console, acesse o Monitoring:
Selecione Alertas.
Para clonar e atualizar uma política de alertas, siga estas etapas:
Selecione a política que você quer clonar na tabela Políticas.
Clique em Copiar para iniciar o fluxo de criação da cópia da política de alertas.
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:
Selecione a política que você quer editar na tabela Políticas.
Clique em Editar para atualizar a política.
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 tipogke_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
ouk8s_node
. Se você quiser corresponder vários tipos, defina um filtro com várias cláusulas combinadas com o operadorOR
.Rótulo
cloud_account
, um grupo pode definir um filtroresource.metadata.cloud_account="<var>CLOUD_ACCOUNT_ID</<var>"
. Como parte de uma suspensão de uso separada, o campo de metadadoscloud_account
não está mais disponível. Use o rótuloresource.labels.project_id
.Rótulo
region
, um grupo pode definir um filtroresource.metadata.region="<var>REGION_NAME</<var>"
. O campo de metadadosregion
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ótuloresource.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
econtainer_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 econtainer_name
não é uma string vazia)Pod pod_id != '' e container_name == ''
(pod_id
não é a string vazia econtainer_name
é a string vazia)Daemon do sistema pod_id == '' and container_name != 'machine'
(pod_id
é a string vazia econtainer_name
édocker-daemon
,kubelets
oupods
)Máquina ppod_id == '' e container_name == 'machine'
(pod_id
é a string vazia econtainer_name
é a stringmachine
)
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 usamstdout
oustderr
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 camposmetadata
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.
(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 recurso resource.labels 1) |
Recursos de entrada de registro (Rótulos de recurso resource.labels 1) |
|||
Metadados de entrada de registrolabels (Rótulos de entrada de registro2)Rótulos (Exemplos) compute.googleapis.com/resource_name:
container.googleapis.com/namespace_name:
container.googleapis.com/pod_name:
container.googleapis.com/stream:
|
Metadados de entrada de registrolabels rótulos (Exemplos) k8s-pod/app:
k8s-pod/pod-template-hash:
|
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 no Mudanças de tipo de recurso, 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 seguinte comando da CLI gcloud 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 seguinte comando da CLI gcloud 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:
- Alterações para exportar locais e tabelas de arquivos de destino: os valores do nome
de registro no Cloud Operations para GKE incluem
stdout
oustderr
, 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 registrostdout
estderr
. - 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 Google Cloud CLI para encontrar os coletores de registro afetados do Logging:
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 seguinte comando da CLI gcloud para atualizar os seus 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
Acesse a página Clusters do GKE do seu projeto. Clique no botão a seguir para acessar:
Clique no cluster que você quer atualizar para usar o Cloud Operations para GKE.
Na linha Cloud Operations para GKE, clique no ícone Editar.
Na caixa de diálogo exibida, confirme se a opção Ativar o Cloud Operations para GKE está selecionada.
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.
Clique em Salvar alterações.
GCLOUD
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.