Neste documento, fornecemos informações para ajudar a diagnosticar e resolver problemas de ingestão de dados, para registros e métricas, no Agente de operações em execução. Se o Agente de operações não estiver em execução, consulte Resolver problemas de instalação e inicialização.
Antes de começar
Antes de tentar corrigir um problema, verifique o status das verificações de integridade do agente.
O console do Google Cloud mostra a instalação do agente de operações travada em "Pendente"
Mesmo após a instalação bem-sucedida do agente de operações, o console do Google Cloud ainda poderá exibir o status "Pendente". Use gcpdiag para confirmar a instalação do agente de operações e verificar se o agente está transmitindo registros e métricas da sua instância de VM.
Razões comuns para falha na instalação
A instalação do Agente de operações pode falhar pelos seguintes motivos:
A VM não tem uma conta de serviço anexada. Anexe uma conta de serviço à VM e reinstale o agente de operações.
A VM já tem um dos agentes legados instalados, o que impede a instalação do agente de operações. Desinstale os agentes legados e reinstale o agente de operações.
Razões comuns para falhas na transmissão de telemetria
Um agente de operações instalado e em execução pode falhar ao enviar logs, métricas ou ambos de uma VM pelos seguintes motivos:
- A conta de serviço anexada à VM não tem o papel
roles/logging.logWriter
ouroles/monitoring.metricWriter
. - O escopo de acesso de criação de log ou monitoramento não está ativado. Para informações sobre como verificar e atualizar escopos de acesso, consulte Verificar seus escopos de acesso.
- A API Logging ou a API Monitoring não estão ativadas.
Use verificações de integridade do agente para identificar a causa raiz e a solução correspondente.
O agente está em execução, mas os dados não foram ingeridos
Use o Metrics Explorer para consultar a métrica uptime
do agente e verificar se o componente do agente, google-cloud-ops-agent-metrics
ou google-cloud-ops-agent-logging
, está gravando na métrica.
-
No Console do Google Cloud, acesse a página do leaderboard Metrics Explorer:
Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Monitoramento.
- Na alternância do Builder Code rotulado, selecione Código e defina a linguagem como MQL.
Digite a seguinte consulta e clique em Executar:
fetch gce_instance | metric 'agent.googleapis.com/agent/uptime' | align rate(1m) | every 1m
O agente está enviando registros para o Cloud Logging?
Se o agente estiver em execução, mas não enviar registros, cheque o status das verificações de integridade do ambiente de execução do agente.
Erros do pipeline
Se você vir o erro de ambiente de execução LogPipelineErr
("Falha no pipeline
de geração de registros do agente de operações"), o subagente de geração de registros encontrou um problema ao gravar os
registros. Verifique as seguintes condições:
- Verifique se os arquivos de armazenamento do subagente de geração de registros estão acessíveis. Esses arquivos
são encontrados nos seguintes locais:
- Linux:
/var/lib/google-cloud-ops-agent/fluent-bit/buffers/
- Windows:
C:\Program Files\Google\Cloud Operations\Ops Agent\run\buffers\
- Linux:
- Verifique se o disco da VM não está cheio.
- Verifique se a configuração de geração de registros está correta.
Para seguir as etapas de processo, use o SSH na VM.
Se você alterar a configuração da geração de registros ou se os arquivos do buffer estiverem acessíveis e o disco da VM não estiver cheio, reinicie o agente de operações:
Linux
- Para reiniciar o agente, execute o seguinte comando na instância:
sudo systemctl restart google-cloud-ops-agent
- Para confirmar se o agente foi reiniciado, execute o seguinte comando e
verifique se os componentes "Agente de métricas" e "Agente do Logging" foram iniciados:
sudo systemctl status "google-cloud-ops-agent*"
Windows
- Conecte-se à sua instância usando o RDP ou uma ferramenta semelhante e faça login no Windows.
- Abra um terminal do PowerShell com privilégios de administrador. Para isso, clique com o botão direito do mouse no ícone do PowerShell e selecione Executar como administrador
- Para reiniciar o agente, execute o seguinte comando do PowerShell:
Restart-Service google-cloud-ops-agent -Force
- Para confirmar se o agente foi reiniciado, execute o seguinte comando e
verifique se os componentes "Agente de métricas" e "Agente do Logging" foram iniciados:
Get-Service google-cloud-ops-agent*
Erros de análise de registros
Se você vir o erro de ambiente de execução LogParseErr
("O agente de operações não conseguiu analisar os registros"), o problema mais provável está na configuração de um operador de geração de registros.
Para resolver esse problema, faça o seguinte:
- Verifique se a configuração de qualquer
processador
parse_json
está correta. - Verifique se a configuração de qualquer
processador
parse_regex
está correta. - Se você não tiver processadores
parse_json
ouparse_regex
, verifique a configuração de todos os outros processadores de geração de registros.
Para seguir as etapas de processo, use o SSH na VM.
Se você alterar a configuração da geração de registros, reinicie o agente de operações:
Linux
- Para reiniciar o agente, execute o seguinte comando na instância:
sudo systemctl restart google-cloud-ops-agent
- Para confirmar se o agente foi reiniciado, execute o seguinte comando e
verifique se os componentes "Agente de métricas" e "Agente do Logging" foram iniciados:
sudo systemctl status "google-cloud-ops-agent*"
Windows
- Conecte-se à sua instância usando o RDP ou uma ferramenta semelhante e faça login no Windows.
- Abra um terminal do PowerShell com privilégios de administrador. Para isso, clique com o botão direito do mouse no ícone do PowerShell e selecione Executar como administrador
- Para reiniciar o agente, execute o seguinte comando do PowerShell:
Restart-Service google-cloud-ops-agent -Force
- Para confirmar se o agente foi reiniciado, execute o seguinte comando e
verifique se os componentes "Agente de métricas" e "Agente do Logging" foram iniciados:
Get-Service google-cloud-ops-agent*
Verifique as métricas locais
Para seguir as etapas de processo, use o SSH na VM.
- O módulo de geração de registros está em execução? Use os seguintes comandos para verificar:
Linux
sudo systemctl status google-cloud-ops-agent"*"
Windows
Abra o Windows PowerShell como administrador e execute:
Get-Service google-cloud-ops-agent
Também é possível verificar o status do serviço no app "Serviços" e inspecionar os processos em execução no app "Gerenciador de tarefas".
Verifique o registro do módulo de geração de registro
Nesta etapa, é necessário usar o SSH na VM.
Para encontrar os registros do módulo de geração de registros, acesse /var/log/google-cloud-ops-agent/subagents/*.log
para Linux e C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log
para Windows. Se não houver registros, o serviço do agente não está sendo executado
corretamente. Primeiro, acesse a seção O agente está instalado, mas não está em execução
para corrigir essa condição.
Erros de permissão 403 podem ser exibidos ao gravar na API Logging. Exemplo:
[2020/10/13 18:55:09] [ warn] [output:stackdriver:stackdriver.0] error { "error": { "code": 403, "message": "Cloud Logging API has not been used in project 147627806769 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/logging.googleapis.com/overview?project=147627806769 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.", "status": "PERMISSION_DENIED", "details": [ { "@type": "type.googleapis.com/google.rpc.Help", "links": [ { "description": "Google developers console API activation", "url": "https://console.developers.google.com/apis/api/logging.googleapis.com/overview?project=147627806769" } ] } ] } }
Para corrigir esse erro, ative a API Logging e defina o papel Gravador de registros.
Um problema de cota para a API Logging poderá ser exibido. Exemplo:
error="8:Insufficient tokens for quota 'logging.googleapis.com/write_requests' and limit 'WriteRequestsPerMinutePerProject' of service 'logging.googleapis.com' for consumer 'project_number:648320274015'." error_code="8"
Para corrigir esse erro, aumente a cota ou reduza a capacidade do registro.
Talvez você veja os seguintes erros no registro do módulo:
{"error":"invalid_request","error_description":"Service account not enabled on this instance"}
ou
can't fetch token from the metadata server
Esses erros podem indicar que você implantou o agente sem uma conta de serviço ou credenciais especificadas. Para informações sobre como resolver esse problema, consulte Autorizar o agente de operações.
O agente está enviando métricas para o Cloud Monitoring?
Verifique o registro do módulo de métricas
Nesta etapa, é necessário usar o SSH na VM.
Você encontra os registros do módulo de métricas no syslog. Se não houver registros, isso indicará que o serviço do agente não está sendo executado corretamente. Primeiro, acesse a seção O agente está instalado, mas não está em execução para corrigir essa condição.
É possível ver erros
PermissionDenied
ao gravar na API Monitoring. Esse erro ocorrerá se a permissão do agente de operações não estiver configurada corretamente. Exemplo:Nov 2 14:51:27 test-ops-agent-error otelopscol[412]: 2021-11-02T14:51:27.343Z#011info#011exporterhelper/queued_retry.go:231#011Exporting failed. Will retry the request after interval.#011{"kind": "exporter", "name": "googlecloud", "error": "[rpc error: code = PermissionDenied desc = Permission monitoring.timeSeries.create denied (or the resource may not exist).; rpc error: code = PermissionDenied desc = Permission monitoring.timeSeries.create denied (or the resource may not exist).]", "interval": "6.934781228s"}
Para corrigir esse erro, ative a API Monitoring e defina o papel Gravador de métricas do Monitoring.
É possível ver erros
ResourceExhausted
ao gravar na API Monitoring. Esse erro ocorrerá se o projeto atingir o limite de cotas da API Monitoring. Exemplo:Nov 2 18:48:32 test-ops-agent-error otelopscol[441]: 2021-11-02T18:48:32.175Z#011info#011exporterhelper/queued_retry.go:231#011Exporting failed. Will retry the request after interval.#011{"kind": "exporter", "name": "googlecloud", "error": "rpc error: code = ResourceExhausted desc = Quota exceeded for quota metric 'Total requests' and limit 'Total requests per minute per user' of service 'monitoring.googleapis.com' for consumer 'project_number:8563942476'.\nerror details: name = ErrorInfo reason = RATE_LIMIT_EXCEEDED domain = googleapis.com metadata = map[consumer:projects/8563942476 quota_limit:DefaultRequestsPerMinutePerUser quota_metric:monitoring.googleapis.com/default_requests service:monitoring.googleapis.com]", "interval": "2.641515416s"}
Para corrigir esse erro, aumente a cota ou reduza a capacidade das métricas.
Talvez você veja os seguintes erros no registro do módulo:
{"error":"invalid_request","error_description":"Service account not enabled on this instance"}
ou
can't fetch token from the metadata server
Esses erros podem indicar que você implantou o agente sem uma conta de serviço ou credenciais especificadas. Para informações sobre como resolver esse problema, consulte Autorizar o agente de operações.
Problemas de conectividade de rede
Se o agente estiver em execução, mas não enviar registros nem métricas, talvez você tenha um problema de rede. Os tipos de problemas de conectividade de rede que você pode encontrar variam com a topologia do aplicativo. Para ter uma visão geral da rede do Compute Engine, consulte este link.
Veja algumas causas comuns de problemas de conectividade:
- Regras de firewall que interferem no tráfego de entrada. Veja informações sobre regras de firewall em Usar regras de firewall da VPC.
- Problemas na configuração de um proxy HTTP.
- Configuração do DNS.
O Agente de operações executa verificações de integridade que detectam erros de conectividade de rede. Consulte a documentação das verificações de integridade para ver as ações sugeridas para erros de conectividade.
A partir da versão 2.28.0, o Agente de operações limita a quantidade de espaço em disco que pode ser usada para armazenar blocos de buffer. O agente de operações cria blocos de buffer quando não é possível enviar os dados da geração de registros
para a API Cloud Logging. Sem limite, esses blocos podem consumir todo o
espaço disponível, interrompendo outros serviços na VM. Quando uma falha temporária de rede faz com que os blocos de buffer sejam gravados em disco, o Agente de operações usa uma quantidade de espaço em disco específica da plataforma para armazenar os blocos. Uma mensagem como
a do exemplo a seguir também aparece em
/var/log/google-cloud-ops-agent/subagents/logging-module.log
, em
VMs do Linux, ou C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log
,
em VMs do Windows, quando a VM não consegue enviar os blocos de buffer para a API Cloud Logging:
[2023/04/15 08:21:17] [warn] [engine] failed to flush chunk
Quero coletar apenas métricas ou registros, não ambos
Por padrão, o Agente de operações coleta métricas e registros.
Para desativar a coleta de métricas ou registros, use o arquivo config.yaml
do Agente de operações para substituir o serviço logging
ou metrics
padrão
para que o pipeline padrão não tenha receptores. Para ver mais informações, consulte
os tópicos a seguir:
- Exemplo de configurações da geração de registros do
service
. - Exemplo de configurações
service
de métricas.
A interrupção da ingestão de dados desativando os serviços do subagente do agente de operações "Agente de geração de registros" ou "Agente de monitoramento" resulta em uma configuração inválida e não é compatível.
As métricas estão sendo coletadas, mas algo parece errado
O agente está registrando mensagens "Falha na exportação. Nova tentativa"
Você verá entradas de registro "Falha na exportação" quando o primeiro ponto de dados de uma métrica cumulativa for descartado. Os registros a seguir não são nocivos e podem ser ignorados com segurança:
Jul 13 17:28:03 debian9-trouble otelopscol[2134]: 2021-07-13T17:28:03.092Z info exporterhelper/queued_retry.go:316 Exporting failed. Will retry the request a fter interval. {"kind": "exporter", "name": "googlecloud/agent", "error": "rpc error: code = InvalidArgument desc = Field timeSeries[1].points[0].interval.start_time had a n invalid value of "2021-07-13T10:25:18.061-07:00": The start time must be before the end time (2021-07-13T10:25:18.061-07:00) for the non-gauge metric 'agent.googleapis.com/ag ent/uptime'.", "interval": "23.491024535s"} Jul 13 17:28:41 debian9-trouble otelopscol[2134]: 2021-07-13T17:28:41.269Z info exporterhelper/queued_retry.go:316 Exporting failed. Will retry the request a fter interval. {"kind": "exporter", "name": "googlecloud/agent", "error": "rpc error: code = InvalidArgument desc = Field timeSeries[0].points[0].interval.start_time had a n invalid value of "2021-07-13T10:26:18.061-07:00": The start time must be before the end time (2021-07-13T10:26:18.061-07:00) for the non-gauge metric 'agent.googleapis.com/ag ent/monitoring/point_count'.", "interval": "21.556591578s"}
O agente está registrando "Não foi possível gravar a série temporal: os pontos devem ser escritos em ordem". mensagens
Se você fez upgrade para o agente de operações a partir do agente do Monitoring legado e está recebendo a seguinte mensagem de erro ao gravar métricas cumulativas, a solução é reinicializar a VM. O agente de operações e o agente do Monitoring calculam os horários de início de métricas cumulativas de maneira diferente, o que pode levar a pontos que aparecem fora de ordem. A reinicialização da VM redefine o horário de início e corrige esse problema.
Jun 2 14:00:06 * otelopscol[4035]: 2023-06-02T14:00:06.304Z#011error#011exporterhelper/queued_retry.go:367#011Exporting failed. Try enabling retry_on_failure config option to retry on retryable errors#011{"error": "failed to export time series to GCM: rpc error: code = InvalidArgument desc = One or more TimeSeries could not be written: Points must be written in order. One or more of the points specified had an older start time than the most recent point.: gce_instance{instance_id:,zone:} timeSeries[0-199]: agent.googleapis.com/memory/bytes_used{state:slab}
O agente está registrando mensagens "O token deve ser um token de curta duração (60 minutos) e em um período razoável"
Se a mensagem de erro a seguir for exibida quando o agente gravar métricas, isso indica que o relógio do sistema não está sincronizado corretamente:
Invalid JWT: Token must be a short-lived token (60 minutes) and in a reasonable timeframe. Check your iat and exp values in the JWT claim.
Para informações sobre como sincronizar os relógios do sistema, consulte Configurar o NTP em uma VM.
O agente está registrando "o receptor de métricas com o tipo "nvml" não é compatível"
Se estiver coletando métricas da GPU NVIDIA Management Library (NVML)
(agent.googleapis.com/gpu
) usando o receptor nvml
,
você está usando uma versão das Operações Agente compatível com visualização para as métricas NVML. O suporte para essas métricas foi disponibilizado para todos na versão 2.38.0 do Agente de operações. Na versão do GA, a coleta de métricas feita pelo receptor nvml
foi mesclada no receptor hostmetrics
, e o receptor nvml
foi removido.
Você vê a mensagem de erro "O receptor de métricas com o tipo nvml não é compatível" depois de instalar o Agente de operações versão 2.38.0 ou mais recente quando você estava usando o receptor de visualização nvml
e substituiu o intervalo de coleções padrão no arquivo de configuração especificado pelo usuário. O erro ocorre
porque o receptor nvml
não existe mais, mas o arquivo de configuração
especificado pelo usuário ainda se refere a ele.
Para corrigir esse problema, atualize o arquivo de configuração especificado pelo usuário para
modificar o intervalo de coleta no receptor hostmetrics
.
As métricas da GPU estão ausentes
Se o Agente de operações estiver coletando algumas métricas, mas algumas ou todas as
métricas GPU da biblioteca de gerenciamento (NVML, na sigla em inglês) (agent.googleapis.com/gpu
)
estão ausentes, pode haver um problema de configuração ou
ausência de processos usando a GPU.
Se você não estiver coletando métricas da GPU, verifique o driver da GPU. Para coletar métricas da GPU, o Agente de operações exige que o driver da GPU esteja instalado e configurado na VM. Para verificar o driver, faça o seguinte:
Para verificar se o driver está instalado e sendo executado corretamente, siga as etapas para verificar a instalação do driver da GPU.
Se o driver não estiver instalado, faça o seguinte:
- Instale o driver da GPU.
Reinicie o Agente de operações.
É necessário reiniciar o Agente de operações depois de instalar ou fazer upgrade do driver da GPU.
Verifique os registros do Agente de operações para confirmar se a comunicação foi iniciada com sucesso. As mensagens de registro serão parecidas com estas:
Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.771Z info nvmlreceiver/client.go:128 Successfully initialized Nvidia Management Library Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.772Z info nvmlreceiver/client.go:151 Nvidia Management library version is 12.555.42.06 Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.772Z info nvmlreceiver/client.go:157 NVIDIA driver version is 555.42.06 Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.781Z info nvmlreceiver/client.go:192 Discovered Nvidia device 0 of model NVIDIA L4 with UUID GPU-fc5a05a7-8859-ec33-c940-3cf0930c0e61.
Se o driver da GPU estiver instalado e os registros do Agente de operações indicarem que o Agente de operações está se comunicando com o driver, mas você não estiver vendo nenhuma métrica da GPU, o problema pode ser um problema com o gráfico que você está usando. Para saber como solucionar problemas com gráficos, consulte O gráfico não exibe nenhum dado.
Se você estiver coletando algumas métricas da GPU, mas não tiver as métricas processes
(processes/max_bytes_used
e processes/utilization
),
você não terá processos em execução nas GPUs. As métricas processes
da GPU não estão
coletados se não houver processos em execução na GPU.
Algumas das métricas estão ausentes ou são inconsistentes
Há um pequeno número de métricas que o agente de operações versão 2.0.0 ou mais recente processa de maneira diferente das versões de "visualização" do agente de operações (versões anteriores ao 2.0.0) ou do agente do Monitoring de dados.
Na tabela a seguir, descrevemos as diferenças nos dados ingeridos pelo agente de operações e pelo agente do Monitoring.Tipo de métrica, omitindoagent.googleapis.com |
Agente de operações (disponibilidade geral)† | Agente de operações (visualização)† | Agente do Monitoring |
---|---|---|---|
cpu_state |
Os valores possíveis para Windows são
idle , interrupt, system e user . |
Os valores possíveis para Windows são
idle , interrupt, system e user . |
Os valores possíveis para Windows são
idle e used .
|
disk/bytes_used edisk/percent_used |
Ingestão com o caminho completo no rótulo device . Por exemplo, /dev/sda15 .Não ingerido para dispositivos virtuais, como tmpfs e udev . |
Processado sem /dev no caminho no rótulo device ; por exemplo, sda15 .Ingestão para dispositivos virtuais, como tmpfs e udev . |
Processado sem /dev no caminho no rótulo device ; por exemplo, sda15 .Ingestão para dispositivos virtuais, como tmpfs e udev . |
Problemas específicos do Windows
As seções a seguir se aplicam apenas ao agente de operações em execução no Windows.
Contadores de desempenho corrompidos no Windows
Se o subagente de métricas não for iniciado, você poderá ver um dos seguintes erros no Cloud Logging:
Failed to retrieve perf counter object "LogicalDisk"
Failed to retrieve perf counter object "Memory"
Failed to retrieve perf counter object "System"
Esses erros podem ocorrer se os contadores de desempenho do sistema forem corrompidos. Para resolver os erros, recrie os contadores de desempenho. No PowerShell como administrador, execute:
cd C:\Windows\system32
lodctr /R
O comando anterior pode falhar de vez em quando. Nesse caso, atualize o PowerShell e tente novamente até conseguir.
Depois que o comando for bem-sucedido, reinicie o agente de operações:
Restart-Service -Name google-cloud-ops-agent -Force
Redefinir completamente o estado do agente
Se o agente entrar em um estado não recuperável, siga estas etapas para restaurá-lo em um novo estado.
Linux
Interrompa o serviço do agente:
sudo service google-cloud-ops-agent stop
Remova o pacote do agente:
curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --uninstall --remove-repo
Remova os registros próprios do agente no disco:
sudo rm -rf /var/log/google-cloud-ops-agent
Remova os buffers locais do agente no disco:
sudo rm -rf /var/lib/google-cloud-ops-agent/fluent-bit/buffers/*/
Reinstale e reinicie o agente:
curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --also-install
sudo service google-cloud-ops-agent restart
Windows
Interrompa o serviço do agente:
Stop-Service google-cloud-ops-agent -Force;
Get-Service google-cloud-ops-agent* | %{sc.exe delete $_};
taskkill /f /fi "SERVICES eq google-cloud-ops-agent*";
Remova o pacote do agente:
(New-Object Net.WebClient).DownloadFile("https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.ps1", "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1");
$env:REPO_SUFFIX="";
Invoke-Expression "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1 -Uninstall -RemoveRepo"
Remova os registros próprios do agente no disco:
rmdir -R -ErrorAction SilentlyContinue "C:\ProgramData\Google\Cloud Operations\Ops Agent\log";
Remova os buffers locais do agente no disco:
Get-ChildItem -Path "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\" -Directory -ErrorAction SilentlyContinue | %{rm -r -Path $_.FullName}
Reinstale e reinicie o agente:
(New-Object Net.WebClient).DownloadFile("https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.ps1", "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1");
$env:REPO_SUFFIX="";
Invoke-Expression "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1 -AlsoInstall"
Redefinir, mas salvar os arquivos de buffer
Se a VM não tiver blocos de buffer corrompidos, ou seja, não há mensagens format
check failed
no arquivo de registro do agente de operações), ignore os comandos anteriores que removem os buffers locais ao redefinir o estado do agente.
Se a VM tiver blocos de buffer corrompidos, será necessário removê-los. As opções a seguir descrevem maneiras diferentes de lidar com os buffers. As outras etapas descritas em Redefinir o estado do agente completamente ainda são aplicáveis.
Opção 1: exclua todo o diretório
buffers
. Essa é a opção mais fácil, mas pode resultar na perda dos registros em buffer não corrompidos ou da duplicação de registro devido à perda dos arquivos de posição.Linux
sudo rm -rf /var/lib/google-cloud-ops-agent/fluent-bit/buffers
Windows
rmdir -R -ErrorAction SilentlyContinue "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers";
Opção 2: exclua os subdiretórios de buffer do diretório
buffers
, mas deixe os arquivos de posição. Essa abordagem é descrita em Redefinir completamente o estado do agente.Opção 3: se você não quiser excluir todos os arquivos de buffer, poderá extrair os nomes dos arquivos de buffer corrompidos dos registros próprios do agente e excluir apenas o buffer corrompido.
Linux
grep "format check failed" /var/log/google-cloud-ops-agent/subagents/logging-module.log | sed 's|.*format check failed: |/var/lib/google-cloud-ops-agent/fluent-bit/buffers/|' | xargs sudo rm -f
Windows
$oalogspath="C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log"; if (Test-Path $oalogspath) { Select-String "format check failed" $oalogspath | %{$_ -replace '.*format check failed: (.*)/(.*)', '$1\$2'} | %{rm -ErrorAction SilentlyContinue -Path ('C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\' + $_)} };
Opção 4: se houver muitos buffers corrompidos e você quiser reprocessar todos os arquivos de registro, use os comandos da Opção 3 e exclua os arquivos de posição (que armazenam operações o progresso do agente por arquivo de registros). Excluir os arquivos de posição pode resultar na duplicação de registro para qualquer registro que já tenha sido ingerido. Esta opção só reprocessa os arquivos de registro atuais. Ele não reprocessa arquivos que já foram substituídos ou registros de outras origens, como uma porta TCP. Os arquivos de posição são armazenados no diretório
buffers
, mas como arquivos. Os buffers locais são armazenados como subdiretórios no diretóriobuffers
,Linux
grep "format check failed" /var/log/google-cloud-ops-agent/subagents/logging-module.log | sed 's|.*format check failed: |/var/lib/google-cloud-ops-agent/fluent-bit/buffers/|' | xargs sudo rm -f sudo find /var/lib/google-cloud-ops-agent/fluent-bit/buffers -maxdepth 1 -type f -delete
Windows
$oalogspath="C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log"; if (Test-Path $oalogspath) { Select-String "format check failed" $oalogspath | %{$_ -replace '.*format check failed: (.*)/(.*)', '$1\$2'} | %{rm -ErrorAction SilentlyContinue -Path ('C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\' + $_)} }; Get-ChildItem -Path "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\" -File -ErrorAction SilentlyContinue | %{$_.Delete()}
Problemas conhecidos em versões mais recentes do Agente de operações
As seções a seguir descrevem problemas conhecidos de versões recentes do agente de operações.
O namespace de métricas do Prometheus inclui o nome e o ID da instância a partir da versão 2.46.0 do Agente de operações
A partir da versão 2.46.0, o Agente de operações
inclui o nome da VM como parte do rótulo namespace
ao ingerir métricas no
formato de ingestão do Prometheus. Nas versões anteriores, as métricas do Prometheus
usavam apenas o ID da instância da VM como parte de namespace
. No entanto, a partir da versão 2.46.0, namespace
está definido como
INSTANCE_ID/INSTANCE_NAME
.
Se você tiver gráficos, painéis ou políticas de alertas que usam o rótulo namespace
,
talvez seja necessário atualizar suas consultas após o upgrade do Agente de operações para
a versão 2.46.0 ou mais recente. Por exemplo, se sua consulta do PromQL
tiver esta aparência: http_requests_total{namespace="123456789"}
, será necessário
mudá-la para http_requests_total{namespace=~"123456789.*"}
, já que o
rótulo namespace
tem o formato INSTANCE_ID/INSTANCE_NAME
.
O tipo de métrica de mudança de métricas sem tipo do Prometheus começa com a versão 2.39.0 do Agente de operações
A partir da versão 2.39.0, o Agente de operações oferece suporte à ingestão de métricas do Prometheus com tipos desconhecidos. Nas versões anteriores, essas métricas são tratadas pelo Agente de operações como medidores, mas a partir da versão 2.39.0, as métricas sem tipo são tratadas como medidores e contadores. Como resultado, os usuários podem usar operações cumulativas nessas métricas.
Se você tiver gráficos, painéis ou políticas de alertas que usam o MQL para
consultar métricas sem tipo do Prometheus, atualize suas consultas MQL
depois de fazer upgrade do Agente de operações para a versão
2.39.0 ou mais recente. Em vez de consultar
métricas sem tipo como prometheus.googleapis.com/
, mude os
tipos de métrica da seguinte maneira:metric_name
/gauge
- Use
prometheus.googleapis.com/
para a versão do medidor da métrica.metric_name
/unknown - Use
prometheus.googleapis.com/
para a versão de contador da métrica.metric_name
/unknown:counter
Não é necessário fazer alterações nos gráficos, painéis ou políticas de alertas que usam o PromQL para consultar métricas sem tipo do Prometheus, mas é possível aplicar operações cumulativas a essas métricas depois de fazer upgrade do Agente de operações para a versão 2.39.0 ou posterior.
Uso elevado da memória em VMs do Windows (versões 2.27.0 a 2.29.0)
No Windows nas versões 2.27.0 a 2.29.0 do agente de operações, um bug que às vezes
vazava os soquetes levava ao aumento do uso de memória e a um grande número de
identificadores retidos pelo processo fluent-bit.exe
.
Para atenuar esse problema, faça upgrade do agente de operações para a versão 2.30.0 ou mais recente e reinicie o agente.
Os fusos horários do log de eventos estão errados no Windows (versões 2.15.0 a 2.26.0)
Os carimbos de data/hora associados aos logs de eventos do Windows no Cloud Logging podem estar incorretos se você alterar o fuso horário da sua VM de UTC. Isso foi corrigido no Agente de operações 2.27.0, mas devido ao problema conhecido de memória alta do Windows, recomendamos que você faça upgrade para pelo menos o Agente de operações 2.30.0 se estiver executando para esse problema. Se não for possível fazer upgrade, tente uma das seguintes soluções alternativas.
Usar um fuso horário UTC
No PowerShell, execute os comandos a seguir como administrador:
Set-TimeZone -Id "UTC"
Restart-Service -Name "google-cloud-ops-agent-fluent-bit" -Force
Substituir a configuração de fuso horário apenas para o serviço do subagente da geração de registros
No PowerShell, execute os comandos a seguir como administrador:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\google-cloud-ops-agent-fluent-bit" -Name "Environment" -Type "MultiString" -Value "TZ=UTC0"
Restart-Service -Name "google-cloud-ops-agent-fluent-bit" -Force
Os carimbos de data/hora analisados no Windows têm fuso horário incorreto (qualquer versão anterior à 2.27.0)
Se você usar um processador de registros que analise um carimbo de data/hora, o valor do fuso horário não será analisado corretamente no Windows. Isso foi corrigido no Agente de operações 2.27.0, mas devido ao problema conhecido de alta memória do Windows, recomendamos que você faça upgrade para pelo menos o Agente de operações 2.30.0 se estiver executando nesse problema.
Problemas conhecidos em versões mais antigas do Agente de operações
As seções abaixo descrevem problemas que ocorrem com as versões mais antigas do agente de operações.
Registros não nocivos (versões 2.9.1 e mais antigas)
É possível ver erros ao extrair métricas de pseudoprocessos ou processos restritos. Os registros a seguir não são nocivos e podem ser ignorados com segurança. Para eliminar essas mensagens, faça upgrade do agente de operações para a versão 2.10.0 ou mais recente.
Jul 13 17:28:55 debian9-trouble otelopscol[2134]: 2021-07-13T17:28:55.848Z error scraperhelper/scrapercontroller.go:205 Error scraping metrics {"kind" : "receiver", "name": "hostmetrics/hostmetrics", "error": "[error reading process name for pid 2: readlink /proc/2/exe: no such file or directory; error reading process name for pid 3: readlink /proc/3/exe: no such file or directory; error reading process name for pid 4: readlink /proc/4/exe: no such file or directory; error reading process name for pid 5: readlink /proc/5/exe: no such file or directory; error reading process name for pid 6: readlink /proc/6/exe: no such file or directory; error reading process name for pid 7: r eadlink /proc/7/exe: no such file or directory; error reading process name for pid 8: readlink /proc/8/exe: no such file or directory; error reading process name for pid 9: readl ink /proc/9/exe: no such file or directory; error reading process name for pid 10: readlink /proc/10/exe: no such file or directory; error reading process name for pid 11: readli nk /proc/11/exe: no such file or directory; error reading process name for pid 12: readlink /proc/12/exe: no such file or directory; error reading process name for pid 13: readli nk /proc/13/exe: no such file or directory; error reading process name for pid 14: readlink /proc/14/exe: no such file or directory; error reading process name for pid 15: readli nk /proc/15/exe: no such file or directory; error reading process name for pid 16: readlink /proc/16/exe: no such file or directory; error reading process name for pid 17: readli nk /proc/17/exe: no such file or directory; error reading process name for pid 18: readlink /proc/18/exe: no such file or directory; error reading process name for pid 19: readli nk /proc/19/exe: no such file or directory; error reading process name for pid 20: readlink /proc/20/exe: no such file or directory; error reading process name for pid 21: readli nk /proc/21/exe: no such file or directory; error reading process name for pid 22: readlink /proc/22/exe: no such file or directory; error reading process name for pid Jul 13 17:28:55 debian9-trouble otelopscol[2134]: 23: readlink /proc/23/exe: no such file or directory; error reading process name for pid 24: readlink /proc/24/exe: no such file or directory; error reading process name for pid 25: readlink /proc/25/exe: no such file or directory; error reading process name for pid 26: readlink /proc/26/exe: no such file or directory; error reading process name for pid 27: readlink /proc/27/exe: no such file or directory; error reading process name for pid 28: readlink /proc/28/exe: no such file or directory; error reading process name for pid 30: readlink /proc/30/exe: no such file or directory; error reading process name for pid 31: readlink /proc/31/exe: no such file or directory; error reading process name for pid 43: readlink /proc/43/exe: no such file or directory; error reading process name for pid 44: readlink /proc/44/exe: no such file or directory; error reading process name for pid 45: readlink /proc/45/exe: no such file or directory; error reading process name for pid 90: readlink /proc/90/exe: no such file or directory; error reading process name for pid 92: readlink /proc/92/exe: no such file or directory; error reading process name for pid 106: readlink /proc/106/exe: no such fi le or directory; error reading process name for pid 360: readlink /proc/360/exe: no such file or directory; error reading process name for pid 375: readlink /proc/375/exe: no suc h file or directory; error reading process name for pid 384: readlink /proc/384/exe: no such file or directory; error reading process name for pid 386: readlink /proc/386/exe: no such file or directory; error reading process name for pid 387: readlink /proc/387/exe: no such file or directory; error reading process name for pid 422: readlink /proc/422/exe : no such file or directory; error reading process name for pid 491: readlink /proc/491/exe: no such file or directory; error reading process name for pid 500: readlink /proc/500 /exe: no such file or directory; error reading process name for pid 2121: readlink /proc/2121/exe: no such file or directory; error reading Jul 13 17:28:55 debian9-trouble otelopscol[2134]: process name for pid 2127: readlink /proc/2127/exe: no such file or directory]"} Jul 13 17:28:55 debian9-trouble otelopscol[2134]: go.opentelemetry.io/collector/receiver/scraperhelper.(controller).scrapeMetricsAndReport Jul 13 17:28:55 debian9-trouble otelopscol[2134]: /root/go/pkg/mod/go.opentelemetry.io/collector@v0.29.0/receiver/scraperhelper/scrapercontroller.go:205 Jul 13 17:28:55 debian9-trouble otelopscol[2134]: go.opentelemetry.io/collector/receiver/scraperhelper.(controller).startScraping.func1 Jul 13 17:28:55 debian9-trouble otelopscol[2134]: /root/go/pkg/mod/go.opentelemetry.io/collector@v0.29.0/receiver/scraperhelper/scrapercontroller.go:186
Os registros próprios do agente consomem muita CPU, memória e espaço em disco (versão 2.16.0 e mais antigas)
As versões do agente de operações anteriores à 2.17.0 podem consumir muito espaço de CPU, memória
e disco
com arquivos /var/log/google-cloud-ops-agent/subagents/logging-module.log
em
VMs Linux ou C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log
em VMs do Windows devido a blocos de buffer corrompidos. Quando isso acontecer, você verá
um grande número de mensagens como esta no arquivo logging-module.log
.
[2022/04/30 05:23:38] [error] [input chunk] error writing data from tail.2 instance [2022/04/30 05:23:38] [error] [storage] format check failed: tail.2/2004860-1650614856.691268293.flb [2022/04/30 05:23:38] [error] [storage] format check failed: tail.2/2004860-1650614856.691268293.flb [2022/04/30 05:23:38] [error] [storage] [cio file] file is not mmap()ed: tail.2:2004860-1650614856.691268293.flb
Para resolver esse problema, faça upgrade do agente de operações para a versão 2.17.0 ou mais recente e redefina totalmente o estado do agente.
Se o sistema ainda gerar um grande volume de registros próprios do agente, considere usar a rotação de registros. Para mais informações, consulte Configurar a rotação de registros.