Simple Log Service:Coleta de logs de contêineres Kubernetes

Recursos

O SLS oferece as seguintes capacidades para a coleta de logs de contêineres Kubernetes:

• Suporte a múltiplas origens de log

  • Coleta diversos tipos de log: stdout, stderr e logs de arquivos de texto do contêiner.

• Filtragem granular de contêineres

  • Inclua ou exclua contêineres com base no nome do namespace, nome do pod, nome do contêiner, rótulos do contêiner ou variáveis de ambiente.

• Processamento avançado de logs

  • Colete logs multilinha: agrupe entradas multilinha, como stack traces do Java, em eventos de log únicos.

  • Pré-processe logs: descarte dados inválidos com um plugin de filtragem de dados ou mascare e estruture dados sensíveis com os plugins de mascaramento e criptografia de dados e de processamento de campos.

  • Analise campos: estruture logs brutos antes do armazenamento com plugins baseados em análise de dados.

• Associação inteligente de metadados

  • Associe metadados automaticamente aos logs de contêiner, como nome do contêiner, imagem, pod, namespace e variáveis de ambiente.

• Confiabilidade

  • Um mecanismo de checkpoint registra a posição atual da coleta para garantir a integridade dos logs.

  • Gerencia logs quando um contêiner para ao fornecer estratégias diferentes para diversos runtimes de contêiner.

Limitações

• Runtime do contêiner: apenas docker e Containerd são suportados.

  docker:

  • Requer permissões para acessar docker.sock.

  • Para coleta de saída padrão, apenas o driver de log json-file é suportado.

  • Apenas os drivers de armazenamento overlay e overlay2 são suportados. Para outros drivers de armazenamento, monte o diretório de log usando um volume.

  Containerd:

  • Requer permissões para acessar containerd.sock.

• Limite de log multilinha:

  A última linha coletada permanece em buffer por 3 segundos por padrão para evitar que logs multilinha sejam divididos devido a atrasos na saída. Ajuste esse comportamento com o parâmetro BeginLineTimeoutMs (mínimo: 1.000 ms).

• Saída padrão:

  O tamanho máximo padrão da entrada de log é 512 KB (524.288 bytes), com limite superior de 8 MB (8.388.608 bytes). Para aumentar esse limite, defina a variável de ambiente max_read_buffer_size no contêiner do LoongCollector.

  Importante

  Não ative a coleta de stdout e stderr simultaneamente. Isso pode causar intercalação incorreta das entradas de log.

Visão geral do fluxo de coleta

1. Prepare a source do log: identifique os logs de stdout ou de arquivos de texto a serem coletados.

2. Instale o LoongCollector: implante o coletor para transmitir logs ao SLS.

3. Configure as regras de coleta: defina regras de coleta de logs e plugins de análise.

4. Consulte e analise logs: monitore seus serviços com os dados de log coletados.

Processos principais

Requisitos de source de log e ponto de montagem

• Para logs de saída padrão, o LoongCollector descobre automaticamente o caminho do arquivo de log com base nos metadados do contêiner.

• Para logs de arquivos de texto do contêiner, o LoongCollector monta o diretório raiz do host em /logtail_host por padrão. Geralmente, não é necessária montagem manual. Se você utilizar um ponto de montagem personalizado, garanta que ele atenda aos seguintes requisitos:

  Requisitos para ponto de montagem personalizado

  Caminho do arquivo de log:

  • Não use links simbólicos:

    • Configuração incorreta: /var/log -> /mnt/logs.

    • Configuração correta: use diretamente o caminho físico /mnt/logs.

  • Regra de correspondência de caminho de montagem: se o diretório de dados do contêiner da sua aplicação for montado via volume, o caminho de coleta deve ser igual ou um subdiretório do ponto de montagem.

    1Mount point: /var/log/service
    2✅ Valid collection path: /var/log/service or /var/log/service/subdir
    3❌ Invalid collection path: /var/log (The path is not specific enough)

Instalação do coletor

O LoongCollector suporta dois modos de implantação:

Modo de implantação: DaemonSet ou sidecar.

