Resolver problemas com o agente do Logging

Nesta página, você verá instruções para solucionar problemas comuns encontrados durante a instalação ou a interação com o agente do Logging.

Lista de verificação

Se você estiver com problemas para instalar ou usar o agente do Logging, veja alguns itens a serem verificados:

  • Se os comandos de instalação do Linux resultarem em erros, certifique-se de prefixar os comandos de instalação com sudo.

  • Confira se o serviço do agente está em execução na instância da VM:

    • Para VMs do Windows, use o seguinte comando do PowerShell:

      Get-Service -Name StackdriverLogging

      Procure um serviço chamado Stackdriver Logging. Se o agente não estiver em execução, talvez seja necessário reiniciá-lo.

    • Para VMs do Linux, use o seguinte comando:

      sudo service google-fluentd status

      Se o agente não estiver em execução, talvez seja necessário reiniciá-lo com o seguinte comando:

      sudo service google-fluentd restart

      Se a reinicialização falhar e a saída do registro mostrar "Desativada por metadados", é provável que você esteja executando uma imagem do Google Cloud Marketplace, em que o agente do Logging está desativado por padrão. A chave de metadados da instância google-logging-enable controla o status de ativação do agente do Logging, em que o valor 0 desativa o agente. Para reativar o agente, remova a chave google-logging-enable ou defina o valor dela como 1. Para mais informações, consulte Criar uma instância com o agente do Logging desativado.

      Se o agente não estiver desativado por meio dos metadados, reinstale-o. Para isso, consulte esta seção.

  • Verifique se o agente tem mensagens de erro gravadas nos registros.

    • No Windows, a partir da versão v1-9, o agente do Logging salva os registros em C:\Program Files (x86)\Stackdriver\LoggingAgent\fluentd.log.

      Não há como conseguir os registros das versões anteriores do agente.

    • No Linux, o agente do Logging é um pacote fluentd e registra mensagens para /var/log/google-fluentd/google-fluentd.log:

  • Se a execução do agente está normal aparentemente, mas você não está recebendo dados, verifique se ele está enviando dados para o projeto correto. Consulte a seção a seguir, Como verificar as credenciais do Compute Engine.

  • Se o agente não autorizar, verifique se as credenciais da sua chave privada são ausentes ou inválidas.

Verificar a instalação do agente

Para verificar se a instalação foi bem-sucedida, procure a entrada de registro de teste do agente no Explorador de registros.

  1. No console do Google Cloud, acesse a página do Explorador de registros.

    Acessar a Análise de registros

    Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Monitoring.

  2. Na parte superior da página, escolha o projeto que contém sua instância de VM:

    • Para instâncias de VM do Compute Engine, escolha o projeto do Google Cloud que contém a instância de VM.
    • Para instâncias de VM do Amazon EC2, escolha o projeto de conector da AWS que vincula sua conta da AWS aos serviços do Google Cloud.

  3. Nas guias das janelas, escolha o recurso da instância da VM:

    • Para Compute Engine, escolha Instância da VM do GCE.
    • No Amazon EC2, escolha Instância do AWS EC2.
    • Selecione syslog (Linux), fluent.info (Windows) ou Todos os registros.

Se você vir uma entrada de registro, "gRPC enviado com sucesso para a API do Logging", a instalação do agente foi concluída. Essa mensagem é gerada quando o agente é instalado e também quando cada agente é reiniciado.

Consulte Como usar o Explorador de registros para mais informações.

Testar o agente

Se você suspeitar que o agente não está funcionando, verifique se ele está em execução e tente enviar uma mensagem de teste para o Logging:

Instância do Linux

O procedimento a seguir funciona em instâncias de VM do Compute Engine e do Amazon EC2 que executam o Linux:

  1. Verifique se o agente do Logging está executando os seguintes comandos na instância de VM:

    ps ax | grep fluentd

    O resultado será semelhante a:

     2284 ?        Sl     0:00 /opt/google-fluentd/embedded/bin/ruby /usr/sbin/google-fluentd [...]
 2287 ?        Sl    42:44 /opt/google-fluentd/embedded/bin/ruby /usr/sbin/google-fluentd [...]

  2. Envie uma mensagem de registro de teste executando o seguinte comando na instância de VM:

    logger "Some test message"

Instância do Windows

O agente do Logging tem dois nomes de serviço do Windows:

  • StackdriverLogging para as versões v1-5 e posteriores
  • fluentdwinsvc para versões anteriores

