Simple Log Service:Solução de problemas na coleta de logs de contêineres

Ausência de heartbeat após reutilização de grupo de segurança existente pelo cluster ACK

Quando um cluster ACK utiliza um grupo de segurança existente, o LoongCollector ou Logtail pode falhar ao reportar o heartbeat de um grupo de máquinas. Isso ocorre quando o grupo de segurança do ECS não permite tráfego de entrada proveniente do Pod CIDR. Consequentemente, o LoongCollector não consegue acessar o CoreDNS para resolver o endpoint do Simple Log Service.

Resolva o problema da seguinte forma:

1. Faça login no console do ECS e localize o grupo de segurança utilizado pelo cluster ACK.

2. Adicione uma inbound rule que permita todos os protocolos e portas provenientes do Pod CIDR. Por exemplo, use 10.229.0.0/16 quando esse valor corresponder ao Pod CIDR do cluster.

3. Confirme se os Pods conseguem acessar o CoreDNS e resolver o endpoint do Simple Log Service.

4. Reinicie o DaemonSet loongcollector-ds no namespace kube-system:

   kubectl rollout restart daemonset/loongcollector-ds -n kube-system

5. Verifique novamente o heartbeat dos Machine Groups e confirme se a coleta de logs foi retomada.

FAQ: Por que não há heartbeat após a implantação do Docker/LoongCollector?

Se o LoongCollector ou Logtail não apresentar heartbeat ou falhar ao se registrar no grupo de máquinas após a implantação do Docker, a causa raiz geralmente é a ausência da configuração do identificador de usuário (AliUID).

Solução:

1. No host, crie o diretório /etc/ilogtail/users/.

   mkdir -p /etc/ilogtail/users/

2. Dentro do diretório /etc/ilogtail/users/, crie um arquivo vazio com o nome do seu ID de conta Alibaba Cloud.

   touch /etc/ilogtail/users/<your-alibaba-cloud-account-id>

3. Ao iniciar o contêiner LoongCollector ou Logtail, monte o diretório como somente leitura adicionando o seguinte sinalizador:

   -v /etc/ilogtail/users:/etc/ilogtail/users:ro

4. Reinicie o contêiner LoongCollector ou Logtail.

Verificação: Faça login no console SLS, acesse Resources > Machine Groups e encontre o grupo de máquinas alvo. Clique em Check Status na coluna Actions. Na caixa de diálogo View Machine Group Status, confirme se o status de heartbeat do grupo de máquinas mudou para OK.

FAQ: Por que o grupo de máquinas mostra apenas um servidor quando vários servidores Docker Swarm reportam o mesmo IP?

Causa: Em um cluster Docker Swarm, vários servidores podem reportar o mesmo endereço IP interno através da rede de contêineres. Se esses servidores também compartilharem o mesmo valor da variável de ambiente ALIYUN_LOGTAIL_USER_DEFINED_ID, o sistema não consegue distingui-los, e os Machine Groups exibem apenas uma entrada.

Solução 1: Defina uma variável de ambiente ALIYUN_LOGTAIL_USER_DEFINED_ID exclusiva para o contêiner Logtail em cada servidor.

Configure um valor diferente em cada servidor e garanta que o valor corresponda à configuração dos Machine Groups correspondentes. Por exemplo:

-e ALIYUN_LOGTAIL_USER_DEFINED_ID=<unique-id-for-this-server>

Solução 2: Defina a variável de ambiente ALIYUN_LOGTAIL_WORKING_IP para especificar manualmente um endereço IP exclusivo para cada servidor.

Utilize um valor que identifique exclusivamente cada host, como o endereço IP público do host ou um endereço IP de rede interna que seja único em todos os servidores:

-e ALIYUN_LOGTAIL_WORKING_IP=<unique-ip-for-this-server>

Caso não encontre logs na página de Preview ou na página de consulta do Logstore no console do Simple Log Service, é possível que o service não esteja coletando seus logs de contêiner. Verifique o status do contêiner e realize as verificações a seguir.