• Modo DaemonSet: implanta automaticamente um agente LoongCollector em cada nó. Adequado para a maioria dos cenários.

  • No modo DaemonSet, o método de implantação depende do tipo de cluster e da relação da conta do SLS.

    • Para clusters do Container Service for Kubernetes (ACK), o componente loongcollector-ds já vem pré-integrado. Ative-o no console do ACK para concluir a instalação. Por padrão, os logs são armazenados no projeto do SLS da conta proprietária do cluster. Installation and configuration.

    • Para coletar logs de um cluster ACK em um projeto do SLS pertencente a uma conta diferente da Alibaba Cloud, instale manualmente o LoongCollector e configure-o com o ID ou AccessKey da conta de destino. Installation and configuration.

    • Para clusters autogerenciados, instale manualmente o LoongCollector e configure-o com o ID ou AccessKey da conta da Alibaba Cloud de destino. Installation and configuration.

    Instale o LoongCollector antes de iniciar a coleta de logs. Collect container logs from a Kubernetes cluster by using a CRD (standard output/file) .

• Modo Sidecar: injeta um contêiner LoongCollector em cada pod da aplicação. Utilize este modo para contêineres serverless, pods de alto volume que excedem a capacidade do DaemonSet ou clusters com runtimes de contêiner seguros. Collect Kubernetes pod text logs (sidecar mode).

Regras de coleta

O SLS oferece suporte a dois métodos para definir regras de coleta:

Conceitos-chave

• Kubernetes: plataforma de orquestração de contêineres open source que automatiza a implantação, o dimensionamento e a gestão de aplicações conteinerizadas.

• Logs de saída padrão, erro padrão e arquivos de texto: o stdout captura a saída normal do programa (logs de negócios, registros operacionais). O stderr captura erros e avisos (stack traces, falhas de inicialização). Ambos são direcionados ao terminal e capturados pelo mecanismo de contêiner. Logs de arquivos de texto são gravados em arquivos pelas aplicações (por exemplo, access.log do Nginx) e são excluídos quando o contêiner é destruído, a menos que sejam persistidos com um volume.

• Mecanismo de checkpoint: registra a posição da coleta em um arquivo, salvo em /tmp/logtail_checkpoint por padrão. Garante uma coleta confiável após reinicializações do LoongCollector ou falhas no nó.

• LoongCollector (Logtail): coletor de logs de alto desempenho desenvolvido pela Alibaba Cloud que suporta implantação via DaemonSet e sidecar no Kubernetes. O LoongCollector é o sucessor do Logtail e totalmente compatível com versões anteriores.

• CRD do Kubernetes: CustomResourceDefinition que permite definir recursos personalizados para configuração. O SLS usa AliyunPipelineConfig como seu tipo de CRD.

• Configuração de coleta: define regras para tipos de log, caminhos de coleta, filtragem, análise e local de armazenamento. What is a collection configuration?.

• Plugin de análise: unidade de processamento dentro da configuração de plugin de processamento para estruturar, dividir, filtrar ou dessensibilizar o conteúdo do log. Suporta modos de expressão regular, separador, JSON e multilinha.

Como funciona

1. Um usuário cria um Custom Resource (CR) usando kubectl para definir uma regra de coleta.

2. O loongcollector-operator monitora continuamente alterações nos CRs do cluster.

3. Ao detectar uma alteração, o Operator converte o CR em uma configuração do LoongCollector e a aplica ao Simple Log Service.

4. O agente LoongCollector envia periodicamente heartbeats ao Simple Log Service para buscar atualizações de configuração, obtém a configuração de coleta mais recente e a aplica dinamicamente.

5. O agente loongcollector-ds coleta logs conforme a nova configuração e os envia ao SLS através do endpoint configurado.

Modo DaemonSet

Implanta um agente LoongCollector em cada nó para coletar logs de todos os contêineres nesse nó. Oferece operação simples, baixo consumo de recursos e configuração flexível, mas com isolamento de tenant mais fraco.

Como funciona o modo DaemonSet

• No modo DaemonSet, o Kubernetes executa exatamente um contêiner LoongCollector em cada nó para coletar logs de todos os contêineres presentes nele.

• O Kubernetes cria e destrói automaticamente contêineres LoongCollector à medida que nós entram ou saem do cluster, eliminando a gestão manual de instâncias.

Modo Sidecar

Injeta um sidecar LoongCollector junto ao contêiner da aplicação em cada pod. O diretório de logs da aplicação é compartilhado via volume do Kubernetes (emptyDir, hostPath ou PVC), permitindo que o LoongCollector leia os arquivos de log diretamente. Proporciona forte isolamento de tenant e alto desempenho, mas consome mais recursos.

Como funciona o modo sidecar

• No modo sidecar, cada pod executa um contêiner LoongCollector dedicado. A coleta de logs é isolada entre os pods.