Você precisa ter um serviço de agente em execução. Execute os seguintes comandos na instância de VM usando o PowerShell:

  1. Solicite o status dos dois serviços. Se você souber qual serviço precisa estar em execução, use apenas o nome desse serviço:

    Get-Service StackdriverLogging,fluentdwinsvc

  2. Se não houver um serviço em execução, você receberá uma mensagem de erro. Caso contrário, você verá um resultado como este:

    Status    Name                DisplayName
------    ----                -----------
Running  StackdriverLogging   Cloud Logging

  3. Se você consultar os dois serviços, verá uma mensagem de erro e um status Running:

    • Se você não vir nenhum status Running, então o agente do Logging não está em execução.
    • Se StackdriverLogging estiver funcionando, então você está executando uma versão recente do agente. Para determinar a versão específica, consulte Como conseguir a versão.
    • Se você vir que fluentdwinsvc está em execução, faça o upgrade do seu agente para a versão mais recente.

  4. Requer privilégios de administrador: caso haja alguma versão de agente em execução, envie uma mensagem de registro de teste executando os seguintes comandos do PowerShell:

    New-EventLog   -LogName Application -Source "Test Source"
Write-EventLog -LogName Application -Source "Test Source" -EntryType Information -EventID 1 -Message "Testing 123 Testing."

Encontrar sua mensagem de teste

Depois de enviar uma mensagem de teste, procure-a no Explorador de registros:

  1. No console do Google Cloud, acesse a página do Explorador de registros.

    Acessar a Análise de registros

    Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Monitoring.

  2. Na parte superior da página, escolha o projeto que contém sua instância de VM:

    • Para instâncias de VM do Compute Engine, escolha o projeto do Google Cloud que contém a instância de VM.
    • Para instâncias de VM do Amazon EC2, escolha o projeto de conector da AWS que vincula sua conta da AWS aos serviços do Google Cloud.

  3. Nas guias das janelas, escolha o recurso da instância da VM:

    • Para Compute Engine, escolha Instância da VM do GCE.
    • No Amazon EC2, escolha Instância do AWS EC2.
    • Selecione syslog (Linux), fluent.info (Windows) ou Todos os registros.

  4. Você precisa ver uma entrada de registro com a mensagem de teste. Em caso afirmativo, o agente do Logging está funcionando corretamente.

Verificar as credenciais do Compute Engine

Para uma instância de VM do Compute Engine executar o agente sem credenciais de chave privada, a instância precisa ter os escopos de acesso adequados e uma identidade da conta de serviço com as permissões adequadas do IAM.

Quando você cria uma instância de VM, as configurações de escopo padrão e de conta de serviço são suficientes para executar os agentes. As instâncias mais anteriores, ou as instâncias para que você alterou as configurações padrão, podem não ter credenciais adequadas.

Falha ao carregar as credenciais padrão

Se houver falhas Could not load the default credentials no arquivo de registros do Logging, isso implicará a falha de conexão do agente com o servidor de metadados do Compute Engine.

O registro de erros vai aparecer desta forma:

