Simple Log Service:Coletar logs de contêiner (saída padrão e arquivos)

Caso de uso 1: Processar logs multilinha

Logs como stack traces do Java e objetos JSON frequentemente abrangem várias linhas. Por padrão, eles são divididos em registros incompletos. Ative o modo multilinha e configure uma expressão regular para a primeira linha a fim de mesclar linhas consecutivas em registros completos.

Exemplo:

Procedimento: Na página Logtail Configuration, na área Processor Configurations, ative Multi-line Mode.

• Type: Selecione Custom ou Multi-line JSON.

  • Custom: Se o formato do log bruto não for fixo, configure uma Regex to Match First Line para identificar a linha inicial de cada entrada de log.

    • Regex to Match First Line: Gere automaticamente ou insira manualmente. A expressão deve corresponder a uma linha inteira de dados. No exemplo acima, a expressão regular correspondente é \[\d+-\d+-\w+:\d+:\d+,\d+]\s\[\w+]\s.*.

      • Geração automática: Clique em Auto-generate Regular Expression. Na caixa de texto Log Sample, selecione o conteúdo do log a ser extraído e clique em Generate Regex.

      • Entrada manual: Clique em Manually Enter Regular Expression. Após inserir a expressão, clique em Validate.

  • Multi-line JSON: Selecione esta opção quando os logs brutos estiverem no formato JSON padrão. O LoongCollector lida automaticamente com quebras de linha dentro de entradas JSON únicas.

  • Processing Method If Splitting Fails:

    • Discard: Se um segmento de texto não corresponder à expressão regular da primeira linha, ele será descartado.

    • Retain Single Line: O texto não correspondido é dividido e retido conforme o modo original de linha única.

  Caso de uso 2: Estruturar logs

  Quando os logs brutos são texto não estruturado (por exemplo, logs de acesso do Nginx), a consulta direta torna-se ineficiente. O LoongCollector oferece plugins de análise que convertem logs brutos em pares chave-valor estruturados para análise, monitoramento e alertas.

  Exemplo:

  Log bruto não processado	Log após análise estruturada
  192.168.*.* - - [15/Apr/2025:16:40:00 +0800] "GET /nginx-logo.png HTTP/1.1" 0.000 514 200 368 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.*.* Safari/537.36"	body_bytes_sent: 368 http_referer: - http_user_agent : Mozi11a/5.0 (Nindows NT 10.0; Win64; x64) AppleMebKit/537.36 (KHTML, like Gecko) Chrome/131.0.x.x Safari/537.36 remote_addr:192.168.*.* remote_user: - request_length: 514 request_method: GET request_time: 0.000 request_uri: /nginx-logo.png status: 200 time_local: 15/Apr/2025:16:40:00

  Procedimento: Na área Processor Configurations da página Logtail Configuration:

  1. Adicionar um plugin de análise: Clique em Add Processor e configure um plugin de análise regex, delimitador ou JSON com base no formato do seu log. Para este exemplo NGINX, selecione Native Processor > Data Parsing (NGINX Mode).

  2. NGINX Log Configuration: Copie toda a definição log_format do arquivo de configuração do seu servidor Nginx (nginx.conf) e cole-a nesta caixa de texto.

     Exemplo:

     * | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')

     Importante

     A definição de formato aqui deve corresponder exatamente ao formato que gera os logs no servidor; caso contrário, a análise falhará.

  3. Parâmetros comuns: Os parâmetros a seguir são comuns a vários plugins de análise de dados e funcionam da mesma maneira.

     • Original field: Especifica o campo de origem a ser analisado. O padrão é content, que representa toda a entrada de log coletada.

     • Keep original field on failure: Recomendado. Se a análise de um log falhar (por exemplo, devido a incompatibilidade de formato), esta opção retém o conteúdo original do log no campo original especificado.

     • Keep original field on success: Quando selecionado, o conteúdo original do log é retido mesmo após uma análise bem-sucedida.

  3. Filtragem de logs

  Coletar logs irrelevantes ou de baixo valor, como os de nível DEBUG ou INFO, desperdiça armazenamento, aumenta custos, prejudica o desempenho das consultas e pode introduzir riscos de segurança. Implemente políticas de filtragem granulares para garantir uma coleta de logs eficiente e segura.

  Filtragem de conteúdo

  Filtre logs com base no conteúdo dos campos, por exemplo, coletando apenas logs onde o nível seja WARNING ou ERROR.

  Exemplo:

  Logs brutos não processados

  Coletar apenas logs WARNING ou ERROR

  {"level":"WARNING","timestamp":"2025-09-23T19:11:40+0800","cluster":"yilu-cluster-0728","message":"Disk space is running low","freeSpace":"15%"} {"level":"ERROR","timestamp":"2025-09-23T19:11:42+0800","cluster":"yilu-cluster-0728","message":"Failed to connect to database","errorCode":5003} {"level":"INFO","timestamp":"2025-09-23T19:11:47+0800","cluster":"yilu-cluster-0728","message":"User logged in successfully","userId":"user-123"}

  {"level":"WARNING","timestamp":"2025-09-23T19:11:40+0800","cluster":"yilu-cluster-0728","message":"Disk space is running low","freeSpace":"15%"} {"level":"ERROR","timestamp":"2025-09-23T19:11:42+0800","cluster":"yilu-cluster-0728","message":"Failed to connect to database","errorCode":5003}

  Procedimento: Na área Processor Configurations da página Logtail Configuration:

  Clique em Add Processor e selecione Native Processor > Data Filtering.

  • Field Name: O campo do log a ser filtrado.

  • Field Value: A expressão regular para filtragem. Apenas correspondência de texto completo é suportada; correspondência parcial de palavras-chave não é permitida.

  Lista de bloqueios de coleta

  Utilize uma lista de bloqueios para excluir diretórios ou arquivos específicos, evitando o upload de logs irrelevantes ou sensíveis.

  Procedimento: Na página Logtail Configuration, acesse a área Input Configurations > Other Input Configurations, ative Collection Blacklist e clique em Add.

  Suporta correspondência exata e com caracteres curinga para diretórios e nomes de arquivos. Os únicos caracteres curinga suportados são o asterisco (*) e o ponto de interrogação (?).

  • File Path Blacklist: Os caminhos de arquivo a serem ignorados. Exemplos:

    • /home/admin/private*.log: Ignora todos os arquivos no diretório /home/admin/ que começam com "private" e terminam com ".log".

    • /home/admin/private*/*_inner.log: Ignora arquivos terminados em "_inner.log" localizados em subdiretórios que começam com "private" sob o diretório /home/admin/.

  • File Blacklist: Os nomes de arquivos a serem ignorados durante a coleta. Exemplo:

    • app_inner.log: Ignora todos os arquivos chamados app_inner.log.

  • Directory Blacklist: O caminho do diretório não pode terminar com uma barra (/). Exemplos:

    • /home/admin/dir1/: A lista de bloqueios de diretório não terá efeito.

    • /home/admin/dir*: Ignora todos os arquivos dentro de subdiretórios de /home/admin/ que começam com "dir".

    • /home/admin/*/dir: Ignora todos os arquivos em qualquer subdiretório de segundo nível chamado "dir" sob /home/admin/. Por exemplo, arquivos em /home/admin/a/dir são ignorados, mas arquivos em /home/admin/a/b/dir são coletados.

  Filtragem de contêineres

  Defina condições de coleta com base em metadados do contêiner — como variáveis de ambiente, rótulos de Pod, namespaces e nomes de contêineres — para controlar precisamente quais logs de contêineres são coletados.

  Procedimento: Na área Input Configurations da página Logtail Configuration, ative Container Filtering e clique em Add.

  Múltiplas condições são combinadas com um "E" lógico. Toda correspondência de expressão regular baseia-se no mecanismo RE2 do Go, que possui limitações em comparação com mecanismos como PCRE. Certifique-se de que suas expressões estejam em conformidade com o Apêndice: Limites de uso de expressões regulares (Filtragem de contêineres) .

  • Lista de bloqueios/permissões de variáveis de ambiente: Filtra contêineres com base em suas variáveis de ambiente.

  • Lista de bloqueios/permissões de rótulos de Pod K8s: Filtra Pods com base em seus rótulos.

  • Correspondência regex de nome de Pod K8s: Coleta logs de Pods cujos nomes correspondem à expressão regular especificada.

  • Correspondência regex de namespace K8s: Seleciona contêineres para coleta com base no nome do namespace.

  • Correspondência regex de nome de contêiner K8s: Coleta logs de contêineres cujos nomes correspondem à expressão regular especificada.

  • Lista de bloqueios/permissões de rótulos de contêiner: Coleta logs de contêineres com rótulos correspondentes. Destinado a cenários Docker e não recomendado para cenários K8s.

  4. Categorização de logs

  Em cenários onde múltiplas aplicações compartilham um formato de log, distinguir a origem torna-se difícil. Configure tópicos e tags de log para permitir associação automática de contexto e categorização lógica.

  Tópicos de log

  Quando várias aplicações ou instâncias compartilham um formato de log, mas possuem caminhos diferentes (por exemplo, /apps/app-A/run.log e /apps/app-B/run.log), distinguir a origem é difícil. Para resolver isso, gere um tópico de log com base no grupo de máquinas, em um nome personalizado ou na extração do caminho do arquivo para diferenciar logs de diversas fontes comerciais ou de caminho.

  Procedimento: Acesse Global Configurations > Other Global Configurations > Log Topic Type e selecione um método de geração de tópico entre as três opções a seguir:

  • Tópico de grupo de máquinas: Quando uma configuração de coleta é aplicada a vários grupos de máquinas, o LoongCollector usa automaticamente o nome do grupo de máquinas como valor do campo __topic__. Adequado para cenários onde os logs são categorizados por cluster de hosts.

  • Custom: O formato é customized://<custom_topic_name>, por exemplo, customized://app-login. Ideal para cenários de tópicos estáticos com identificadores de negócio fixos.

  • Extração de caminho de arquivo: Extrai informações-chave do caminho completo do arquivo de log para marcar dinamicamente a origem do log. Útil quando múltiplos usuários ou aplicações compartilham o mesmo nome de arquivo de log, mas possuem caminhos diferentes.

    Quando vários usuários ou serviços gravam logs em diretórios de nível superior diferentes com subcaminhos e nomes de arquivo idênticos, a origem não pode ser distinguida apenas pelo nome do arquivo. Por exemplo:

    * | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')

    Nesse caso, configure a extração de caminho de arquivo e use uma expressão regular para extrair informações-chave do caminho completo. O resultado correspondente é então enviado ao Logstore como o tópico do log.

    Regra de extração: Grupos de captura regex

    Ao configurar uma expressão regular, o sistema determina automaticamente o formato do campo de saída com base no número e na nomenclatura dos grupos de captura, conforme descrito abaixo:

    Na expressão regular para um caminho de arquivo, as barras (/) devem ser escapadas.

    Tipo de grupo de captura	Caso de uso	Campo gerado	Exemplo de regex	Exemplo de caminho	Campo gerado
    Grupo de captura único (um (.*?))	Uma única dimensão é necessária para distinguir origens (ex.: nome de usuário, ambiente).	Gera um campo __topic__.	\/logs\/(.*?)\/app\.log	/logs/userA/app.log	__topic__:userA
    Múltiplos grupos de captura sem nome (vários (.*?))	Múltiplas dimensões são necessárias, mas sem rótulos semânticos.	Gera campos Tag formatados como __tag__:__topic_{i}__:value, onde {i} é o índice do grupo de captura.	\/logs\/(.*?)\/(.*?)\/app\.log	/logs/userA/svcA/app.log	__tag__:__topic_1__:userA; __tag__:__topic_2__:svcA
    Múltiplos grupos de captura nomeados (usando (?P<name>.*?))	Múltiplas dimensões são necessárias com nomes de campos semânticos claros para facilitar consultas e análises.	Gera campos Tag formatados como __tag__:{name}:value.	\/logs\/(?P<user>.*?)\/(?P<service>.*?)\/app\.log	/logs/userA/svcA/app.log	__tag__:user:userA; __tag__:service:svcA

  Marcação de logs

  Ative o recurso de enriquecimento de tags de log para extrair informações-chave de variáveis de ambiente do contêiner ou rótulos de Pod do Kubernetes e anexá-las como Tags para agrupamento granular de logs.

  Procedimento: Na página Logtail Configuration, na área Input Configurations, ative Log Tag Enrichment e clique em Add.

  • Environment Variables: Configure um nome de variável de ambiente e uma chave de Tag. O valor da variável de ambiente será armazenado como o valor da Tag.

    • Nome da variável de ambiente: O nome da variável de ambiente a ser extraída.

    • Chave da Tag: A chave para a nova Tag.

  • Pod Labels: Configure uma chave de rótulo de Pod e uma chave de Tag. O valor do rótulo do Pod será armazenado como o valor da Tag.

    • Chave do rótulo do Pod: A chave do rótulo do Pod Kubernetes a ser extraída.

    • Chave da Tag: A chave para a nova Tag.

  5. Configuração de saída

  Por padrão, todos os logs são enviados para o Logstore atual com compressão lz4. Para distribuir logs da mesma origem para diferentes Logstores, siga as etapas abaixo.

  Distribuição dinâmica para múltiplos destinos

  Importante

  • A distribuição dinâmica para múltiplos destinos está disponível apenas para LoongCollector 3.0.0 e versões posteriores. Este recurso não é suportado pelo Logtail.

  • É possível configurar no máximo cinco destinos de saída.

  • Após configurar múltiplos destinos de saída, esta configuração de coleta deixará de aparecer na lista de configurações de coleta do Logstore atual. Para visualizar, modificar ou excluir a configuração, consulte Como gerenciar configurações de distribuição para múltiplos destinos?.

  Procedimento: Na página Logtail Configuration, na área Output Configurations:

  1. Clique em para expandir a configuração de saída.

  2. Clique em Add Output Targets e conclua a seguinte configuração:

     • Logstores: Selecione o Logstore de destino.

     • Compression Method: Suporta lz4 e zstd.

     • Route Settings: Roteie logs com base em campos Tag. Logs que correspondem à configuração de roteamento são enviados para o Logstore de destino. Se deixado em branco, todos os logs coletados serão enviados para o Logstore de destino.

       • Tag Name: A chave da Tag usada para roteamento. Insira a chave diretamente (ex.: __path__) sem o prefixo __tag__:. Os campos Tag dividem-se em duas categorias:

         As Tags são explicadas em Gerenciar Tags de Coleta do LoongCollector .

         • Relacionadas ao agente: Geradas pelo agente de coleta e independentes de quaisquer plugins. Exemplos incluem __hostname__ e __user_defined_id__.

         • Relacionadas ao plugin de entrada: Fornecidas e enriquecidas pelos plugins de entrada. Exemplos incluem __path__ da coleta de arquivos e _pod_name_ ou _container_name_ da coleta K8s.

       • Tag Value: Logs cujo valor de Tag corresponde a esta configuração são enviados para o Logstore de destino.

       • Discard this tag?: Se ativado, este campo Tag não será incluído nos logs enviados.

  Etapa 4: Consulta e análise

  Após configurar o processamento de logs e os plugins, clique em Next para prosseguir para a página Query and Analysis Configurations:

  • Por padrão, o sistema ativa o índice de texto completo, que permite pesquisar o conteúdo bruto do log por palavra-chave.

  • Para consultar dados por campos específicos, clique em Automatic Index Generation após o carregamento dos dados em Preview Data. O Log Service gera um índice de campo com base na primeira entrada de log dos dados de visualização.

  Após concluir a configuração, clique em Next para finalizar o processo de coleta.

  Etapa 5: Validar e solucionar problemas

  Após criar e aplicar uma configuração de coleta a um grupo de máquinas, o sistema a implanta automaticamente e inicia a coleta de logs incrementais.

  Visualizar logs coletados

  1. Confirme se o arquivo de log tem novo conteúdo: O LoongCollector coleta apenas logs incrementais. Execute tail -f /path/to/your/log/file e acione operações de negócio para garantir que novos logs estejam sendo gravados.

  2. Pesquise logs: Acesse a página Search & Analyze do Logstore de destino. Clique em Search & Analyze. O intervalo de tempo padrão corresponde aos últimos 15 minutos. Verifique se novos logs foram ingeridos. Cada log de texto de contêiner coletado inclui os seguintes campos por padrão:

     Parâmetro	Descrição
     __tag__:__hostname__	Nome do host do contêiner.
     __tag__:__path__	Caminho do arquivo de log dentro do contêiner.
     __tag__:_container_ip_	Endereço IP do contêiner.
     __tag__:_image_name_	Nome da imagem utilizada pelo contêiner.
     __tag__:_pod_name_	Nome do Pod.
     __tag__:_namespace_	Namespace do Pod.
     __tag__:_pod_uid_	Identificador exclusivo (UID) do Pod.

  Consultar os nós históricos de um Pod

  Caso um Pod tenha sido movido ou reiniciado, consulte os logs de eventos do Kubernetes do seu cluster ACK no Simple Log Service para identificar os nós onde o Pod foi executado anteriormente.

  1. Faça login no console do Simple Log Service e localize o projeto k8s-log-{cluster_id} na lista de projetos.

  2. Clique no LogStore k8s-event para acessar a página de consulta e análise.

  3. Na caixa de pesquisa, insira uma instrução de consulta que filtre pelo nome do Pod, por exemplo, pod_name: my-pod e clique em Search & Analyze.

  4. Nos resultados retornados, verifique o valor do campo hostname. Esse valor corresponde ao nome do host do nó onde o Pod foi executado.

  Nota

  No LogStore k8s-event, os nomes dos campos são pod_name e hostname, sem o prefixo __tag__:. O formato com o prefixo __tag__: aplica-se à coleta de stdout e logs de texto de contêineres, mas não aos logs de eventos do Kubernetes.

  Solucionar problemas comuns

  Falha no heartbeat do grupo de máquinas

  1. Verifique o identificador de usuário: Se o servidor não for uma instância ECS, ou se a instância ECS e o Projeto pertencerem a contas Alibaba Cloud diferentes, garanta que o identificador de usuário correto exista no diretório especificado.

     • No Linux, execute o comando cd /etc/ilogtail/users/ && touch <uid> para criar um arquivo de identificador de usuário.

     • Windows: Acesse o diretório C:\LogtailData\users\ e crie um arquivo vazio chamado <uid>.

     O identificador de usuário estará configurado corretamente se o caminho especificado contiver um arquivo cujo nome seja o ID da conta Alibaba Cloud do Projeto atual.

  2. Verifique o identificador do grupo de máquinas: Se você utilizar um identificador personalizado para um grupo de máquinas, confirme se o arquivo user_defined_id existe no diretório especificado. Caso exista, verifique se o conteúdo corresponde ao identificador personalizado configurado para o grupo de máquinas.

     • Linux:

       * | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')

     • Windows: No diretório C:\LogtailData, crie um arquivo chamado user_defined_id e grave o identificador personalizado nele. (Se o diretório não existir, crie-o manualmente.)

  3. Se o identificador de usuário e o identificador do grupo de máquinas estiverem configurados corretamente, consulte Solução de problemas de grupos de máquinas do LoongCollector (Logtail) para obter mais orientações sobre solução de problemas.

  Erros de coleta de logs ou erros de formato

  Esse problema geralmente ocorre quando a conexão de rede e a configuração básica estão corretas, mas o conteúdo do log não corresponde às regras de análise. Para diagnosticar o problema, visualize a mensagem de erro específica:

  1. Na página Logtail Configuration, clique no nome da configuração do LoongCollector (Logtail) que apresenta erros de coleta. Na aba Log Collection Error, clique em Select Time Range para definir o período da consulta.

  2. Na seção , visualize o tipo de alerta do log de erro e consulte Tipos comuns de erros na coleta de dados para encontrar a solução correspondente.

  Próximas etapas

  1. Consulta e análise de logs:

  2. Visualização de dados: Utilize painéis de visualização para monitorar tendências de métricas principais.

  3. Alertas de anomalias de dados: Configure políticas de alerta para detectar anomalias nos dados em tempo real.

  Solução de problemas na coleta de logs de contêineres

  1. Verifique se novos logs estão sendo gerados no arquivo de log de destino. O Logtail não coleta dados até que novos logs apareçam.

  2. Verificar os logs de execução do Logtail

  1. Faça login no contêiner do Logtail:

     1. Consulte o pod do Logtail.

        * | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')

        A saída será semelhante à seguinte:

        * | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')

     2. Faça login no pod.

        * | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')

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

  2. Verifique os logs de execução do Logtail:

     Os logs do Logtail ficam armazenados no diretório /usr/local/ilogtail/ dentro do contêiner do Logtail. Os nomes dos arquivos são ilogtail.LOG e logtail_plugin.LOG. Faça login no contêiner do Logtail e execute os comandos abaixo para visualizar os logs:

     * | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')

     Verifique nos logs de erro o tipo de alerta e encontre a solução correspondente em Erros comuns na coleta de dados do Simple Log Service.

  3. Verificar o heartbeat do grupo de máquinas

  Acesse a página Resource Group > Machine Groups e clique no nome do grupo de máquinas de destino. Na seção Machine Group Configurations > Machine Group Status, visualize o status de Heartbeat e anote a quantidade de nós com status "OK".

  1. Verifique a quantidade de nós de trabalho no cluster de contêineres.

     1. Conectar-se a um cluster ACK usando kubectl.

     2. Verifique a quantidade de nós de trabalho no cluster.

        * | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')

        A saída será semelhante à seguinte:

        * | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')

  2. Compare a quantidade de nós com status de heartbeat OK com a quantidade de nós de trabalho no cluster de contêineres. Em seguida, siga as etapas de solução de problemas adequadas com base no resultado.

     • O status de heartbeat de todos os nós no grupo de máquinas está Failed:

       • Para clusters autogerenciados, verifique se os parâmetros {regionId}, {aliuid}, {access-key-id} e {access-key-secret} estão corretos.

         Se estiverem incorretos, execute o comando helm del --purge alibaba-log-controller para excluir o pacote de instalação e reinstale-o.

     • A quantidade de nós com status de heartbeat OK é menor que a quantidade de nós de trabalho no cluster.

       • Verifique se um DaemonSet foi implantado manualmente usando um arquivo YAML.

         1. Execute o comando a seguir. Se houver retorno, isso indica que um DaemonSet foi implantado manualmente antes usando um arquivo YAML.

            * | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')

         2. Baixe a versão mais recente do modelo de DaemonSet.

         3. Configure parâmetros como ${your_region_name}, ${your_aliyun_user_id} e ${your_machine_group_name} com seus valores reais.

         4. Atualize o recurso.

            * | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')

  4. Verificar filtros de coleta

  No console SLS, verifique a configuração de coleta do Logtail. Confirme se as definições IncludeLabel, ExcludeLabel, IncludeEnv e ExcludeEnv na configuração do Logtail atendem aos seus requisitos de coleta.

  • Neste contexto, "label" refere-se ao rótulo do contêiner obtido na saída do inspect do Docker, e não a um rótulo do Kubernetes.

  • Para testar seus filtros, remova temporariamente as configurações IncludeLabel, ExcludeLabel, IncludeEnv e ExcludeEnv e verifique se os logs são coletados. Caso sejam, sua configuração de filtro está incorreta.

  Perguntas frequentes

  Gerenciar configurações de distribuição para múltiplos destinos

  Como as configurações de distribuição para múltiplos destinos se aplicam a vários logstores, gerencie-as a partir da página de gerenciamento no nível do Projeto:

  1. Faça login no console do Simple Log Service e clique no nome do Projeto de destino.

  2. Na página do Projeto, no painel de navegação à esquerda, clique em Resource Group > Configurations.

     Nota

     Esta página gerencia todas as configurações de coleta dentro do Projeto, incluindo configurações de logstores que tenham sido excluídos acidentalmente.

  Enviar logs do ACK para um Projeto entre contas

  É possível enviar logs de contêineres para um Projeto do Simple Log Service (SLS) em outra conta Alibaba Cloud instalando manualmente o componente LoongCollector (Logtail) no cluster ACK e configurando-o com o ID da conta Alibaba Cloud de destino ou com uma credencial de acesso (AccessKey).

  Descrição do cenário: Se você precisar coletar dados de log no Projeto SLS de outra conta por motivos organizacionais, de permissão ou monitoramento, instale o LoongCollector (Logtail) manualmente para habilitar a coleta entre contas.

  Procedimento: Siga estas etapas para instalar o LoongCollector manualmente. Para obter informações sobre como instalar o Logtail, consulte Instalar e configurar o Logtail.

  1. Conecte-se ao cluster Kubernetes e execute o comando apropriado para sua região:

     Regiões da China

     * | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')

     Regiões fora da China

     * | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')

  2. Acesse o diretório loongcollector-custom-k8s-package e modifique o arquivo de configuração ./loongcollector/values.yaml.

     * | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')

  3. No diretório loongcollector-custom-k8s-package, execute o comando a seguir para instalar o LoongCollector e suas dependências:

     * | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')

  4. Após concluir a instalação, verifique se os componentes estão em execução.

     Se um pod falhar ao iniciar, verifique as configurações no arquivo values.yaml e garanta que as imagens necessárias foram baixadas.

     * | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')

     O Simple Log Service também cria automaticamente os recursos listados abaixo. Você pode visualizá-los no console do Simple Log Service.

     Tipo de recurso	Nome do recurso	Descrição
     Projeto	O valor de projectName especificado no arquivo values.yaml	Isola logs de diferentes serviços. Para um gerenciamento flexível de logs, Crie um Projeto.
     Grupo de máquinas	k8s-group-${cluster_id}	Conjunto de nós de coleta de logs. Os endereços IP dos nós do Kubernetes mudam dinamicamente conforme o cluster escala horizontalmente, portanto, identificar um grupo de máquinas por endereço IP pode causar falhas de heartbeat. Por isso, grupos de máquinas em cenários Kubernetes utilizam um identificador personalizado. Para mais informações, consulte Guia para associar grupos de máquinas a configurações de coleta.

     Importante

     O componente LoongCollector não cria um logstore chamado config-operation-log. Se esse logstore já existir, o LoongCollector não gravará logs nele.

  Usar múltiplas configurações para a mesma origem

  Por padrão, para evitar duplicação de dados, o Simple Log Service (SLS) permite que apenas uma configuração de coleta colete logs de cada origem:

  • Um arquivo de log de texto pode corresponder a apenas uma configuração de coleta do Logtail.

  • Saída padrão (stdout) de um contêiner:

    • Se você usar a nova versão do modelo de saída padrão, o stdout poderá ser coletado por apenas uma configuração de coleta de saída padrão por padrão.

    • Se você usar a versão antiga do modelo de saída padrão, nenhuma configuração extra será necessária e múltiplas coletas serão suportadas por padrão.

  1. Faça login no console do Simple Log Service e acesse o Projeto de destino.

  2. No painel de navegação à esquerda, escolha Logstores e localize o logstore de destino.

  3. Clique no ícone ao lado do nome para expandir o logstore.

  4. Clique em Logtail Configuration. Na lista de configurações, localize a configuração do Logtail desejada e clique em Manage Logtail Configuration na coluna Actions.

  5. Na página de configuração do Logtail, clique em Edit e role até a seção Input Configurations:

     • Para coletar logs de arquivos de texto, ative Allow File to Be Collected for Multiple Times.

     • Para coletar a saída padrão de contêineres, ative Allow Collection by Different Logtail Configurations.

  Erro de dependência ao desinstalar o loongcollector

  Problema: Ao tentar desinstalar o componente loongcollector (logtail-ds) no Container Service for Kubernetes (ACK), você recebe um erro informando que as dependências do componente não foram atendidas.

  Dependencies of addons are not met: terway-eniip depends on logtail-ds(>0.0) whose version is v3.x.x.x-aliyun or will be v3.x.x.x-aliyun.

  Causa: O plugin de rede terway-eniip tem a coleta de logs ativada, o que cria uma dependência do componente loongcollector (logtail-ds). Portanto, o ACK não permite desinstalar o loongcollector (logtail-ds) até que essa dependência seja removida.

  Solução: Siga estas etapas para remover a dependência e, em seguida, desinstalar o componente:

  1. Faça login no console do ACK.

  2. Na lista de clusters, clique no nome do cluster de destino para acessar sua página de detalhes.

  3. No painel de navegação à esquerda, clique em Add-ons.

  4. Na lista de add-ons, pesquise pelo componente terway-eniip e clique em .

  5. Na caixa de diálogo exibida, clique em OK.

  6. Depois que a configuração entrar em vigor, tente desinstalar o componente loongcollector (logtail-ds) novamente.

  Última entrada de log atrasada ou truncada

  Causa: O truncamento de logs geralmente ocorre quando falta uma quebra de linha final no arquivo de log ou quando uma entrada de log multilinha, como uma pilha de exceções, não foi totalmente gravada. Como o coletor não consegue determinar se a entrada de log está completa, a última entrada pode ser dividida ou atrasada. A forma como isso é tratado depende da versão do seu LoongCollector (Logtail):

  • Versões anteriores à 1.8: Se a última linha de um log não tiver uma quebra de linha (retorno de carro) ou se um bloco de log multilinha estiver incompleto, o coletor aguarda a próxima operação de gravação para acionar uma saída. Isso pode atrasar significativamente a última entrada de log até que um novo log seja gravado.

  • Versão 1.8 e posteriores: Essas versões introduzem um mecanismo de flush por tempo limite para evitar que logs fiquem presos. Quando uma linha de log incompleta é detectada, o sistema inicia um temporizador. Após o término do período de tempo limite, o conteúdo atual é enviado automaticamente para garantir que o log seja eventualmente coletado.

    • Tempo limite padrão: 60 segundos (garante a integridade dos dados na maioria dos cenários)

    • Você pode ajustar esse valor conforme suas necessidades. No entanto, recomendamos que não o defina como 0, pois isso pode causar truncamento de logs ou perda parcial de dados.

  Solução:

  Você pode estender o tempo de espera para garantir que uma entrada de log completa seja gravada antes de ser coletada:

  1. Faça login no console do Simple Log Service e acesse o Projeto de destino.

  2. No painel de navegação à esquerda, escolha Logstores e localize o logstore de destino.

  3. Clique no ícone ao lado do nome para expandir o logstore.

  4. Clique em Logtail Configuration. Na lista de configurações, localize a configuração do Logtail desejada e clique em Manage Logtail Configuration na coluna Actions.

  5. Na página de configuração do Logtail, clique em Edit.

     • Acesse Input Configurations > Other Input Configurations > Advanced Parameters e adicione a seguinte configuração JSON para personalizar o período de tempo limite.

       * | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')

       • Valor padrão: Determinado pelo parâmetro de inicialização default_reader_flush_timeout, que geralmente é de alguns segundos.

       • Unidade: Segundos.

       • Valor recomendado: ≥ 1 segundo. Recomendamos que não defina como 0, pois isso pode causar truncamento de logs ou perda parcial de dados.

  6. Após concluir a configuração, clique em OK.

  Failover e recuperação de rede do LoongCollector

  Se o LoongCollector (Logtail) detectar um problema de conectividade de rede interna, como falha ou tempo limite, ele alternará automaticamente para a rede pública. Esse mecanismo de failover garante uma coleta de logs confiável e evita acúmulos ou perda de dados.

  • LoongCollector: Alterna automaticamente de volta para a rede interna após a recuperação da rede.

  • Logtail: Não alterna automaticamente de volta. É necessário reiniciá-lo para restaurar a comunicação pela rede interna.

  Apêndice: Processadores nativos

  Na página Logtail Configuration, na área Processor Configurations, adicione plug-ins de processamento para estruturar logs brutos. Para adicionar um plug-in de processamento a uma configuração de coleta existente, siga estas etapas:

  1. No painel de navegação à esquerda, escolha Logstores e localize o Logstore de destino.

  2. Clique em à esquerda do nome para expandir o Logstore.

  3. Clique em Logtail Configuration. Na lista de configurações, encontre a configuração do Logtail desejada e clique em Manage Logtail Configuration.

  4. Na página de configuração do Logtail, clique em Edit.

  Esta seção apresenta apenas os plug-ins de processamento mais utilizados, que cobrem cenários comuns de processamento de logs. Para conhecer mais recursos, consulte Plug-ins de processamento de extensão .

  Importante

  Regras para combinação de plug-ins (aplica-se ao LoongCollector / Logtail 2.0 e versões posteriores):

  • Os plug-ins de processamento nativos e de extensão podem ser usados de forma independente ou combinados, conforme necessário.

  • Recomendamos o uso prioritário dos plug-ins de processamento nativos, pois oferecem melhor desempenho e maior estabilidade.

  • Quando os recursos nativos não atenderem aos requisitos do negócio, adicione plug-ins de processamento de extensão após os nativos já configurados para realizar um processamento complementar.

  Restrição de ordem:

  Todos os plug-ins são executados sequencialmente na ordem em que foram configurados, formando uma cadeia de processamento. Observação: Todos os plug-ins de processamento nativos devem preceder quaisquer plug-ins de processamento de extensão. Após adicionar qualquer plug-in de processamento de extensão, não é possível adicionar mais plug-ins de processamento nativos.

  Análise com expressão regular

  Este processador utiliza uma expressão regular para analisar logs e convertê-los em pares chave-valor. Em seguida, consulte e analise cada campo extraído de forma independente.

  Exemplo:

  Log bruto

  Resultado da análise

  127.0.0.1 - - [16/Aug/2024:14:37:52 +0800] "GET /wp-admin/admin-ajax.php?action=rest-nonce HTTP/1.1" 200 41 "http://www.example.com/wp-admin/post-new.php?post_type=page" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36 Edg/127.0.0.0"

  body_bytes_sent: 41 http_referer: http://www.example.com/wp-admin/post-new.php?post_type=page http_user_agent: Mozilla/5.0 (Windows NT 10.0; Win64; ×64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36 Edg/127.0.0.0 remote_addr: 127.0.0.1 remote_user: - request_method: GET request_protocol: HTTP/1.1 request_uri: /wp-admin/admin-ajax.php?action=rest-nonce status: 200 time_local: 16/Aug/2024:14:37:52 +0800

  Etapas: Na página Logtail Configuration, na área Processor Configurations, clique em Add Processor e selecione Native Processor > Data Parsing (Regex Mode):

  • Regular Expression: Corresponde às entradas de log. Gere-a automaticamente ou insira-a manualmente.

    • Para gerar uma expressão regular automaticamente:

      • Clique em Generate Regular Expression.

      • Na caixa Log Sample, destaque o conteúdo a ser extraído.

      • Clique em Generate.

        

    • Insira manualmente uma expressão regular com base no formato do seu log.

    Após configurar a expressão, clique em Validate para testar se ela analisa corretamente sua amostra de log.

  • Extracted Field: Atribua um nome (chave) ao conteúdo extraído (valor).

  • Para obter informações sobre outros parâmetros, consulte a descrição dos parâmetros de configuração comuns em Cenário 2: Logs estruturados.

  Análise com delimitador

  Este processador usa um delimitador para converter logs em pares chave-valor. É possível utilizar delimitadores de caractere único ou múltiplo.

  Exemplo:

  Log bruto	Usando um caractere especificado, dividir um campo
  05/May/2025:13:30:28,10.10.*.*,"POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=****************&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=******************************** HTTP/1.1",200,18204,aliyun-sdk-java	ip:10.10.*.* request:POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=****************&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=******************************** HTTP/1.1 size:18204 status:200 time:05/May/2025:13:30:28 user_agent:aliyun-sdk-java

  Procedimento: Na página Logtail Configuration, na área Processor Configurations, clique em Add Processor e selecione Native Processor > Data Parsing (Delimiter Mode):

  • Delimiter: O caractere que separa os campos no log.

    Exemplo: Para um arquivo CSV, selecione Custom e insira uma vírgula (,).

  • Quote: O caractere usado para envolver o valor de um campo. Isso é necessário caso o valor contenha o delimitador, evitando divisões incorretas.

  • Extracted Field: Atribua um nome de campo (Key) para cada coluna em ordem sequencial. Os nomes dos campos devem obedecer às seguintes regras:

    • Podem conter apenas letras, dígitos e sublinhados (_).

    • Devem começar com uma letra ou um sublinhado (_).

    • Comprimento máximo: 128 bytes.

  • Para obter informações sobre outros parâmetros, consulte a descrição dos parâmetros de configuração comuns em Cenário 2: Logs estruturados.

  Análise de JSON padrão

  Este processador converte uma entrada de log que seja um objeto JSON em pares chave-valor.

  Exemplo:

  Log bruto	Resultado da análise
  {"url": "POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=U0Ujpek********&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=pD12XYLmGxKQ%2Bmkd6x7hAgQ7b1c%3D HTTP/1.1", "ip": "10.200.98.220", "user-agent": "aliyun-sdk-java", "request": {"status": "200", "latency": "18204"}, "time": "05/Jan/2025:13:30:28"}	ip: 10.200.98.220 request: {"status": "200", "latency" : "18204" } time: 05/Jan/2025:13:30:28 url: POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=U0Ujpek******&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=pD12XYLmGxKQ%2Bmkd6x7hAgQ7b1c%3D HTTP/1.1 user-agent:aliyun-sdk-java

  Procedimento: Na página Logtail Configuration, na seção Processor Configurations, clique em Add Processor e selecione Native Processor > Data Parsing (JSON Mode):

  • Original Field: O valor padrão é content. Este campo armazena o conteúdo bruto do log a ser analisado.

  • Para obter informações sobre outros parâmetros, consulte a descrição dos parâmetros de configuração comuns em Cenário 2: Logs estruturados.

  Análise de JSON aninhado

  Este processador expande um objeto JSON aninhado em pares chave-valor. Controle a expansão com a configuração JSON expansion depth.

  Exemplo:

  Log bruto	Resultado (profundidade: 0)	Resultado (profundidade: 1)
  {"s_key":{"k1":{"k2":{"k3":{"k4":{"k51":"51","k52":"52"},"k41":"41"}}}}}	0_s_key_k1_k2_k3_k41:41 0_s_key_k1_k2_k3_k4_k51:51 0_s_key_k1_k2_k3_k4_k52:52	1_s_key:{"k1":{"k2":{"k3":{"k4":{"k51":"51","k52":"52"},"k41":"41"}}}}

  Procedimento: Na página Logtail Configuration, na seção Processor Configurations, clique em Add Processor e selecione Extended Processor > Expand JSON Field:

  • Original Field: O nome do campo original a ser expandido, como content.

  • JSON Expansion Depth: O número de níveis a serem expandidos dentro do objeto JSON. 0 expande todos os níveis (padrão), 1 expande apenas o nível superior, e assim por diante.

  • Character to Concatenate Expanded Keys: O caractere usado para unir chaves de objetos aninhados. O padrão é o sublinhado (_).

  • Name Prefix of Expanded Keys: Um prefixo a ser adicionado ao nome de cada chave expandida.

  • Expand Array: Ative esta opção para expandir um array em pares chave-valor indexados.

    Por exemplo, {"k":["a","b"]} é expandido para {"k[0]":"a","k[1]":"b"}.

    Para renomear um campo expandido (por exemplo, de prefix_s_key_k1 para new_field_name ), adicione um processador Rename Fields após este.

  • Para obter informações sobre outros parâmetros, consulte a descrição dos parâmetros de configuração comuns em Cenário 2: Logs estruturados.

  Análise de array JSON

  Use a função json_extract para extrair um objeto JSON de um array JSON.

  Exemplo:

  Log bruto	Resultado da análise
  [{"key1":"value1"},{"key2":"value2"}]	json1:{"key1":"value1"} json2:{"key2":"value2"}

  Procedimento: Na página Logtail Configuration, na seção Processor Configurations, defina o Processing Method como SPL. Em seguida, configure a SPL statement para usar a função json_extract e extrair objetos JSON do array JSON.

  Exemplo: Do campo de log content, extraia elementos de um array JSON e armazene os resultados respectivamente nos novos campos json1 e json2.

  * | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')

  Análise de log Apache

  Este processador analisa logs de acesso do Apache e os converte em pares chave-valor com base na diretiva LogFormat do Apache.

  Exemplo:

  Log bruto	Análise do Apache Common Log Format combined
  1 192.168.1.10 - - [08/May/2024:15:30:28 +0800] "GET /index.html HTTP/1.1" 200 1234 "https://www.example.com/referrer" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.X.X Safari/537.36"	http_referer:https://www.example.com/referrer http_user_agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.X.X Safari/537.36 remote_addr:192.168.1.10 remote_ident:- remote_user:- request_method:GET request_protocol:HTTP/1.1 request_uri:/index.html response_size_bytes:1234 status:200 time_local:[08/May/2024:15:30:28 +0800]

  Procedimento: Na página Logtail Configuration, na seção Processor Configurations, clique em Add Processor e selecione Native Processor > Data Parsing (Apache Mode):

  • Log Format: combined

  • APACHE LogFormat Configuration: O sistema preenche este campo automaticamente com base no Log Format selecionado.

    Importante

    Verifique se o conteúdo preenchido automaticamente é idêntico à diretiva LogFormat definida no arquivo de configuração do Apache do seu servidor, geralmente localizado em /etc/apache2/apache2.conf.

  • Para outros parâmetros, consulte a descrição dos parâmetros de configuração comuns em Cenário 2: Log estruturado.

  Mascaramento de dados

  Mascare dados sensíveis em seus logs.

  Exemplo:

  Log bruto	Resultado mascarado
  [{'account':'1812213231432969','password':'04a23f38'}, {'account':'1812213685634','password':'123a'}]	[{'account':'1812213231432969','password':'********'}, {'account':'1812213685634','password':'********'}]

  Procedimento: Na página Logtail Configuration, na seção Processor Configurations, clique em Add Processor e selecione Native Processor > Data Masking:

  • Original Field: O campo de origem que contém o conteúdo a ser mascarado.

  • Data Masking Method:

    • const: Substitui o conteúdo sensível por uma string especificada.

    • md5: Substitui o conteúdo sensível pelo seu valor de hash MD5.

  • Replacement String: A string a ser usada para mascaramento. Obrigatória quando o Data Masking Method estiver definido como const.

  • Content Expression that Precedes Replaced Content: Uma expressão regular na sintaxe RE2 para localizar o conteúdo imediatamente anterior aos dados sensíveis.

  • Content Expression to Match Replaced Content: Uma expressão regular na sintaxe RE2 para corresponder aos dados sensíveis que você deseja substituir.

  Análise de tempo

  Analisa o campo de tempo no log e define o resultado analisado como o campo __time__ do log.

  Exemplo:

  Log bruto	Resultado da análise
  {"level":"INFO","timestamp":"2025-09-23T19:11:47+0800","cluster":"yilu-cluster-0728","message":"User logged in successfully","userId":"user-123"}

  Procedimento: Na página Logtail Configuration, na seção Processor Configurations, clique em Add Processor e selecione Native Processor > Time Parsing:

  • Original Field: O campo de origem que contém a string de tempo a ser analisada.

  • Time Format: O formato de tempo correspondente à string de tempo em seus logs.

  • Time Zone: O fuso horário do campo de tempo do log. Se não for especificado, o padrão será o fuso horário da máquina que executa o LoongCollector (Logtail).

  Apêndice: Limitações de expressões regulares (filtragem de contêineres)

  As expressões regulares para filtragem de contêineres usam o mecanismo Go RE2. Em comparação com outros mecanismos, como PCRE, o mecanismo RE2 possui várias limitações de sintaxe. Tenha em mente os pontos abaixo ao escrever expressões regulares:

  1. Diferenças na sintaxe de grupos nomeados

  O Go usa a sintaxe (?P<name>...) para definir um grupo nomeado e não oferece suporte à sintaxe (?<name>...) do PCRE.

  • Correto: (?P<year>\d{4})

  • Incorreto: (?<year>\d{4})

  2. Recursos de expressão regular não suportados

  O mecanismo RE2 não oferece suporte aos seguintes recursos comuns, porém complexos, de expressões regulares. Evite usá-los:

  • Asserções: (?=...), (?!...), (?<=...) e (?<!...)

  • Expressões condicionais: (?(condition)true|false)

  • Correspondência recursiva: (?R) e (?0)

  • Referências a subprogramas: (?&name) e (?P>name)

  • Grupos atômicos: (?>...)

  3. Recomendações

  Utilize uma ferramenta como o Regex101 para depurar suas expressões regulares. Para garantir compatibilidade, selecione o modo Golang (RE2) para validação. Caso utilize alguma sintaxe não suportada, o plug-in falhará ao analisar ou corresponder à expressão.

  Apêndice: Comparação de versões da saída padrão de contêineres

  Para melhorar a eficiência de armazenamento e a consistência da coleta, o formato de metadados de log da saída padrão de contêineres foi atualizado. O novo formato consolida os metadados sob o campo __tag__, o que otimiza o armazenamento e padroniza o formato.

  1. Principais vantagens da nova saída padrão

     • Desempenho significativamente aprimorado

       • Refatorada em C++, a nova versão oferece uma melhoria de desempenho de 180% a 300% em relação à implementação anterior em Go.

       • Oferece suporte a processamento de dados com plug-ins nativos e processamento paralelo multithread, aproveitando totalmente os recursos do sistema.

       • Permite combinações flexíveis de plug-ins nativos e plug-ins Go para atender às necessidades de cenários complexos.

     • Maior confiabilidade

       • Suporta uma fila de rotação para logs de saída padrão e unifica o mecanismo de coleta de logs com o mecanismo de coleta de arquivos, proporcionando alta confiabilidade quando os logs de saída padrão sofrem rotação rápida.

     • Menor consumo de recursos

       • O uso de CPU é reduzido em 20% a 25%.

       • O uso de memória é reduzido em 20% a 25%.

     • Consistência operacional aprimorada

       • Configuração de parâmetros unificada: Os parâmetros de configuração do novo plug-in de coleta de saída padrão são consistentes com os do plug-in de coleta de arquivos.

       • Gerenciamento de metadados unificado: A nomenclatura dos campos de metadados do contêiner e o local de armazenamento das tags são unificados com o cenário de coleta de arquivos, permitindo que o lado do consumidor mantenha apenas um conjunto de lógica de processamento.

  2. Comparação de recursos entre as versões nova e antiga

     Recurso	Versão antiga	Nova versão
     Método de armazenamento	Os metadados são incorporados ao conteúdo do log como campos regulares.	Os metadados são consolidados sob a tag __tag__.
     Eficiência de armazenamento	Cada entrada de log carrega uma cópia completa dos metadados, consumindo mais espaço de armazenamento.	Várias entradas de log no mesmo contexto podem reutilizar os metadados, economizando custos de armazenamento.
     Consistência de formato	O formato é inconsistente com o formato de coleta de arquivos de contêiner.	A nomenclatura de campos e a estrutura de armazenamento estão totalmente alinhadas com a coleta de arquivos de contêiner, proporcionando uma experiência unificada.
     Método de acesso à consulta	Consulte metadados diretamente pelo nome do campo, como _container_name_.	Acesse o par chave-valor correspondente através de __tag__, como __tag__: _container_name_.

  3. Mapeamento de campos de metadados do contêiner

     Nome do campo antigo	Novo nome do campo
     _container_ip_	__tag__:_container_ip_
     _container_name_	__tag__:_container_name_
     _image_name_	__tag__:_image_name_
     _namespace_	__tag__:_namespace_
     _pod_name_	__tag__:_pod_name_
     _pod_uid_	__tag__:_pod_uid_

     Na nova versão, todos os campos de metadados são armazenados na seção de tags do log no formato __tag__:<key>, em vez de serem incorporados ao conteúdo do log.

  4. Impacto da nova versão nos usuários

     • Adaptação do lado do consumidor: Como o local de armazenamento muda do conteúdo para a tag, ajuste sua lógica de consumo de logs adequadamente. Por exemplo, acesse os campos através de __tag__ ao executar uma consulta.

     • Compatibilidade com SQL: As consultas SQL já são automaticamente compatíveis com ambas as versões, portanto, não é necessário modificar suas instruções de consulta para processar logs de nenhuma das versões.

  Mais informações

  Parâmetros globais

  Parâmetro	Descrição
  Nome da configuração	Nome da configuração do Logtail. Deve ser único dentro do seu Project. Não é possível alterar o nome após a criação da configuração do Logtail.
  Tipo de tópico de log	Define como o tópico de log é gerado. As opções incluem Machine Group Topic, File Path Extraction e Custom.
  Parâmetros avançados	Parâmetros avançados opcionais para a configuração global. Criar uma configuração de pipeline do Logtail.

  Parâmetros de entrada

  Parâmetro	Descrição
  Modo de implantação do Logtail	DaemonSet: Implanta um LoongCollector em cada nó do cluster para coletar logs de todos os containers nesse nó. Sidecar: Cada Pod executa um container do LoongCollector para coletar logs de todos os containers dentro desse Pod. A coleta de logs para diferentes Pods é isolada.
  Tipo de caminho de arquivo	Permite configurar um Path in Container ou Host Path. Path in Container: Selecione esta opção para coletar arquivos de log de texto de dentro de um container. Host Path: Selecione esta opção para coletar logs de service dos nós do cluster.
  Caminho do arquivo	Especifica o diretório de log e o nome do arquivo com base na localização do log no host, como uma instância ECS. Se o host de destino for um sistema Linux, o caminho do log deve começar com uma barra (/). Por exemplo, /apsara/nuwa/**/app.Log. Se o host de destino for um sistema Windows, o caminho do log deve começar com uma letra de unidade. Por exemplo, C:\Program Files\Intel\**\*.Log. Tanto os nomes de diretórios quanto os de arquivos aceitam correspondência exata e curingas. Consulte Correspondência com curingas. Os únicos curingas suportados para caminhos de log são o asterisco (*) e o ponto de interrogação (?). A coleta de logs utiliza correspondência de diretórios em vários níveis. Isso significa que o Logtail encontra todos os arquivos que atendem aos critérios no diretório especificado e em todos os seus subdiretórios. Por exemplo: /apsara/nuwa/**/*.log indica arquivos com o sufixo .log no diretório /apsara/nuwa e em seus subdiretórios recursivos. /var/logs/app_*/**/.log indica arquivos com o sufixo .log em todos os diretórios que correspondem ao formato app_ sob o diretório /var/logs e em seus subdiretórios recursivos. /var/log/nginx/**/access* indica arquivos cujos nomes começam com access no diretório /var/log/nginx e em seus subdiretórios recursivos.
  Profundidade máxima de monitoramento de diretório	Define a profundidade máxima de diretório a ser monitorada. Trata-se da profundidade máxima correspondida pelo curinga ** no File Path. Um valor de 0 indica que apenas o diretório atual é monitorado.
  Saída padrão	Se você ativar Stdout and Stderr, o Logtail coletará a saída padrão do container.
  Erro padrão	Se você ativar Standard Error, o Logtail coletará o erro padrão do container.
  Permitir coleta múltipla da saída padrão	Por padrão, a saída padrão de um container pode ser coletada por apenas uma configuração do Logtail. Para coletar a saída padrão com várias configurações, ative a chave Allow File to Be Collected for Multiple Times.
  Ativar visualização de metadados do container	Ativar Enable Container Metadata Preview permite visualizar os metadados do container após criar uma configuração do Logtail. Isso inclui informações dos containers correspondentes e informações completas dos containers.
  Filtragem de containers	Condições de filtragem Importante Um rótulo de container é o rótulo presente na saída do comando docker inspect e difere de um rótulo do Kubernetes. Obter rótulos de container. Uma variável de ambiente é configurada quando um container é iniciado. Obter variáveis de ambiente do container. Em cenários Kubernetes, utilize informações de nível Kubernetes para filtragem de containers, como K8s Pod Name Regular Matching, K8s Namespace Regular Matching, K8s Container Name Regular Matching e Kubernetes Pod Label Whitelist. No Kubernetes, namespaces e nomes de containers são mapeados para os rótulos de container io.kubernetes.pod.namespace e io.kubernetes.container.name, respectivamente. Recomendamos o uso desses rótulos para filtragem de containers. Por exemplo, se um Pod pertence ao namespace backend-prod e possui um container chamado worker-server, você pode coletar logs desse container definindo a lista de permissões de rótulos de container como io.kubernetes.pod.namespace : backend-prod ou io.kubernetes.container.name : worker-server. Caso esses dois rótulos de container não atendam às suas necessidades de filtragem, utilize a lista de permissões ou a lista de bloqueios de variáveis de ambiente para filtrar os containers. K8s Pod Name Regular Matching Especifica uma expressão regular para corresponder aos nomes dos Pods. Os logs são coletados dos containers dentro dos Pods correspondentes. Por exemplo, se você definir este parâmetro como ^(nginx-log-demo.*)$, todos os containers em Pods cujos nomes começam com nginx-log-demo serão correspondidos. K8s Namespace Regular Matching Define uma expressão regular para corresponder aos namespaces. A coleta de logs ocorre nos containers dos namespaces correspondentes. Por exemplo, ao definir este parâmetro como ^(default|nginx)$, todos os containers nos namespaces nginx e default são correspondidos. K8s Container Name Regular Matching Especifica uma expressão regular para corresponder aos nomes dos containers. O nome do container Kubernetes é definido em spec.containers. Os logs são coletados dos containers que correspondem ao nome. Por exemplo, se você definir este parâmetro como ^(container-test)$, todos os containers chamados container-test serão correspondidos. Container Label Whitelist (We recommend that you configure this parameter in a Docker environment and do not configure this parameter in a Kubernetes environment.) Define de quais containers os logs serão coletados. Por padrão, este campo está vazio, o que significa que a saída padrão de todos os containers é coletada. Para definir uma lista de permissões de rótulos de container, LabelKey é obrigatório e LabelValue é opcional. Se LabelValue estiver vazio, todos os containers com o rótulo LabelKey serão correspondidos. Se LabelValue não estiver vazio, apenas os containers com um rótulo idêntico a LabelKey=LabelValue serão correspondidos. Por padrão, LabelValue é usado para correspondência de strings. A correspondência só é bem-sucedida se o LabelValue for idêntico ao valor do rótulo do container. Se o valor começar com ^ e terminar com $, a correspondência por expressão regular será utilizada. Por exemplo, se você definir LabelKey como io.kubernetes.container.name e LabelValue como ^(nginx|cube)$, os containers chamados nginx ou cube serão correspondidos. Várias entradas na lista de permissões têm uma relação lógica OR. Um container é correspondido se seu rótulo corresponder a qualquer uma das entradas da lista de permissões. Container Label Blacklist (We recommend that you configure this parameter in a Docker environment and do not configure this parameter in a Kubernetes environment.) Exclui containers da coleta de logs. Por padrão, este campo está vazio, o que significa que nenhum container é excluído. Para definir uma lista de bloqueios de rótulos de container, LabelKey é obrigatório e LabelValue é opcional. Se LabelValue estiver vazio, todos os containers com o rótulo LabelKey serão excluídos. Se LabelValue não estiver vazio, apenas os containers com um rótulo idêntico a LabelKey=LabelValue serão excluídos. LabelValue usa correspondência de strings por padrão. A correspondência ocorre apenas se o valor de LabelValue for idêntico ao valor do rótulo do container. Se o valor começar com ^ e terminar com $, uma correspondência por expressão regular será executada. Por exemplo, se você definir LabelKey como io.kubernetes.container.name e LabelValue como ^(nginx|cube)$, isso corresponderá aos containers chamados nginx ou cube. Várias entradas na lista de bloqueios têm uma relação lógica OR. Um container é excluído se seu rótulo corresponder a qualquer uma das entradas da lista de bloqueios. Environment Variable Whitelist Especifica de quais containers os logs devem ser coletados. Por padrão, este campo está vazio, significando que a saída padrão de todos os containers é coletada. Para definir uma lista de permissões de variáveis de ambiente, EnvKey é obrigatório e EnvValue é opcional. Se EnvValue estiver vazio, todos os containers com a variável de ambiente EnvKey serão correspondidos. Se EnvValue não estiver vazio, apenas os containers com uma variável de ambiente idêntica a EnvKey=EnvValue serão correspondidos. Por padrão, EnvValue é usado para correspondência de strings. A correspondência só é encontrada se o valor de EnvValue for idêntico ao valor da variável de ambiente. Se o valor começar com ^ e terminar com $, trata-se de uma correspondência por expressão regular. Por exemplo, se você definir EnvKey como NGINX_SERVICE_PORT e EnvValue como ^(80|6379)$, esta configuração corresponderá aos containers cuja porta de service seja 80 ou 6379. Múltiplas entradas na lista de permissões possuem uma relação lógica OR. Um container é correspondido se suas variáveis de ambiente corresponderem a qualquer um dos pares chave-valor especificados. Environment Variable Blacklist Exclui containers da coleta de logs. Por padrão, este campo está vazio, o que significa que nenhum container é excluído. Para definir uma lista de bloqueios de variáveis de ambiente, EnvKey é obrigatório e EnvValue é opcional. Se EnvValue estiver vazio, os logs de todos os containers com a variável de ambiente EnvKey serão excluídos. Se EnvValue não estiver vazio, apenas os containers com uma variável de ambiente idêntica a EnvKey=EnvValue serão excluídos. Por padrão, EnvValue é usado para correspondência de strings, o que significa que a correspondência só é bem-sucedida se o valor de EnvValue for idêntico ao valor da variável de ambiente. Se o valor começar com ^ e terminar com $, ele será tratado como uma expressão regular. Por exemplo, se você definir EnvKey como NGINX_SERVICE_PORT e EnvValue como ^(80|6379)$, esta configuração corresponderá aos containers que possuem uma porta de service de 80 ou 6379. Múltiplas entradas na lista de bloqueios possuem uma relação lógica OR. Um container é excluído se suas variáveis de ambiente corresponderem a qualquer um dos pares chave-valor especificados. Kubernetes Pod Label Whitelist Especifica de quais containers coletar logs usando uma lista de permissões de rótulos do Kubernetes. Para definir uma lista de permissões de rótulos do Kubernetes, LabelKey é obrigatório e LabelValue é opcional. Se LabelValue estiver vazio, todos os containers com o rótulo Kubernetes LabelKey serão correspondidos. Se LabelValue não estiver vazio, apenas os containers com um rótulo Kubernetes idêntico a LabelKey=LabelValue serão correspondidos. Por padrão, LabelValue usa correspondência de strings, o que significa que a correspondência ocorre apenas se o LabelValue for idêntico ao valor do rótulo Kubernetes. Se o valor começar com ^ e terminar com $, ele será tratado como uma expressão regular. Por exemplo, definir LabelKey como app e LabelValue como ^(test1|test2)$ corresponde aos containers que possuem o rótulo Kubernetes app:test1 ou app:test2. Múltiplas entradas na lista de permissões possuem uma relação lógica OR. Um container é correspondido se seu rótulo Kubernetes corresponder a qualquer uma das entradas da lista de permissões. Nota Se você alterar um rótulo em um controlador de recursos do Kubernetes, como um Deployment, durante a execução, o Pod em execução não será reiniciado. Consequentemente, o Pod não consegue detectar a alteração, o que pode causar falhas nas regras de correspondência. Ao configurar a lista de permissões e a lista de bloqueios de rótulos do Kubernetes, utilize os rótulos Kubernetes nos Pods. Para mais informações sobre rótulos do Kubernetes, consulte Labels and Selectors. Kubernetes Pod Label Blacklist Exclui containers da coleta de logs usando uma lista de bloqueios de rótulos do Kubernetes. Para definir uma lista de bloqueios de rótulos do Kubernetes, LabelKey é obrigatório e LabelValue é opcional. Se LabelValue estiver vazio, todos os containers com o rótulo Kubernetes LabelKey serão excluídos. Se LabelValue não estiver vazio, apenas os containers com um rótulo Kubernetes idêntico a LabelKey=LabelValue serão excluídos. Por padrão, LabelValue realiza uma correspondência exata de strings. A correspondência só é encontrada se o LabelValue for idêntico ao valor do rótulo Kubernetes. Se o valor começar com ^ e terminar com $, ele será tratado como uma expressão regular. Por exemplo, se você definir LabelKey como app e definir LabelValue como ^(test1|test2)$, isso corresponderá aos containers com os rótulos Kubernetes app:test1 ou app:test2. Múltiplas entradas na lista de bloqueios possuem uma relação lógica OR. Um container é excluído se seu rótulo Kubernetes corresponder a qualquer uma das entradas da lista de bloqueios. Nota Se você alterar um rótulo em um controlador de recursos do Kubernetes, como um Deployment, durante a execução, o Pod em execução não será reiniciado. Portanto, o Pod não consegue detectar a alteração, o que pode causar falhas nas regras de correspondência. Ao configurar a lista de permissões e a lista de bloqueios de rótulos do Kubernetes, utilize os rótulos Kubernetes nos Pods. Para mais informações sobre rótulos do Kubernetes, consulte Labels and Selectors.
  Enriquecimento de tags de log	Adiciona variáveis de ambiente e rótulos do Kubernetes aos logs como tags de log. Environment Variables Após configurar campos de extensão de variáveis de ambiente, o Log Service adiciona campos relacionados a variáveis de ambiente aos seus logs. Por exemplo, se você definir Environment Variable Name como VERSION e Tag Name como env_version, e um container tiver a variável de ambiente VERSION=v1.0.0, o campo __tag__:__env_version__: v1.0.0 será adicionado aos seus logs. Pod Labels Após configurar os campos de extensão do Pod Kubernetes, o Log Service adiciona campos relacionados ao Pod Kubernetes aos seus logs. Por exemplo, se você definir o Pod Label Name como app e o Tag Name como k8s_pod_app, o campo __tag__:__k8s_pod_app__: serviceA será adicionado aos logs de um Pod que possui o rótulo app=serviceA.
  Codificação de arquivo	Especifica o formato de codificação dos arquivos de log.
  Tamanho da primeira coleta	Quando a configuração entra em vigor pela primeira vez, este parâmetro especifica a posição inicial da coleta, medida a partir do final do arquivo. O valor padrão é 1024 KB. Na primeira coleta, se um arquivo for menor que 1024 KB, a coleta começa no início do arquivo. Na primeira coleta, se um arquivo for maior que 1024 KB, a coleta começa a 1024 KB do final do arquivo. Você pode modificar o First Collection Size. O valor, especificado em KB, pode variar de 0 a 10.485.760.
  Lista de bloqueios de coleta	Ativar a chave Collection Blacklist permite configurar uma lista de bloqueios para ignorar diretórios ou arquivos específicos durante a coleta. É possível especificar diretórios e nomes de arquivos usando correspondências exatas ou curingas. Os únicos curingas suportados são o asterisco (*) e o ponto de interrogação (?). Importante Se você usar um curinga no File Path, mas quiser filtrar alguns dos caminhos resultantes, deverá inserir os caminhos completos correspondentes na Collection Blacklist para garantir que a configuração da lista de bloqueios tenha efeito. Por exemplo, se você definir o File Path como /home/admin/app/log/.log, mas quiser excluir todos os subdiretórios no diretório /home/admin/app1, selecione Directory Blacklist e defina o diretório como /home/admin/app1/**. Se você definir o diretório como /home/admin/app1*, a lista de bloqueios não terá efeito. A correspondência da lista de bloqueios gera sobrecarga computacional. Para obter desempenho ideal, use 10 ou menos entradas na lista de bloqueios. Um caminho de diretório não pode terminar com uma barra (/). Por exemplo, se você definir o caminho como /home/admin/dir1/, a lista de bloqueios de diretório não terá efeito. É possível configurar uma lista de bloqueios por caminho de arquivo, nome de arquivo ou diretório. File Path Blacklist Selecione File Path Blacklist e defina o caminho como /home/admin/private*.log para ignorar todos os arquivos no diretório /home/admin/ que começam com private e terminam com .log durante a coleta. Selecione File Path Blacklist e defina o caminho como /home/admin/private/_inner.log para ignorar arquivos que terminam com _inner.log dentro de diretórios que começam com private sob o diretório /home/admin/. Por exemplo, o arquivo /home/admin/private/app_inner.log é ignorado, mas o arquivo /home/admin/private/app.log é coletado. Lista de bloqueios de arquivos Se você selecionar File Blacklist e definir o nome do arquivo como app_inner.log, todos os arquivos chamados app_inner.log serão ignorados durante a coleta. Lista de bloqueios de diretórios Selecione Directory Blacklist e defina o diretório como /home/admin/dir1. Isso ignora todos os arquivos no diretório /home/admin/dir1 durante a coleta. Selecione Directory Blacklist e defina o diretório como /home/admin/dir* para ignorar todos os arquivos em subdiretórios que começam com dir sob o diretório /home/admin/ durante a coleta. Selecione Directory Blacklist e defina o diretório como /home/admin/*/dir. Isso ignora todos os arquivos em qualquer subdiretório de segundo nível chamado dir sob o diretório /home/admin/ durante a coleta. Por exemplo, arquivos no diretório /home/admin/a/dir são ignorados, mas arquivos no diretório /home/admin/a/b/dir são coletados.
  Permitir coleta múltipla de arquivo	Por padrão, um arquivo de log pode ser correspondido por apenas uma configuração do Logtail. Se os logs em um arquivo precisarem ser coletados várias vezes, ative a chave Allow File to Be Collected for Multiple Times.
  Parâmetros avançados	Parâmetros avançados opcionais para o plugin de entrada de arquivo. Criar uma configuração de pipeline do Logtail.

  Parâmetros do processador

  Parâmetro	Descrição
  Amostra de log	Uma amostra do log que você deseja coletar. Utilize uma amostra de log do seu caso de uso real. A amostra ajuda a configurar os parâmetros de processamento com mais facilidade. É possível adicionar várias amostras. O comprimento total não pode exceder 1.500 caracteres. [2023-10-01T10:30:01,000] [INFO] java.lang.Exception: exception happened at TestPrintStackTrace.f(TestPrintStackTrace.java:3) at TestPrintStackTrace.g(TestPrintStackTrace.java:7) at TestPrintStackTrace.main(TestPrintStackTrace.java:16)
  Modo multilinha	Tipo de log multilinha: Um log multilinha é uma entrada que abrange várias linhas. Você deve definir uma regra para identificar o início de cada entrada de log. Custom: Usa um Regex to Match First Line para identificar cada entrada de log. Multi-line JSON: Cada objeto JSON é expandido em várias linhas. Exemplo: { "name": "John Doe", "age": 30, "address": { "city": "New York", "country": "USA" } } Ação em caso de falha na divisão: Exception in thread "main" java.lang.NullPointerException at com.example.MyClass.methodA(MyClass.java:12) at com.example.MyClass.methodB(MyClass.java:34) at com.example.MyClass.main(MyClass.java:½0) Se o Log Service falhar ao dividir o conteúdo de log anterior: Discard: Descarta este segmento de log. Retain Single Line: Mantém cada linha de texto como uma entrada de log separada, resultando em quatro entradas de log no total.
  Modo de processamento	Processors, que inclui o Native Processor e o Extended Processor. Para mais informações sobre processadores, consulte Usar processadores nativos e estendidos. Importante Para limitações de uso do processador, consulte os avisos do console. Logtail 2.0 e posterior: É possível combinar processadores nativos de qualquer maneira. É possível combinar processadores nativos e estendidos, mas todos os processadores estendidos devem seguir todos os processadores nativos. Versões do Logtail anteriores à 2.0: Não é possível usar processadores nativos e estendidos juntos. Processadores nativos só podem ser usados para coletar logs de texto. Ao usar processadores nativos, você deve atender aos seguintes requisitos: O primeiro processador deve ser um processador de análise de expressão regular, análise baseada em delimitador, análise JSON, análise de padrão Nginx, análise de padrão Apache ou análise de padrão IIS. Após o processador de análise inicial, você pode adicionar no máximo um processador de análise de tempo, um processador de filtragem e vários processadores de mascaramento de dados. Para os parâmetros Retain Original Field if Parsing Fails e Retain Original Field if Parsing Succeeds, apenas as seguintes combinações são válidas. Carregar apenas logs analisados com sucesso: Carregar logs analisados em caso de sucesso e logs brutos em caso de falha: Em caso de sucesso, carrega os logs analisados e anexa o campo de log bruto. Em caso de falha, carrega os logs brutos. Por exemplo, se o log original "content": "{"request_method":"GET", "request_time":"200"}" for analisado com sucesso, anexar o campo original adiciona um novo campo ao log analisado. O nome do campo é o campo original renomeado (se deixado em branco, o nome assume o nome do campo original por padrão), e o valor do campo é o log original {"request_method":"GET", "request_time":"200"}.