Solucionar logs ausentes de sidecar Istio

Um log de sidecar Istio pode não ser coletado quando o arquivo de log do contêiner correspondente deixar de existir. A coleta também pode falhar quando o ContainerFilters não corresponder exatamente ao contêiner sidecar do Istio.

Realize as seguintes verificações em ordem:

1. Verifique o Deployment ou StatefulSet do Pod e confirme se ele contém a variável de ambiente correta para a configuração do Logtail. Por exemplo:

   aliyun_logs_reconfig-zltx-test-stdout: "stdout"

2. Confirme se o componente Logtail ou LoongCollector está instalado e em execução. Verifique se o ConfigMap dele contém a configuração esperada.

3. Na configuração de coleta, utilize ContainerFilters para configurar uma correspondência exata para o contêiner sidecar do Istio. Valide se o filtro identifica o sidecar, e não apenas o contêiner da aplicação.

4. Aplique a carga de trabalho ou configuração de coleta corrigida e confirme se o arquivo de log do contêiner correspondente ainda existe. Gere uma nova entrada de log do sidecar e verifique se o Simple Log Service a recebe.

O grupo de máquinas não abrange todos os nós de contêiner

Sintoma: O heartbeat do grupo de máquinas está normal, mas a coleta de logs de alguns contêineres parou.

Esse problema pode ocorrer quando os contêineres estão sendo executados em servidores que não foram incluídos nos Machine Groups.

Etapas de solução de problemas:

1. Em todos os servidores relevantes, execute o comando a seguir para identificar em quais nós os contêineres estão realmente em execução:

   docker ps -a | grep <container-name>

2. Compare os endereços IP dos nós que executam os contêineres com a lista de IPs configurada no grupo de máquinas. Se um contêiner estiver em execução em um servidor que não foi adicionado ao grupo de máquinas, adicione o endereço IP desse servidor aos Machine Groups no console SLS.

FAQ: Por que não consigo encontrar o Pod na pré-visualização de metadados do contêiner, ou por que não é possível coletar logs do emptyDir?

Causa: O Logtail executando no modo DaemonSet não consegue acessar diretamente o armazenamento temporário emptyDir dentro de um contêiner. Isso impede que o Logtail leia arquivos de log e extraia metadados do contêiner, fazendo com que o Pod não seja encontrado na Preview de metadados do contêiner.

Solução 1 (Recomendada): Redirecione a saída de logs da aplicação para a saída padrão (stdout/stderr).

1. Modifique sua aplicação para gravar logs no stdout ou stderr em vez de arquivos.