• Monte um volume compartilhado tanto nos contêineres da aplicação quanto nos do LoongCollector para acesso aos arquivos de log.

• Quando o volume de logs de um pod excede a capacidade do DaemonSet, o modo sidecar permite alocar recursos dedicados ao LoongCollector.

• Ambientes serverless não possuem nós, tornando o DaemonSet inaplicável. O modo sidecar integra-se diretamente às arquiteturas serverless.

Descoberta de contêineres

O LoongCollector precisa identificar os contêineres em execução no nó antes de coletar seus logs. Esse processo é chamado de descoberta de contêineres.

• O LoongCollector comunica-se diretamente com o daemon do runtime de contêiner no nó, e não com o kube-apiserver do cluster. Isso evita carga extra no kube-apiserver.

• O LoongCollector acessa o socket do runtime de contêiner (docker ou Containerd) no host. Ele permite incluir ou excluir contêineres por namespace, nome do pod, rótulos do pod ou variáveis de ambiente.

Coleta de saída padrão

O LoongCollector identifica automaticamente a API ou o driver de log correto para cada runtime de contêiner (docker, Containerd) com base nos metadados. Ele lê o fluxo stdout diretamente, sem acessar os sistemas de arquivos dos contêineres.

Coleta de logs de arquivos de texto do contêiner

• O Kubernetes isola os sistemas de arquivos dos contêineres, impedindo que um coletor acesse diretamente arquivos em outros contêineres. O LoongCollector monta o sistema de arquivos raiz do host para acessar indiretamente os arquivos do contêiner da aplicação.

• Por padrão, o sistema de arquivos raiz do host é montado em /logtail_host. Normalmente, não é necessária montagem manual. Por exemplo, se um arquivo de log do contêiner estiver em /log/app.log e seu caminho no host for /var/lib/docker/containers/<container-id>/log/app.log, o LoongCollector o lerá a partir de /logtail_host/var/lib/docker/containers/<container-id>/log/app.log.

Análise de logs multilinha

O LoongCollector usa uma expressão regular definida pelo usuário para corresponder ao início de uma linha de log.

• Correspondência bem-sucedida: a linha é tratada como o início de uma nova entrada de log.

• Falha na correspondência: a linha é anexada à entrada de log atual.

Quando outra linha corresponde à expressão regular de início de linha, a entrada de log atual é finalizada e uma nova é iniciada.

Processamento de logs quando um contêiner para

Após a exclusão de um pod, os logs já coletados no LogStore do Simple Log Service não são afetados. Os logs são retidos durante o período de retenção de dados do LogStore e permanecem consultáveis dentro desse período. É possível alterar o período de retenção no console do Simple Log Service.

Após a exclusão de um pod, as configurações de coleta baseadas em rótulos ou namespaces são aplicadas automaticamente aos novos pods que possuem os mesmos rótulos. Quando uma atualização contínua (rolling update) de Deployment exclui pods antigos e cria novos, o Simple Log Service coleta automaticamente os logs dos novos pods, sem necessidade de reconfigurar as regras de coleta.

Recuperação de metadados do contêiner

O LoongCollector recupera metadados do Kubernetes diretamente através da API CRI (Container Runtime Interface), permitindo a marcação de metadados em tempo real e não intrusiva durante a coleta.

• docker: o LoongCollector usa o Docker Client para se comunicar com o Docker Daemon na recuperação de metadados. As principais APIs incluem:

  • ContainerList: lista os contêineres em execução no nó.

  • ContainerInspect: retorna a configuração detalhada e o status do contêiner.

  • Events: escuta eventos do ciclo de vida do contêiner em tempo real.

  Principais campos de metadados recuperados via Docker Client:

  • LogPath: o caminho no host do arquivo de log stdout do contêiner.

  • GraphDriver.Data: o caminho no host do rootfs do contêiner, usado para acesso ao sistema de arquivos e solução de problemas.

• Containerd: o LoongCollector usa a CRI para suportar ambientes containerd e CRI-O, coletando metadados de runtimes subjacentes como runc ou Kata Containers.

  • A CRI fornece o caminho do host do arquivo de log stdout, mas não o caminho do rootfs do contêiner. O LoongCollector usa estes métodos para encontrá-lo:

    • Busca por caminho de arquivo: pesquisa no sistema de arquivos do host o caminho do rootfs do contêiner usando o ID do contêiner.

    • Interação direta com containerd: o LoongCollector pode ignorar a CRI e comunicar-se diretamente com o containerd para obter o caminho do rootfs e outros metadados não disponíveis via CRI.