Esta página fornece instruções para resolver problemas comuns encontrados na instalação ou na interação com o agente Logging.
Lista de verificação
Se tiver problemas com a instalação ou a utilização do agente de registo, veja o que tem de verificar:
Se os comandos de instalação do Linux resultarem em erros, certifique-se de que prefixa os comandos de instalação com
sudo.Verifique se o serviço do agente está em execução na instância de VM:
Para uma VM do Windows, use o seguinte comando do PowerShell:
Get-Service -Name StackdriverLoggingPesquise um serviço denominado Stackdriver Logging. Se o agente não estiver em execução, pode ter de o reiniciar.
Para uma VM Linux, use o seguinte comando:
sudo service google-fluentd statusSe o agente não estiver em execução, pode ter de o reiniciar através do seguinte comando:
sudo service google-fluentd restartSe o reinício falhar e o resultado do registo mostrar "Desativado através de metadados", é provável que esteja a executar uma imagem do Google Cloud Marketplace, onde o agente de registo está desativado por predefinição. A chave de metadados da instância
google-logging-enablecontrola o estado de ativação do agente de registo, em que um valor de0desativa o agente. Para reativar o agente, remova a chavegoogle-logging-enableou defina o respetivo valor como1. Para mais informações, consulte o artigo Crie uma instância com o agente de registo desativado).Se o agente não estiver desativado através de metadados, reinstale-o. Consulte a secção seguinte, Reinstalar o agente do Logging.
Verifique se o agente escreveu mensagens de erro nos registos.
No Windows, a partir da versão v1-9, o agente de registo guarda os respetivos registos em
C:\Program Files (x86)\Stackdriver\LoggingAgent\fluentd.log.Não existe forma de obter os registos das versões anteriores do agente.
No Linux, o agente de registos é um pacote
fluentde regista mensagens em/var/log/google-fluentd/google-fluentd.log:Se vir erros HTTP 429, pode ter excedido as suas quotas da API Logging. Pode ver a sua quota disponível selecionando APIs e serviços > Painel de controlo na Google Cloud consola. Escolha a API Logging.
Se vir problemas de acesso ou autorização da API, aceda a Validar credenciais do Compute Engine.
Se o agente parecer estar a ser executado normalmente, mas não estiver a receber dados, deve verificar se o agente está a enviar dados para o projeto correto. Consulte a secção seguinte, Validar credenciais do Compute Engine.
Se o agente não conseguir autorizar, verifique se as credenciais da sua chave privada estão em falta ou são inválidas.
Valide a instalação do agente
Para verificar se a instalação foi bem-sucedida, procure a entrada do registo de teste do agente no Logs Explorer.
-
Na Google Cloud consola, aceda à página Explorador de registos:
Aceda ao Explorador de registos
Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cuja legenda é Registo.
Na parte superior da página, escolha o projeto que contém a instância de VM:
- Para instâncias de VM do Compute Engine, escolha o Google Cloud projeto que contém a instância de VM.
- Para instâncias de VM do Amazon EC2, escolha o Google Cloud projeto para o qual está a enviar registos.
Nos separadores do Windows, escolha o recurso para a sua instância de VM:
- Para o Compute Engine, escolha
Instância de VM do GCE. - Para Amazon EC2, escolha Instância do AWS EC2.
- Selecione syslog (Linux), fluent.info (Windows) ou Todos os registos.
- Para o Compute Engine, escolha
Se vir uma entrada no registo "Successfully sent gRPC to Logging API" (gRPC enviado com êxito para a API Logging), a instalação do agente está concluída. Esta mensagem é gerada uma vez quando o agente é instalado e também sempre que o agente é reiniciado.
Para mais informações sobre o Explorador de registos, consulte o artigo Usar o Explorador de registos.
Teste o agente
Se suspeitar que o agente não está a funcionar, verifique se está em execução e tente enviar uma mensagem de teste para o registo:
Instância do Linux
O procedimento seguinte funciona em instâncias do Compute Engine e da VM do Amazon EC2 que executam o Linux:
Verifique se o agente de registo está em execução executando os seguintes comandos na instância de VM:
ps ax | grep fluentdDeverá ver uma saída semelhante à seguinte:
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 [...]Envie uma mensagem de registo de teste executando o seguinte comando na instância da VM:
logger "Some test message"
Instância do Windows
O agente de registos tem dois nomes de serviços do Windows:
StackdriverLoggingpara as versões v1 a 5 e posterioresfluentdwinsvcpara versões anteriores
Deve estar a executar um serviço de agente. Execute os seguintes comandos na instância de VM com o PowerShell:
Pergunte sobre o estado de ambos os serviços. Se souber que serviço deve estar em execução, pode usar apenas o nome desse serviço:
Get-Service StackdriverLogging,fluentdwinsvcSe um serviço não estiver em execução, é apresentada uma mensagem de erro. Se estiver em execução, vê um resultado semelhante ao seguinte:
Status Name DisplayName ------ ---- ----------- Running StackdriverLogging Cloud LoggingSe consultar ambos os serviços, deve ver uma mensagem de erro e um estado
Running:- Se não vir nenhum estado
Running, significa que o agente de registo não está em execução. - Se vir que o ícone
StackdriverLoggingestá em execução, significa que está a usar uma versão recente do agente. Para determinar a versão específica, consulte Obter a versão. - Se vir que o
fluentdwinsvcestá em execução, deve atualizar o seu agente para a versão mais recente.
- Se não vir nenhum estado
Requer privilégios de administrador: se estiver a ser executada alguma versão do agente, envie uma mensagem de registo 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."
Encontre a sua mensagem de teste
Depois de enviar uma mensagem de teste, procure-a no Explorador de registos:
-
Na Google Cloud consola, aceda à página Explorador de registos:
Aceda ao Explorador de registos
Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cuja legenda é Registo.
Na parte superior da página, escolha o projeto que contém a instância de VM:
- Para instâncias de VM do Compute Engine, escolha o Google Cloud projeto que contém a instância de VM.
- Para instâncias de VM do Amazon EC2, escolha o Google Cloud projeto para o qual está a enviar registos.
Nos separadores do Windows, escolha o recurso para a sua instância de VM:
- Para o Compute Engine, escolha
Instância de VM do GCE. - Para Amazon EC2, escolha Instância do AWS EC2.
- Selecione syslog (Linux), fluent.info (Windows) ou Todos os registos.
- Para o Compute Engine, escolha
Deve ver uma entrada de registo com a sua mensagem de teste. Se for o caso, o agente de registo está a funcionar corretamente.
Valide as credenciais do Compute Engine
Para que uma instância de VM do Compute Engine execute o agente sem credenciais de chave privada, a instância tem de ter âmbitos de acesso adequados e a identidade da conta de serviço usada pela instância tem de ter autorizações do IAM adequadas.
Quando cria uma instância de VM, as definições predefinidas de âmbito e conta de serviço são suficientes para executar os agentes. As instâncias muito antigas ou as instâncias para as quais alterou as predefinições podem não ter credenciais adequadas.
Falha ao carregar as credenciais predefinidas
Caso existam falhas Could not load the default credentials no ficheiro de registo Logging, isto implica que o agente pode não conseguir estabelecer ligação ao servidor de metadados do Compute Engine.
O registo de erros tem o seguinte aspeto:
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 potencial causa para isto é se a VM tiver uma configuração de proxy personalizada. Para corrigir este problema,
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) de passar pelo proxy. Se o erro persistir, remova a conta de serviço do Compute Engine predefinida da VM e volte a adicioná-la.
Valide os âmbitos de acesso
Para validar os âmbitos de acesso, faça o seguinte:
-
Na Google Cloud consola, aceda à página Instâncias de VM:
Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cuja legenda seja Compute Engine.
Clique no nome da instância de VM. É apresentada a página de detalhes da sua instância.
Na secção Âmbitos de acesso da API Cloud, clique em Detalhes para ver a lista de APIs. Procure as seguintes entradas:
- Se vir "Esta instância tem acesso total à API para todos os serviços do Google Cloud", os seus âmbitos de acesso são adequados.
- Se vir junto a Stackdriver Logging API, um nome mais antigo para a Cloud Logging API, que tem a autorização Apenas escrita ou Completa, significa que os âmbitos de acesso da sua instância são adequados para o agente do Cloud Logging.
- Se vir junto a API Stackdriver Monitoring, um nome mais antigo para a API Cloud Monitoring, que tem a autorização Apenas escrita ou Completa, os âmbitos de acesso da sua instância são adequados para o agente do Cloud Monitoring.
Corrija o problema
Se não tiver âmbitos de acesso adequados na sua instância do Compute Engine, adicione os âmbitos de acesso necessários à sua instância.
A tabela seguinte mostra os âmbitos relevantes para os agentes de registo e monitorização:
| Âmbito de acesso | Autorizações de agentes |
|---|---|
| https://www.googleapis.com/auth/logging.write | Adequado para o agente de registos |
| https://www.googleapis.com/auth/monitoring.write | Adequado para o agente de monitorização |
Valide a autorização da conta de serviço predefinida
Mesmo que os âmbitos de acesso da instância de MV do Compute Engine sejam adequados, a conta de serviço predefinida da instância pode não fornecer as autorizações do IAM corretas para o agente.
Para validar a autorização da conta de serviço predefinida, comece por localizar a conta de serviço predefinida:
-
Na Google Cloud consola, aceda à página Instâncias de VM:
Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cuja legenda seja Compute Engine.
Clique no nome da instância de VM. É apresentada a página de detalhes da sua instância.
Procure o cabeçalho Conta de serviço na página. É apresentada a conta de serviço predefinida para a instância. Pode ter o seguinte aspeto:
[ID]-compute@developer.gserviceaccount.com-
Na Google Cloud consola, aceda à página IAM:
Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cujo subtítulo é IAM e administração.
Selecione Ver por: diretores. É apresentada uma lista de pessoas, grupos e contas de serviço. Na coluna Função, encontram-se as funções que cada principal tem no seu projeto.
Na linha da conta de serviço predefinida da sua instância, deve ver uma ou mais funções:
- Se vir Editor, essa função é adequada para todos os agentes. A função de editor pode ser concedida automaticamente à conta de serviço predefinida, consoante a configuração da política da organização.
- Se vir Escritor de registos, essa função é suficiente para o agente de registo. Para outras funções de registo que incluem a autorização de escrita, consulte o artigo Controlo de acesso para o Cloud Logging.
- Se vir Gravador de métricas de monitorização, essa função é suficiente para o agente de monitorização. Para outras funções de monitorização que incluem a autorização de escrita, consulte o artigo Controlo de acesso para o Cloud Monitoring.
Corrija o problema
Se a sua conta de serviço predefinida não tiver funções adequadas, experimente editar as funções da sua conta de serviço na página IAM e administrador > IAM. Adicione as funções de registo ou monitorização adequadas para autorizar os agentes: Registo > Escritor de registos ou Monitorização > Escritor de métricas de monitorização.
Valide as credenciais de chave privada
Nas instâncias de VM do Compute Engine, pode configurar o agente para usar uma conta de serviço não predefinida que tenha a autorização adequada. Nas instâncias de VM do AWS EC2, tem de configurar o agente para usar uma conta de serviço.
Para configurar o agente desta forma, tem de criar credenciais de chave privada para a conta de serviço designada e facultar essas credenciais ao agente.
- O agente procura uma variável de ambiente,
GOOGLE_APPLICATION_CREDENTIALS, que contém o nome de um ficheiro que contém as credenciais da chave privada. Se a variável do ambiente não estiver presente, o agente procura credenciais numa localização predefinida:
Linux
/etc/google/auth/application_default_credentials.jsonWindows
C:\ProgramData\Google\Auth\application_default_credentials.jsonSe a localização predefinida não contiver as credenciais, o agente usa as credenciais predefinidas da aplicação do servidor de metadados.
As seguintes informações ajudam a diagnosticar problemas de credenciais de chave privada:
- A chave privada está no lugar?
- A chave privada ainda é válida para a conta de serviço?
- A conta de serviço tem as funções necessárias para o agente?
Para verificar se as credenciais de chave privada válidas estão instaladas na instância de VM, verifique primeiro se o ficheiro de credenciais existe na localização esperada e, em seguida, verifique se as informações no ficheiro de credenciais 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 sua instância, execute os seguintes comandos do Linux na sua instância:
sudo cat $GOOGLE_APPLICATION_CREDENTIALS
sudo cat /etc/google/auth/application_default_credentials.json
Se qualquer um dos comandos apresentar um ficheiro como o apresentado abaixo, a sua instância pode ter credenciais de chave privada válidas. Se ambos os comandos apresentarem um ficheiro, é usado o ficheiro 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}"
}
As discrepâncias entre as configurações das credenciais podem fazer com que o agente use credenciais diferentes das que o seu serviço requer. Por exemplo, se definir uma localização de credenciais personalizada em GOOGLE_APPLICATION_CREDENTIALS no shell de início de sessão, mas não definir essa variável na configuração do serviço do agente, o serviço procura na localização predefinida em vez da sua localização personalizada.
Para rever ou alterar a variável de ambiente das credenciais,
aceda a GOOGLE_APPLICATION_CREDENTIALS ou defina-a em /etc/default/google-fluentd.
Se não existirem ficheiros de credenciais, consulte a secção Adicionar credenciais.
As credenciais são válidas?
No ficheiro de credenciais, project_id é o seu Google Cloud projeto, client_email identifica a conta de serviço no projeto e private_key_id identifica a chave privada na conta de serviço. Faça corresponder estas informações ao que é apresentado na secção IAM e administrador > Contas de serviço daGoogle Cloud consola.
O ficheiro de credenciais não é válido se alguma das seguintes afirmações for verdadeira:
- Está a verificar uma instância do Compute Engine, mas o Google Cloud projeto no ficheiro de credenciais não é o projeto que contém a sua instância.
- Está a verificar uma instância do Amazon EC2, mas o Google Cloud projeto no ficheiro de credenciais não é o Google Cloud projeto para o qual está a enviar registos.
- A conta de serviço apresentada não existe. Pode ter sido eliminada.
- A conta de serviço indicada não tem as funções corretas ativadas: Logs Writer para o agente do Cloud Logging e Monitoring Metric Writer para o agente do Cloud Monitoring.
- A chave privada não existe. Pode ter sido revogada.
As credenciais podem ser revogadas através da secção IAM e administrador > Contas de serviço da Google Cloud consola. Se não existirem credenciais válidas, consulte o artigo Adicionar credenciais para substituir as credenciais existentes ou adicionar novas.
Se a conta de serviço for a correta, mas a chave privada tiver sido revogada, pode criar uma nova chave privada e copiá-la para a sua instância. Consulte o artigo Criar chaves de contas de serviço.
Caso contrário, tem de criar uma nova conta de serviço, conforme descrito na secção Adicionar credenciais.
Valide as consultas de exclusão de registos
Veja as consultas de exclusão atuais para garantir que os registos que procura não foram excluídos acidentalmente.
Valide a firewall
Para ver se a sua instância tem acesso ao logging.googleapis.com, execute o seguinte comando Linux na sua instância:
curl -sSL 'https://logging.googleapis.com/$discovery/rest?version=v2' | head
O comando pode demorar algum tempo a terminar quando a firewall bloqueia o tráfego de saída. Exemplo de saída que indica um problema de firewall:
curl: (7) Failed to connect to 2607:f8b0:4001:c03::5f: Network is unreachable
Visite Regras de firewall para ver informações sobre como configurar regras para tráfego de saída.
Reinstale o agente
A instalação da versão mais recente do agente pode resolver muitos problemas:
Se tiver a certeza de que o problema não está relacionado com as credenciais, pode avançar para Instalar no Linux e Windows.
Para uma instalação completa do agente e de quaisquer credenciais necessárias, consulte o artigo Instale o agente de registo.
Outros problemas comuns
A tabela seguinte apresenta alguns problemas comuns que pode encontrar com o agente do Cloud Logging e indica como os corrigir.
No Linux, o agente Logging regista erros em
/var/log/google-fluentd/google-fluentd.log. No Windows, o agente de registo
regista 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 existe um problema com as autorizações ou o acesso à API.
Pode começar a ver erros depois de o agente ter sido executado com êxito. Por exemplo, alguém pode ter revogado as autorizações necessárias do seu projeto ou instância de VM.
| Erro | Causa | Solução |
|---|---|---|
| Não é possível executar o instalador do agente no Windows | Pode ter transferido o instalador 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 | Não ativou a API Cloud Logging no seu projeto. | Aceda à API Console e altere o estado da Cloud Logging API para ATIVADO. |
| O pedido tinha credenciais inválidas
ou Não é possível obter o token de acesso (não existem âmbitos configurados?) |
A sua instância de VM não tem credenciais adequadas. Se estiver a usar o Amazon EC2, tem de instalar as credenciais nas instâncias de VM antes de instalar o agente. | Consulte o artigo Autorize o agente Logging a instalar credenciais. |
| Falha na autorização | As suas credenciais de autorização de chave privada para o agente de registo não estão configuradas corretamente. | Consulte o artigo Validar credenciais de chave privada. |
| O autor da chamada não tem autorização | A conta de serviço usada para autorização no seu projeto tem autorizações insuficientes. Pode ser a conta de serviço predefinida usada no Compute Engine ou no App Engine, ou pode ser uma conta de serviço definida pelo utilizador usada para autorização de chave privada. A conta tem de ter a função de Editor. | Altere a autorização da conta de serviço na página de IAM do seu projeto. Se necessário, pode modificar o âmbito de acesso de uma VM existente através dos procedimentos de Alteração da conta de serviço e dos âmbitos de acesso de uma instância. |
| Não é possível obter o ID do projeto | O agente do Cloud Logging não conseguiu obter o ID do projeto a partir de um ficheiro de credenciais de chave privada de uma conta de serviço. |
Para adicionar ou substituir um ID do projeto para o agente,
edite o ficheiro de configuração do agente,
/etc/google-fluentd/google-fluentd.conf, na instância
da VM.
Na secção <match **>,
adicione a seguinte linha:project_id [YOUR_PROJECT_ID]Caso contrário, consulte Autorize o agente de registo a corrigir ou substituir as credenciais. |
| O agente de registo de janelas deixa de carregar registos de eventos de alguns canais | O agente de registo pode falhar silenciosamente na ingestão de registos de eventos de determinados canais, mesmo que ainda esteja em execução e a ingerir registos de agentes e registos de eventos de outros canais.
O motivo é que o plugin windows_eventlog tem alguns problemas, conforme
mencionado nesta apresentação.
A utilização de windows_eventlog2
resolve este problema. |
Nota: o formato de dados do plug-in windows_eventlog2 não é retrocompatível
com o plug-in windows_eventlog. Se existirem
pipelines de exportação do BigQuery ou Google Cloud Storage configurados para estes registos,
têm de ser ajustados em conformidade. Veja
esta comparação de entradas do registo
fornecida pela windows_eventlog e pela windows_eventlog2.
Para usar windows_eventlog2, primeiro tem de parar o
agente de registo e, em seguida, substituir o ficheiro de configuração por um semelhante a
este ficheiro de configuração de exemplo.
Por fim, inicie o agente de registos. |
| O agente de registos deixa de carregar registos na presença de logrotate | O agente de registo pode perder o controlo da sua posição nos ficheiros de entrada quando o logrotate está configurado com a definição copytruncate. |
É recomendável usar a definição nocopytruncate para garantir que o logrotate move os ficheiros em vez de os truncar. Se quiser
manter a definição copytruncate, a solução alternativa é
reiniciar o agente
periodicamente. Em alternativa, pode usar a definição postrotate para
reiniciar o agente. |
| error_class=Errno::EADDRINUSE error="Address already in use - bind(2) for 0.0.0.0:24231" | Existem várias instâncias do agente de registo em execução na VM. | Usar ps -aux | grep "/usr/sbin/google-fluentd" para mostrar
processos de agente em execução (devem existir apenas dois: um supervisor e um
trabalhador) e sudo netstat -nltp | grep :24231 para mostrar
processos em execução que ocupam a porta. Terminar instâncias mais antigas conforme
adequado. |
O agente de registos não é iniciado devido a erros de
lib/fluent/config/types.rb |
A configuração do agente de registo usa uma
secção do analisador regex
que tem uma regex com formato incorreto, o que resulta numa chamada subexp inválida e em 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 a regex com formato incorreto no ficheiro de
configuração
do agente. Dica: pesquise regex ou parse. |
Limitação da taxa de transferência de registos
O débito máximo de registos que o agente de registo pode processar está limitado pela CPU. A utilização da CPU tende a aumentar quando o débito de registos aumenta. No entanto, o agente, com a configuração predefinida, só pode usar até um núcleo da CPU. Assim, quando o débito de registos aumenta, o agente pode atingir um limite de utilização da CPU. Se estes picos forem apenas temporários, o agente de registo coloca os registos em buffer e, mais tarde, atualiza-os para os processar. Se o débito dos registos permanecer consistentemente elevado, os registos podem exceder o buffer e, eventualmente, serem perdidos.
Normalmente, quando cada entrada de registo é um texto não processado de 1000 bytes e não contém processamento de formato adicional, o agente do Logging atinge o limite de uma CPU principal a cerca de 5500 entradas de registo por segundo. Se as entradas de registo exigirem processamento avançado, por exemplo, análise JSON ou Regex, o número máximo de entradas de registo por segundo pode ser inferior.
Se precisar de um débito de registos mais elevado, pode considerar usar o Ops Agent. No Linux, para entradas de registo que sejam texto não processado de 1000 bytes e não envolvam processamento adicional, o agente de operações pode processar cerca de 160 000 entradas de registo por segundo.
Tamanho máximo do registo excedido
Se uma ou mais entradas de registo excederem o limite de tamanho máximo, pode encontrar entradas nos registos do fluentd semelhantes às 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 este erro, reduza as entradas do registo para que não excedam o limite de tamanho máximo. Por exemplo, o seguinte código de exemplo corta registos com a etiqueta 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 registos estão duplicados
LogEntry.insertID
é adicionado no pipeline de processamento no agente. Se insertID for diferente entre os registos duplicados, isto indica que os registos são seguidos a partir dos ficheiros de registo várias vezes. Isto pode acontecer na presença da rotação de registos ou quando o ficheiro
pos está em falta ou danificado. Para reduzir a probabilidade de este problema ocorrer, certifique-se de que os ficheiros de posição para qualquer entrada in_tail não estão configurados para estar na pasta /var/log nem em quaisquer outras pastas que possam ter a rotação de registos ativada.
O pipeline de registo também depende do campo LogEntry.timestamp para remover registos duplicados. Certifique-se de que a data/hora real da entrada do registo é analisada corretamente. Se o Fluentd não estiver configurado para analisar a data/hora original da entrada de registo, o Fluentd usa a hora em que processa a entrada de registo. Assim, se a entrada for lida várias vezes, mesmo que a data/hora na linha de registo seja a mesma, o Fluentd pode tratá-las como entradas de registo diferentes com datas/horas diferentes.
Erros repetidos no registo de auditoria: Data points cannot be written more than 24h in the past
Existe um problema conhecido que afeta as versões 1.8.5 a 1.9.3 (inclusive), o que faz com que registos como os seguintes apareçam repetidamente nos registos de auditoria de acesso aos dados quando o agente está 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 é atualizar o seu agente para a versão 1.9.4 ou posterior.
Os carateres Unicode nos registos são substituídos por espaços ou "�"
Por predefinição, a entrada in_tail espera que os ficheiros de entrada sejam codificados em ASCII, pelo que substitui qualquer carater não ASCII por um espaço. Para carregar ficheiros codificados em UTF-8, tem de fornecer duas opções na configuração in_tail:
<source>
@type tail
…
encoding UTF-8
from_encoding UTF-8
</source>
Ambas as opções são necessárias. Se for fornecida apenas a opção encoding, os carateres não ASCII nos registos carregados são substituídos por "�".
Agente removido comunicado pela consola Google Cloud como instalado
Depois de desinstalar o agente, a Google Cloud consola pode demorar até uma hora a comunicar esta alteração.
O agente de registos não aparece na lista Desinstalar um programa do Windows
Para desinstalar o agente de registo quando não estiver listado na lista Desinstalar um programa do painel de controlo do Windows, execute uninstall.exe a partir do diretório onde o instalou.