2. No console SLS, configure o caminho de coleta para usar o caminho de log padrão do Kubernetes:

   /logtail_host/var/log/pods/<namespace>_<pod-name>-<uid>/<container-name>/*.log

Solução 2: Se sua aplicação precisar obrigatoriamente gravar logs em arquivos, altere a montagem do volume de log de emptyDir para hostPath ou PVC.

1. Na especificação do seu Pod, substitua o volume emptyDir por uma definição hostPath ou PVC, para que os logs sejam persistidos em um caminho acessível a partir do host.

2. Ajuste o caminho de coleta do SLS para apontar para o caminho de montagem real no host, por exemplo:

   /logtail_host/var/log/your-app/*.log

FAQ: Como lidar com falhas na criação de arquivos ou erros de permissão ao coletar logs de contêineres?

Sintoma: Uma mensagem de erro indica que o Logtail precisa criar um arquivo vazio específico dentro do contêiner, mas a criação do arquivo falha ou um erro de permissão é reportado.

Solução:

1. Crie manualmente o arquivo vazio especificado na mensagem de erro dentro do contêiner:

   touch <file-path>

2. Defina as permissões do arquivo como -rw-r--r-- (644):

   chmod 644 <file-path>

3. Reinicie o contêiner.

Alternativa: Se o problema persistir após as etapas acima, monte o diretório de logs do contêiner na máquina host e configure o SLS para coletar logs do caminho correspondente no host. Essa abordagem é mais estável do que a coleta de arquivos dentro do contêiner.

FAQ: Como lidar com o erro "parse cri docker line error: invalid CRI log, timestamp not found"?

Causa: Falha na análise do log. Esse erro é comumente causado por uma configuração incorreta de log multilinha.

Solução:

1. Verifique e ajuste a expressão regular de início de linha, ou desative o modo multilinha:

   • Na configuração YAML: Comente ou remova a seção de configuração multiline e reaplique a configuração.

   • No console SLS: Abra a configuração do Logtail e desative o modo multilinha.

2. Verifique se o K8s Namespace Regex e outros campos de formato estão corretos. Para corresponder a múltiplos namespaces, separe-os com uma barra vertical (|), por exemplo, namespace1|namespace2.

3. Após modificar a configuração YAML, reaplique-a para que as alterações tenham efeito:

   kubectl apply -f <your-config-file>.yaml

FAQ: O que fazer se uma marca de exclamação vermelha aparecer ao lado do plugin de análise JSON e a configuração do Logtail não puder ser salva?

Sintoma: Após adicionar um plugin de análise JSON a uma configuração do Logtail, uma marca de exclamação vermelha aparece ao lado do ícone do plugin, e a configuração não pode ser salva na caixa de diálogo.

Causa: A marca de exclamação vermelha geralmente indica que o plugin não está configurado, ou que a configuração foi alterada, mas não aplicada.

Solução:

1. Na página de edição da configuração do Logtail, exclua o plugin de análise JSON que foi adicionado por padrão.

2. Adicione manualmente um plugin de análise JSON novamente e preencha todos os campos obrigatórios, como a amostra de log e as regras de análise.

3. Após concluir a configuração, a marca de exclamação vermelha desaparecerá e você poderá salvar a configuração do Logtail.

FAQ: O que fazer se nenhum dado for coletado porque múltiplas configurações do Logtail correspondem ao mesmo arquivo (MULTI CONFIG MATCH ALARM)?

Sintoma: O alerta MULTI CONFIG MATCH ALARM aparece nos logs operacionais do Logtail, e nenhum dado é coletado do arquivo alvo.

Causa: Por padrão, um arquivo de log pode corresponder a apenas uma configuração do Logtail. Quando múltiplas configurações do Logtail correspondem ao mesmo arquivo, apenas uma delas entra em vigor. As outras configurações não conseguem coletar dados e acionam o alerta MULTI CONFIG MATCH ALARM.

Solução:

1. Exclua configurações redundantes do Logtail: No console do Simple Log Service, verifique todas as configurações do Logtail vinculadas aos Machine Groups. Exclua configurações duplicadas ou não utilizadas para que cada arquivo corresponda a apenas uma configuração.

2. Divida a correspondência por nome do pod: Se você precisar de múltiplas configurações para o mesmo arquivo, por exemplo, para dividir a coleta por nome do pod, modifique as configurações conforme descrito na documentação oficial. Garanta que cada configuração do Logtail corresponda apenas ao seu próprio arquivo alvo através de um caminho mais preciso ou filtro de rótulo, evitando sobreposição de caminhos.

3. Após a modificação, verifique os logs operacionais do Logtail e confirme se o alerta MULTI CONFIG MATCH ALARM desapareceu e se os dados estão sendo coletados conforme esperado.

FAQ: Como lidar com o erro do Logtail no such file or directory ao coletar logs de contêineres?

Sintoma: Os logs operacionais do Logtail contêm o erro no such file or directory, e os logs do contêiner alvo não podem ser coletados. Certifique-se de que um índice foi criado para o LogStore para que os logs possam ser consultados e analisados após a coleta.

Causa: O caminho de coleta alvo não existe no nó. Esse problema geralmente está relacionado ao ciclo de vida do pod do Kubernetes ou ao mecanismo de rotação de logs.

Solução:

1. Verifique se o pod ainda existe: Se o pod tiver sido excluído, o caminho de log correspondente não existe mais e você pode ignorar o erro. Se o pod ainda estiver em execução, faça login no servidor (nó) e verifique se o caminho de log real existe.

2. Use a coleta de stdout do contêiner sempre que possível: Ao criar uma configuração de coleta de logs no console ACK, selecione o tipo Container Stdout e corresponda ao contêiner alvo por rótulo ou nome do contêiner, em vez de depender do caminho de arquivo interno do contêiner.

3. Sugestões de configuração quando a coleta de arquivos for necessária: Use um caminho com curinga, por exemplo, /logtail_host/var/log/pods/*/*.log, e ative a descoberta automática de novos arquivos na configuração do Logtail para que ele possa rastrear novos caminhos após a rotação de logs ou recriação do pod.