Starting google-fluentd 1.8.4: /opt/google-fluentd/embedded/lib/ruby/gems/2.6.0/gems/googleauth-0.9.0/lib/googleauth/application_default.rb:74:in `get_application_default': Could not load the default credentials. Browse to (RuntimeError) https://developers.google.com/accounts/docs/application-default-credentials for more information.

Uma possível causa para isso é se a VM tiver uma configuração de proxy personalizada. Para corrigir isso, consulte a instrução de configuração do proxy para excluir o servidor de metadados do Compute Engine (metadata.google.internal ou 169.254.169.254) do proxy. Se o erro persistir, remova a conta de serviço padrão do Compute Engine da VM e adicione-a novamente.

Verificar os escopos de acesso

Para verificar os escopos de acesso, faça o seguinte:

  1. No Console do Google Cloud, acesse a página Instâncias de VM.

    Acessar Instâncias de VM

    Se você usar a barra de pesquisa para encontrar a página, selecione o resultado com o subtítulo Compute Engine.

  2. Clique no nome da instância de VM. A página "Detalhes" da instância é exibida.

  3. Na seção Escopos de acesso da API Cloud, clique em Detalhes para ver a lista de APIs. Procure as entradas a seguir:

    1. Se você vir "Esta instância tem acesso total à API a todos os serviços do Google Cloud", os escopos de acesso serão adequados.
    2. Se, ao lado de API Stackdriver Logging, um nome antigo para a API Cloud Logging, você vir que tem a permissão Somente gravação ou Completa, os escopos de acesso da instância são adequados para o agente do Cloud Logging.
    3. Se, ao lado de API Stackdriver Logging, um nome antigo para a API Cloud Monitoring, você vir que tem a permissão Somente gravação ou Completa, os escopos de acesso da instância são adequados para o agente do Cloud Monitoring.

Corrigir o problema

Se você não tiver escopos de acesso adequados na instância do Compute Engine, adicione os escopos de acesso necessários à instância.

A tabela a seguir mostra os escopos relevantes para os agentes do Logging e do Monitoring:

Escopo de acesso Permissões do agente
https://www.googleapis.com/auth/logging.write Adequado para o agente do Logging
https://www.googleapis.com/auth/monitoring.write Adequado para o agente do Monitoring

Verificar a permissão padrão da conta de serviço

Mesmo que os escopos de acesso da instância da VM do Compute Engine sejam adequados, a conta de serviço padrão da instância talvez não forneça as permissões certas do IAM para o agente.

Para verificar a permissão da conta de serviço padrão, comece localizando a conta de serviço padrão:

  1. No Console do Google Cloud, acesse a página Instâncias de VM.

    Acessar Instâncias de VM

    Se você usar a barra de pesquisa para encontrar a página, selecione o resultado com o subtítulo Compute Engine.

  2. Clique no nome da instância de VM. A página "Detalhes" da instância é exibida.

  3. Procure o título da conta de serviço na página. A conta de serviço padrão da instância é listada. Pode parecer com esta:

    [ID]-compute@developer.gserviceaccount.com

  4. No console do Google Cloud, abra a página IAM.

    Acesse o IAM

    Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo IAM e administrador.

  5. Selecione Visualizar por: principais. Você precisa ver uma lista de pessoas, grupos e contas de serviço. Na coluna Papel estão os papéis que cada principal tem no projeto.

  6. Na linha da conta de serviço padrão da instância, você precisa ver um ou mais papéis:

Corrigir o problema

Se a conta de serviço padrão não tiver papéis adequados, tente editar os papéis da conta de serviço na página IAM e administrador > IAM. Adicione os papéis do Logging ou do Monitoring adequados para autorizar os agentes: Logging > Gravador de registros ou Monitoring > Gravador de métricas do Monitoring.

Verificar credenciais de chave privada

Em instâncias de VM do Compute Engine, configure o agente para usar uma conta de serviço não padrão sem a autorização apropriada. Em instâncias de VM do AWS EC2, você precisa configurar o agente para usar uma conta de serviço assim.

Para configurar o agente dessa maneira, você precisa criar credenciais de chave particular para a conta de serviço designada e fornecer essas credenciais ao agente.

  1. O agente procura uma variável de ambiente, GOOGLE_APPLICATION_CREDENTIALS, que mantém o nome de um arquivo que contém as credenciais de chave particular.

  2. Se a variável de ambiente não estiver presente, o agente procurará credenciais em um local padrão:

    Linux

    /etc/google/auth/application_default_credentials.json

    Windows

    C:\ProgramData\Google\Auth\application_default_credentials.json

  3. Se o local padrão não contiver as credenciais, o agente usará as credenciais padrão do aplicativo do servidor de metadados.

As seguintes informações ajudam a fazer o diagnóstico de problemas de credenciais de chave particular:

  1. A chave particular está implementada?
  2. A chave particular continua sendo válida para a conta de serviço?
  3. A conta de serviço tem os papéis necessários para o agente?

Para verificar se as credenciais de chave privada válidas estão instaladas na instância de VM, confirme primeiro se o arquivo de credenciais está na localização esperada e se as informações nele são válidas.

As credenciais estão presentes?

Para ver se as credenciais da conta de serviço de chave privada estão na instância, execute os seguintes comandos do Linux na instância:

sudo cat $GOOGLE_APPLICATION_CREDENTIALS
sudo cat /etc/google/auth/application_default_credentials.json

Se um dos comandos exibir um arquivo conforme mostrado a seguir, pode ser que a instância tenha credenciais de chave privada válidas. Se ambos os comandos exibirem um arquivo, será usado o arquivo indicado por GOOGLE_APPLICATION_CREDENTIALS.

{
  "type": "service_account",
  "project_id": "[YOUR-PROJECT-ID]",
  "private_key_id": "[YOUR-PRIVATE-KEY-ID]",
  "private_key": "[YOUR-PRIVATE-KEY]",
  "client_email": "[YOUR-PROJECT-NUMBER]-[YOUR-KEY@DEVELOPER].gserviceaccount.com",
  "client_id": "[YOUR-CLIENT-ID]",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://accounts.google.com/o/oauth2/token",
  "auth_provider_x509_cert_url": "{x509-cert-url}",
  "client_x509_cert_url": "{client-x509-cert-url}"
}

Discrepâncias entre configurações de credenciais podem fazer com que o agente use credenciais diferentes das exigidas pelo serviço. Por exemplo, se você definir um local de credencial personalizado em GOOGLE_APPLICATION_CREDENTIALS no shell de login, mas não definir essa variável na configuração de serviço do agente, o serviço procurará no local padrão em vez do seu local personalizado.

Para revisar ou alterar a variável de ambiente de credenciais, acesse ou defina GOOGLE_APPLICATION_CREDENTIALS em /etc/default/google-fluentd.

Se não houver arquivos de credenciais presentes, consulte Como adicionar credenciais.

As credenciais são válidas?

No arquivo de credenciais, project_id é o projeto do Google Cloud, project_id identifica a conta de serviço no projeto e project_id identifica a chave privada na conta de serviço. Combine essas informações com o que é exibido na seção IAM e Administrador > Contas de serviço do Console do Google Cloud.

O arquivo de credenciais não será válido se qualquer uma das afirmações a seguir for verdadeira:

  • Você está verificando uma instância do Compute Engine, mas o projeto do Google Cloud no arquivo de credenciais não é o que contém a instância.
  • Você está verificando uma instância do Amazon EC2, mas o projeto do Google Cloud no arquivo de credenciais não é o projeto do conector, chamado AWS Link..., para sua conta da AWS.
  • A conta de serviço listada não existe. Ela pode ter sido excluída.
  • A conta de serviço listada não tem os papéis certos ativados: Gravador de registros para o agente do Cloud Logging e o Gravador de métricas do Monitoring para o agente do Cloud Monitoring.
  • A chave privada não existe. Ela pode ter sido revogada.

As credenciais podem ser revogadas por meio da seção IAM e Administrador > Contas de serviço do console do Google Cloud. Se não houver credenciais válidas, consulte Como adicionar credenciais para substituir as atuais ou adicionar novas.

Se a conta de serviço for a correta, mas a chave particular tiver sido revogada, você poderá criar uma nova chave particular e copiá-la para a instância. Consulte Como criar chaves da conta de serviço.

Do contrário, você precisará criar uma nova conta de serviço, conforme descrito na seção Como adicionar credenciais.

Verificar consultas da exclusão de registro

Visualize suas consultas de exclusão atuais para garantir que os registros que você está procurando não sejam excluídos acidentalmente.

Verificar firewall

Para ver se a instância tem acesso a logging.googleapis.com, execute o seguinte comando do Linux na sua instância:

curl -sSL 'https://logging.googleapis.com/$discovery/rest?version=v2' | head

O comando pode levar algum tempo para ser concluído quando o firewall bloqueia o tráfego de saída. Exemplo de saída que indica um problema no firewall:

curl: (7) Failed to connect to 2607:f8b0:4001:c03::5f: Network is unreachable

Acesse Regras de firewall para informações sobre como configurar regras para tráfego de saída.

Reinstalar o agente

A instalação da versão mais recente do agente soluciona muitos problemas:

Outros problemas comuns

A tabela a seguir lista alguns problemas comuns que é possível encontrar com o agente do Cloud Logging e informa como corrigi-los.

No Linux, o agente do Logging registra erros em /var/log/google-fluentd/google-fluentd.log. No Windows, o agente do Logging registra erros em C:\Program Files (x86)\Stackdriver\LoggingAgent\fluentd.log, a partir da versão v1-9. A classe de erro Google::APIClient::ClientError indica que há um problema com as permissões ou com o acesso à API.

É possível que ocorram erros depois que o agente tiver sido executado com êxito. Por exemplo, alguém pode revogar as permissões necessárias do projeto ou da instância de VM.

Erro Causa Solução
Falha na execução do instalador do agente no Windows O download do instalador pode ter sido feito para um diretório do sistema. Mova o instalador para um diretório que não seja do sistema, como C:\Users\[USERID]\.
O projeto não ativou a API Você não ativou a API Cloud Logging no seu projeto. Acesse o console de APIs e altere o status da API Cloud Logging para ON.
A solicitação tinha credenciais inválidas
ou
Não foi possível buscar o token de acesso. Nenhum escopo foi configurado?		 A instância de VM não tem credenciais adequadas. Se você estiver usando o Amazon EC2, instale credenciais nas instâncias de VM antes de instalar o agente. Consulte Autorizar o agente do Logging para instalar credenciais.
Falha na autorização As credenciais de autorização de chave privada para o agente do Logging não estão configuradas corretamente. Consulte Como verificar credenciais de chave privada.
O autor da chamada não tem permissão A conta de serviço usada para autorização no projeto não tem permissões suficientes. Pode ser a conta de serviço padrão usada no Compute Engine ou no App Engine ou pode ser uma conta de serviço definida pelo usuário usada para autorização de chave privada. A conta precisa ter o papel de Editor. Altere a permissão da conta de serviço na página IAM do seu projeto. Se necessário, é possível modificar o escopo de acesso para uma VM atual usando os procedimentos contidos em Como alterar a conta de serviço e os escopos de acesso de uma instância.
Não é possível conseguir o código do projeto O agente do Cloud Logging deixou de receber o ID do projeto enviado pelo arquivo de credenciais de chave privada de uma conta de serviço. Para adicionar ou modificar um ID do projeto para o agente, edite o arquivo de configuração do agente, /etc/google-fluentd/google-fluentd.conf, na instância da VM. Na seção <match **>, adicione a seguinte linha:
project_id [YOUR_PROJECT_ID]
Caso contrário, consulte Autorizar o agente do Logging para corrigir ou substituir as credenciais.
O agente do Logging do Windows interrompe a ingestão de registros de eventos em alguns canais O agente do Logging pode falhar ao ingerir registros de eventos de determinados canais, mesmo que ainda esteja em execução e ingerindo registros de agente e de eventos de outros canais. O motivo é que o plug-in windows_eventlog tem alguns problemas, conforme mencionado nesta apresentação. Usar windows_eventlog2 resolve esse problema. Observação: o formato de dados do plug-in windows_eventlog2 não é compatível com versões anteriores do plug-in windows_eventlog. Se houver pipelines de exportação do BigQuery ou do Google Cloud Storage configurados para esses registros, será necessário ajustá-los adequadamente. Veja esta comparação de entradas de registro fornecida por windows_eventlog e windows_eventlog2. Para usar windows_eventlog2, primeiro você precisa interromper o agente do Logging e, em seguida, substituir o arquivo de configuração por um semelhante a este arquivo de configuração de amostra. Por fim, inicie o agente do Logging.
O agente do Logging interrompe a ingestão de registros na presença de logrotate O agente do Logging pode perder o controle de onde está nos arquivos de entrada quando logrotate está configurado com a configuração copytruncate. É melhor usar a configuração nocopytruncate para garantir que o logrotate mova os arquivos em vez de truncá-los. Se você quiser manter a configuração copytruncate, a solução alternativa é reiniciar o agente periodicamente. Também é possível usar a configuração postrotate para reiniciar o agente.
error_class=Errno::EADDRINUSE error="O endereço já está sendo usado - vincular(2) para 0.0.0.0:24231" Há várias instâncias do agente do Logging em execução na VM. Usando ps -aux | grep "/usr/sbin/google-fluentd" para mostrar os processos do agente em execução (deve haver apenas dois: um supervisor e um worker) e sudo netstat -nltp | grep :24231 para mostrar os processos em execução que ocupam a porta. Elimine instâncias mais antigas se for apropriado.
Falha do agente do Logging ao iniciar devido a erros de lib/fluent/config/types.rb A configuração do agente do Logging usa uma seção do analisador de regex em que o regex está incorreto, resultando em uma chamada de subex inválida e erros como Starting google-fluentd 1.8.6: /opt/google-fluentd/embedded/lib/ruby/gems/2.6.0/gems/fluentd-1.11.2/lib/fluent/config/types.rb:92: warning: invalid subexp call. Localize e corrija o regex incorreto no arquivo de configuração do agente. Dica: pesquise por regex ou parse.

Limitação na capacidade de processamento de registros

A capacidade máxima de processamento de registros que o agente do Logging pode processar é limitada pela CPU. O uso da CPU aumenta junta da capacidade de processamento de registros. Porém, na configuração padrão, o agente pode usar até um único núcleo de CPU. Portanto, quando a capacidade de processamento de registros aumenta, o agente pode atingir um limite de uso da CPU. Se esses picos forem temporários, o agente do Logging armazenará os registros e os processará mais tarde. Se a capacidade de processamento de registros permanecer alta, os registros poderão estourar o buffer e acabarem sendo perdidos.

Normalmente, quando cada entrada de registro é de 1.000 bytes de texto bruto e não tem mais processamento de formato, o agente do Logging atinge o limite principal de CPU em cerca de 5.500 entradas de registro por segundo. Se as entradas de registro exigirem processamento avançado, por exemplo, análise de JSON ou Regex, o número máximo de entradas de registro por segundo pode ser menor.

Se você precisar de mais capacidade de processamento de registros, use o agente de operações. No Linux, para entradas de registro de 1.000 bytes de texto bruto e que não envolvem processamento extra, o agente de operações pode processar cerca de 160.000 entradas de registro por segundo.

Tamanho máximo do registro excedido

Se uma ou mais entradas de registro excederem o limite máximo de tamanho, será possível encontrar entradas nos registros fluentd semelhantes aos seguintes:

Dropping 1 log message(s) error_class="Google::Apis::ClientError" error="Invalid request"


ou

Dropping 1 log message(s) error="3:Log entry with size 1000515 bytes exceeds maximum size of 112640 bytes" error_code="3"

Para resolver esse erro, corte as entradas de registro para que elas não excedam o limite máximo de tamanho. Por exemplo, o código de amostra a seguir corta registros com a tag mytag, com os dados no campo message:

# Cloud Logging only supports log entries that are up to 256 KiB in size.
# Trim the entries to just under that size to avoid dropping them.
<filter [MY_TAG]>
  @type record_transformer
  enable_ruby true
  <record>
    message ${record['message'].length > 256000 ? "[Trimmed]#{record['message'][0..256000]}..." : record['message']}
  </record>
</filter>

Os registros estão duplicados

LogEntry.insertID é adicionado ao pipeline de processamento no agente. Se insertID for diferente entre os registros duplicados, isso indicará que os registros são processados entre os arquivos de registro várias vezes. Isso pode ocorrer na presença de rotação de registros ou quando o arquivo pos está ausente ou corrompido. Para reduzir a chance desse problema, certifique-se de que os arquivos de posição de qualquer entrada in_tail não estejam configurados para estar na pasta /var/log ou quaisquer outras pastas que tenham a rotação de registro ativada.

O pipeline de geração de registros também depende do campo LogEntry.timestamp para desduplicar registros. Verifique se o carimbo de data/hora da entrada de registro está analisado corretamente. Se o Fluentd não estiver configurado para analisar o carimbo de data/hora original a partir da entrada de registro, ele usará o horário em que processou a entrada. Portanto, se a entrada for lida várias vezes, mesmo que o carimbo de data/hora na linha de registro seja o mesmo, o Fluentd poderá tratá-las como entradas de registro diferentes com carimbos de data/hora diferentes.

Erros repetidos de registro de auditoria: Data points cannot be written more than 24h in the past

Há um problema conhecido que afeta as versões de 1.8.5 a 1.9.3 (inclusive). Isso faz com que registros como os seguintes apareçam repetidamente em Registros de auditoria de acesso a dados, quando o agente estiver em execução há mais de 24 horas:

Field timeSeries[0].points[0].interval.end_time had an invalid value of "2021-10-20T20:16:34.010866-07:00": Data points cannot be written more than 24h in the past.

A solução é fazer upgrade do agente para a versão 1.9.4 ou posterior.

Os caracteres Unicode nos registros são substituídos por espaços ou '�'

Por padrão, a entrada in_tail espera que os arquivos de entrada sejam codificados em ASCII. Por isso, ela substitui qualquer caractere não ASCII por um espaço. Para processar realmente arquivos codificados em UTF-8, você precisa fornecer duas opções na configuração de in_tail:

<source>
  @type tail
  …

  encoding UTF-8
  from_encoding UTF-8
</source>

Ambas as opções são necessárias. Se apenas a opção encoding for fornecida, os caracteres não ASCII nos registros ingeridos serão substituídos por '�'.

Agente removido informado pelo console do Google Cloud como instalado

Depois de desinstalar o agente, o console do Google Cloud pode levar até uma hora para informar essa alteração.

O agente do Logging não aparece na lista "Desinstalar um programa" do Windows

Para desinstalar o agente do Logging quando ele não estiver na lista Desinstalar um programa do Painel de Controle do Windows, execute uninstall.exe no diretório em que você o instalou.