4. Verifique se a configuração do Logtail está aplicada ao grupo de máquinas: Assegure-se de que a configuração do Logtail esteja vinculada aos Machine Groups que contêm o pod alvo.

5. Verifique os logs operacionais do Logtail: Se um grande número de erros estiver concentrado em pods que já foram destruídos, você pode ignorá-los. Se os erros persistirem e o pod ainda estiver em execução, corrija o caminho de coleta ou verifique a montagem do nó.

FAQ: Como lidar com interrupção de coleta causada pelo Logtail ignorando arquivos devido a logfiletoobig?

Sintoma: O alerta logfiletoobig aparece nos logs operacionais do Logtail, o arquivo alvo é ignorado e a coleta de logs é interrompida.

Causa: O tamanho do arquivo de log alvo excede o limite padrão do Logtail. O Logtail ignora o arquivo para proteger sua estabilidade.

Solução:

1. Ajuste os parâmetros de coleta do Logtail: Na configuração do Logtail ou nos parâmetros globais dos Machine Groups, faça as seguintes alterações:

   • Aumente o MaxLogFileSize, por exemplo, para 1GB, para evitar que arquivos grandes sejam ignorados.

   • Aumente o MaxLogFileInodeCacheSize, por exemplo, para 2000, para melhorar o rastreamento de arquivos rotacionados.

   • Defina EnableContainerDiscovery como true para que o Logtail possa descobrir automaticamente caminhos de log de contêineres e criar entradas de rastreamento automaticamente para novos pods.

2. Acione uma nova varredura: No cluster ACK, execute o comando a seguir para excluir o pod loongcollector-ds (ou Logtail-ds). O DaemonSet recriará automaticamente o pod e fará uma nova varredura em todos os caminhos de log dos contêineres:

   kubectl delete pod -n kube-system -l k8s-app=loongcollector-ds

Solução de problemas suplementar para ACK

Em um cluster ACK, se a coleta de logs ainda não retornar dados após as verificações anteriores, cheque os dois itens a seguir:

1. Verifique a configuração de coleta CRD do ACK: Execute o comando a seguir para visualizar as configurações de coleta CRD do cluster ACK:

   kubectl get ClusterAliyunPipelineConfig -A

   Valide se o LogStore e as regras de coleta na saída correspondem às suas expectativas.

2. Verifique a declaração de volume da imagem do contêiner: Execute o comando docker inspect na imagem do contêiner e verifique o campo Config.Volumes:

   docker inspect <image-name> | grep -A5 Volumes

   Se Config.Volumes não estiver vazio, a imagem declara um VOLUME que pode sobrescrever o caminho do arquivo de log. Remova a declaração VOLUME ou monte o volume como emptyDir.

Fazer login em um contêiner Logtail

• Docker Padrão

  1. No host, execute o comando a seguir para localizar o contêiner Logtail.

     docker ps | grep logtail

     A saída será semelhante a esta:

     223****6e        registry.cn-hangzhou.aliyuncs.com/log-service/logtail                             "/usr/local/ilogta..."   8 days ago          Up 8 days                               logtail-iba

  2. Execute o comando a seguir para iniciar um shell bash no contêiner Logtail.

     docker exec -it 223****6e  bash

     Substitua 223****6e pelo ID real do contêiner.

• Kubernetes

  1. Execute o comando a seguir para localizar o pod Logtail.

     kubectl get po -n kube-system | grep logtail

     A saída será semelhante a esta:

     logtail-ds-****d                                             1/1       Running    0          8d
     logtail-ds-****8                                             1/1       Running    0          8d

  2. Execute o comando a seguir para fazer login no pod.

     kubectl exec -it -n kube-system logtail-ds-****d -- bash

     Substitua logtail-ds-****d pelo ID real do pod.

Visualizar logs de runtime do Logtail

O Logtail armazena seus logs no diretório /usr/local/ilogtail/ do contêiner Logtail. Os arquivos de log são ilogtail.LOG e logtail_plugin.LOG.

1. Faça login no contêiner Logtail. Para mais informações, consulte Log on to a Logtail container.

2. Acesse o diretório /usr/local/ilogtail/.

   cd /usr/local/ilogtail

3. Visualize os arquivos ilogtail.LOG e logtail_plugin.LOG.

   cat ilogtail.LOG
   cat logtail_plugin.LOG

Saída padrão (stdout) do contêiner Logtail

A saída padrão de um contêiner Logtail não fornece informações úteis para solução de problemas. Você pode ignorar o seguinte conteúdo.

start umount useless mount points, /shm$|/merged$|/mqueue$
umount: /logtail_host/var/lib/docker/overlay2/3fd0043af174cb0273c3c7869500fbe2bdb95d13b1e110172ef57fe840c82155/merged: must be superuser to unmount
umount: /logtail_host/var/lib/docker/overlay2/d5b10aa19399992755de1f85d25009528daa749c1bf8c16edff44beab6e69718/merged: must be superuser to unmount
umount: /logtail_host/var/lib/docker/overlay2/5c3125daddacedec29df72ad0c52fac800cd56c6e880dc4e8a640b1e16c22dbe/merged: must be superuser to unmount
......
xargs: umount: exited with status 255; aborting
umount done
start logtail
ilogtail is running
logtail status:
ilogtail is running

Verificar status dos componentes do Kubernetes

Execute o comando a seguir para visualizar o status e as informações da implantação do Simple Log Service.

kubectl get deploy -n kube-system | grep -E 'alibaba-log-controller|loongcollector-operator'

A seguinte saída será retornada:

NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
alibaba-log-controller   1/1     1            1           11d

Execute o comando a seguir para visualizar as informações de status do recurso DaemonSet.

kubectl get ds  -n kube-system | grep -E 'logtail-ds|loongcollector-ds'

A seguinte saída será retornada:

NAME         DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR  AGE
logtail-ds   2         2         2       2            2           **ux           11d

Versão, endereço IP e horário de inicialização do Logtail

1. No host, execute o comando a seguir para visualizar a versão, o endereço IP e o horário de inicialização do Logtail.

   As informações estão armazenadas no arquivo /usr/local/ilogtail/app_info.json do contêiner Logtail.

   kubectl exec logtail-ds-****k -n kube-system cat /usr/local/ilogtail/app_info.json

   A saída será semelhante a esta:

   {
      "UUID" : "",
      "hostname" : "logtail-****k",
      "instance_id" : "0EB****_172.20.4.2_1517810940",
      "ip" : "172.20.4.2",
      "logtail_version" : "0.16.2",
      "os" : "Linux; 3.10.0-693.2.2.el7.x86_64; #1 SMP Tue Sep 12 22:26:13 UTC 2017; x86_64",
      "update_time" : "2018-02-05 06:09:01"
   }

Obter informações de solução de problemas para logs de Pod em um cluster ACK

Se a coleta de logs para um Pod em um cluster ACK estiver anormal, utilize as etapas a seguir para obter as informações básicas necessárias para autossolução de problemas ou para fornecer ao suporte técnico.

Etapa 1: Encontre o nome do Pod Logtail ou LoongCollector.

kubectl get pods -n kube-system | grep loongcollector

Etapa 2: Obtenha o endereço IP da instância Logtail ou LoongCollector a partir do arquivo app_info.json.

kubectl exec <pod-name> -n kube-system cat /usr/local/ilogtail/app_info.json

O campo ip na saída JSON retornada é o endereço IP da instância Logtail.

Ao solicitar suporte, forneça as seguintes informações para auxiliar na solução de problemas:

• Nome do Projeto SLS

• Nome da configuração de coleta do Logtail

• Nome do Pod alvo

• Nome do contêiner alvo

Lidar com Logstores CRD excluídos acidentalmente

Se você excluir um Logstore criado automaticamente por uma Custom Resource Definition (CRD), os dados coletados serão irrecuperáveis e a configuração CRD para o Logstore se tornará inválida. Para evitar problemas na coleta de logs, escolha uma das seguintes soluções:

• Na configuração CRD, utilize um Logstore diferente daquele que você excluiu.

• Reinicie o pod alibaba-log-controller.

  Execute o comando a seguir para localizar o pod.

  kubectl get po -n kube-system | grep alibaba-log-controller

FAQ: Executar docker pull para baixar a imagem do LoongCollector ou Logtail afeta outros services no host?

Conclusão: Executar apenas o comando docker pull para baixar a imagem do LoongCollector ou Logtail não afeta outros services em execução no host. Isso se aplica tanto a instâncias ECS da Alibaba Cloud quanto a servidores locais. O comando docker pull apenas baixa camadas de imagem para o repositório de imagens local. Ele não inicia um contêiner nem consome recursos adicionais de CPU ou memória.

Precauções:

• Ao executar posteriormente o docker run para iniciar um contêiner, certifique-se de que o host tenha recursos suficientes de CPU e memória para que o novo contêiner não compita com as cargas de trabalho existentes.

• Verifique se o mapeamento de portas do contêiner entra em conflito com portas já utilizadas por services existentes no host.

• Se desejar executar o componente de coleta de logs no Kubernetes a longo prazo, instale o LoongCollector no modo DaemonSet através do Component Management no console ACK (Recomendado). Isso permite que o cluster agende recursos de maneira unificada.

FAQ: Um Pod que não está em estado Running afeta a coleta de logs de arquivos?

Conclusão: Sim. O LoongCollector e o Logtail coletam arquivos de dentro do contêiner. Se o service falhar ao iniciar e o Pod não estiver em estado Running, o contêiner pode não criar o arquivo de log ou seu diretório. O coletor não consegue ler ou coletar um arquivo de um caminho que não existe.

Para verificar a coleta de logs de arquivos, defina temporariamente o comando de inicialização do service para manter o contêiner em execução. Por exemplo:

sleep 3600

Depois que o Pod entrar no estado Running, grave manualmente uma entrada de log de teste no caminho de arquivo configurado. Em seguida, verifique se o LoongCollector ou Logtail coleta a nova entrada. Restaure o comando de inicialização original após o teste.

FAQ: Por que não consigo consultar logs stdout do contêiner por nome de método ou outro campo de negócio?

O Simple Log Service só consegue consultar campos quando eles existem no log coletado e um índice é criado para eles. Se o stdout do contêiner ou o log da aplicação não contiver um nome de método, informações do chamador ou outro campo de negócio, você não poderá consultar esse campo diretamente no Simple Log Service.

Verifique a configuração de logging em sua aplicação ou gateway, como NGINX ou Spring Cloud Gateway. Assegure-se de que cada campo de negócio necessário seja gravado no stdout ou no arquivo de log coletado.

Para adicionar contexto do Kubernetes, abra Input Configurations na configuração de coleta e ative Enrich Log Tags. Esse recurso pode anexar variáveis de ambiente ou rótulos de Pod do Kubernetes como tags, incluindo metadados como nome do Pod, namespace e rótulos.

Um campo de conteúdo de log faz parte do texto emitido pela aplicação ou gateway. Uma tag de metadados é anexada durante a coleta para enriquecer o contexto do log. O enriquecimento de tags não cria um nome de método ou campo de chamador ausente no conteúdo original do log.