Collect container logs with the AliyunPipelineConfig CRD - Simple Log Service: Central de Documentação do Alibaba Cloud

Importante

As configurações de coleta baseadas em CRD só podem ser modificadas mediante atualização do próprio CRD. Alterações realizadas no console do SLS não são sincronizadas e não entram em vigor.

Aplicabilidade

Ambiente operacional
- Clusters ACK (edições gerenciada e dedicada) e clusters Kubernetes autogerenciados.
- A versão do Kubernetes deve ser 1.16.0 ou posterior e suportar Mount propagation: HostToContainer.
- Runtime de contêiner (apenas Docker e Containerd)
  - Docker:
    - Requer acesso ao arquivo docker.sock.
    - A coleta de saída padrão suporta apenas o driver de log JSON-file.
    - Somente os drivers de armazenamento overlay e overlay2 são suportados. Para outros tipos de drivers de armazenamento, é necessário montar manualmente os diretórios de log.
  - Containerd: Requer acesso ao arquivo containerd.sock.
Requisitos de recursos: O LoongCollector (Logtail) executa com a classe de prioridade 'system-cluster-critical'. Não realize a implantação se o cluster tiver recursos insuficientes, pois isso pode causar a evicção de Pods nos nós.
- CPU: Reserve pelo menos 0,1 núcleo.
- Memória: Reserve pelo menos 150 MB para o componente de coleta e 100 MB para o componente controlador.
- O uso real varia conforme a taxa de coleta, os diretórios e arquivos monitorados e o congestionamento de envio. Mantenha a utilização abaixo de 80% dos limites configurados.
Requisitos de permissão: Para realizar a implantação, a conta Alibaba Cloud ou o usuário RAM deve possuir a permissão AliyunLogFullAccess.

Para criar uma política personalizada, consulte a política de sistema AliyunCSManagedLogRolePolicy . Copie as permissões dessa política e conceda-as ao usuário ou função RAM de destino para configurar permissões granulares.

Fluxo de configuração de coleta

Install LoongCollector: Implante o LoongCollector como um DaemonSet para executar um contêiner de coleta em cada nó do cluster. Essa configuração centraliza a coleta de logs de todos os contêineres no nó.
Create a LogStore: Um LogStore é uma unidade de armazenamento para dados de log. É possível criar vários LogStores dentro de um Project.

Crie um arquivo YAML de configuração de coleta: Use kubectl to connect to the cluster. Há duas formas de criar o arquivo de configuração de coleta:

Método 1: Use o gerador de configuração de coleta

Utilize o gerador de configuração de coleta no console do Log Service para configurar parâmetros visualmente e gerar automaticamente um arquivo YAML padrão.
Método 2: Escreva manualmente o arquivo YAML

Escreva manualmente um arquivo YAML com base nos exemplos deste documento. Construa a configuração progressivamente: comece com uma configuração mínima, adicione lógica de processamento e, em seguida, ative recursos avançados.

Para cenários complexos não abordados neste documento ou campos que exigem personalização profunda, consulte a AliyunPipelineConfig parameter reference para obter uma lista completa de campos, regras de valores e detalhes sobre as capacidades dos plugins.

Uma configuração de coleta completa geralmente inclui as seguintes partes:

Configuração mínima (Obrigatória): Esta configuração estabelece o pipeline de dados do cluster para o Log Service e consiste em duas partes:
- Entradas (inputs): Define a origem do log. Para logs de contêiner, as origens incluem os dois tipos a seguir. Para coletar outros tipos de logs, como resultados de consultas MySQL, consulte Input plugins.
  - Saída padrão do contêiner (stdout e stderr): Logs que a aplicação do contêiner imprime no console.
  - Arquivos de log de texto: Arquivos de log gravados em um caminho especificado dentro do contêiner.
- Saídas (flushers): Define o destino do log. Os logs coletados são enviados para o LogStore especificado.
  
  Se o Project ou LogStore de destino não existir, o sistema o criará automaticamente. Você também pode criar manualmente um Project e um LogStore antecipadamente.
Configurações comuns de processamento (Opcional): Defina o campo processors para realizar análise estruturada (como expressão regular ou delimitador), mascaramento de dados ou filtragem nos logs brutos.

Este documento descreve apenas plugins de processamento nativos que cobrem cenários comuns de processamento de logs. Para mais recursos, consulte Extended processing plugins.
Outras configurações avançadas (Opcional): Ativa recursos avançados, como coleta de logs multilinha e enriquecimento de tags de log, para atender a requisitos de coleta mais específicos.

Exemplo de estrutura:

apiVersion: telemetry.alibabacloud.com/v1alpha1 # Use the default value. Do not modify.
kind: ClusterAliyunPipelineConfig               # Use the default value. Do not modify.
metadata:
  name: test-config                             # Set the resource name, which must be unique within the current Kubernetes cluster.
spec:
  project:                                      # Set the name of the target Project.
    name: k8s-your-project                      
  config:                                       # Set the Logtail collection configuration.
    inputs:                                     # Set the input plugins for the Logtail collection configuration.
      ...
    processors:                                 # Set the processing plugins for the Logtail collection configuration.
      ...
    flushers:                                   # Set the output plugins for the Logtail collection configuration.
      ...

Aplique a configuração
```
kubectl apply -f <your_yaml>
```

Instale o LoongCollector (Logtail)

O LoongCollector é o agente de coleta de logs de nova geração do SLS, uma versão atualizada do Logtail. Ambos não podem coexistir. Para instalar o Logtail, consulte Install and configure Logtail .

Siga estas etapas para a instalação básica do LoongCollector. Para parâmetros detalhados, consulte Installation and configuration. Se o LoongCollector ou Logtail já estiver instalado, pule para a criação da logstore.

ACK cluster

É possível instalar o LoongCollector pelo console do Container Service for Kubernetes (ACK). Por padrão, os logs são enviados para um Project do Simple Log Service na conta Alibaba Cloud atual.

Faça login no console do ACK. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, clique no nome do cluster de destino para abrir sua página de detalhes.
No painel de navegação à esquerda, clique em Add-ons.

Na aba, localize loongcollector e clique em Install.

Nota

Ao criar um cluster, na página Component Configurations, marque a caixa de seleção Enable Log Service. Em seguida, você pode optar por Create Project ou Select Project.

Após a conclusão da instalação, o Simple Log Service cria automaticamente os recursos relacionados na região do seu cluster ACK. Visualize esses recursos no console do Simple Log Service.

Tipo de recurso

Nome do recurso

Descrição

Project

k8s-log-${cluster_id}

Isola logs de diferentes serviços.

Para criar um Project visando um gerenciamento mais flexível dos recursos de log, consulte Create a Project.

machine group

k8s-group-${cluster_id}

Um grupo de nós de coleta de logs.

Importante

O LoongCollector não cria um logstore chamado config-operation-log. Caso já exista um logstore com esse nome, o LoongCollector interrompe a gravação de logs nele.

Self-managed cluster

Conecte-se ao seu cluster Kubernetes. Em seguida, execute o comando apropriado para sua região a fim de baixar o LoongCollector e suas dependências:

Para regiões na China continental:

wget https://aliyun-observability-release-cn-shanghai.oss-cn-shanghai.aliyuncs.com/loongcollector/k8s-custom-pkg/3.0.12/loongcollector-custom-k8s-package.tgz; tar xvf loongcollector-custom-k8s-package.tgz; chmod 744 ./loongcollector-custom-k8s-package/k8s-custom-install.sh

Para regiões fora da China continental:

wget https://aliyun-observability-release-ap-southeast-1.oss-ap-southeast-1.aliyuncs.com/loongcollector/k8s-custom-pkg/3.0.12/loongcollector-custom-k8s-package.tgz; tar xvf loongcollector-custom-k8s-package.tgz; chmod 744 ./loongcollector-custom-k8s-package/k8s-custom-install.sh

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

# ===================== Required parameters =====================
# The Project where logs are sent. Example: k8s-log-custom-sd89ehdq.
projectName: ""
# The Project's region. Example: cn-shanghai.
region: ""
# The UID of the Alibaba Cloud account that owns the Project. Enclose the value in quotation marks. Example: "123456789"
aliUid: ""
# The network type. Valid values: Internet (public network) and Intranet (internal network). Default: Internet.
net: Internet
# The AccessKey ID and secret for an Alibaba Cloud account or RAM user that has the AliyunLogFullAccess policy.
accessKeyID: ""
accessKeySecret: ""
# The custom cluster ID. The ID can contain only uppercase letters, lowercase letters, digits, and hyphens (-).
clusterID: ""

No diretório loongcollector-custom-k8s-package, execute o seguinte comando para instalar o LoongCollector e suas dependências:
```
bash k8s-custom-install.sh install
```

Após a conclusão da instalação, verifique o status dos componentes.

Se os pods falharem ao iniciar, verifique a configuração do values.yaml e garanta que as imagens necessárias foram baixadas.

# Check pod status
kubectl get po -n kube-system | grep loongcollector-ds

O Simple Log Service também cria automaticamente os seguintes recursos. Visualize-os no console do Simple Log Service.

Tipo de recurso

Nome do recurso

Descrição

Project

O valor de projectName especificado no arquivo values.yaml

Isola logs de diferentes serviços.

machine group

k8s-group-${cluster_id}

Um grupo de nós de coleta de logs.

Importante

O LoongCollector não cria um logstore chamado config-operation-log. Caso já exista um logstore com esse nome, o LoongCollector interrompe a gravação de logs nele.

Crie um Logstore

Se você já criou um logstore, pule esta etapa e vá para collection configuration.

Faça login no console do Log Service e clique no projeto de destino.
No painel de navegação à esquerda, escolha Log Storage e clique em +.
Na página Create Logstore, configure os seguintes parâmetros principais:
- Logstore Name: Insira um nome exclusivo dentro do projeto. Este nome não pode ser alterado após a criação.
- Logstore Type: Escolha Standard ou Query com base em suas especificações.
- Billing Mode:
  - Pay-by-feature: A cobrança é feita separadamente para cada recurso, como armazenamento, indexação e operações de leitura/gravação. Adequado para casos de uso em pequena escala ou quando o uso dos recursos é incerto.
  - Pay-by-ingested-data: A cobrança ocorre apenas pela quantidade de dados brutos ingeridos. Este modo oferece um período gratuito de armazenamento de 30 dias e recursos gratuitos, como transformação e entrega de dados. Esse modelo de custo simplificado é ideal para casos em que o período de retenção é próximo de 30 dias ou o pipeline de processamento de dados é complexo.
- Data Retention Period: Defina o número de dias para reter os logs. O valor varia de 1 a 3650 dias. Um valor de 3650 indica armazenamento permanente. O padrão é 30 dias.
Mantenha as demais configurações com seus valores padrão e clique em OK. Manage logstores.

Configuração mínima

Em spec.config, você configura plugins de entrada e saída para definir a origem e o destino dos logs.

Container standard output (old version)

Finalidade: Coleta logs de saída padrão do contêiner (stdout/stderr) impressos diretamente no console.

inputs (plugin de entrada)

Define a origem do log. Atualmente, é possível configurar apenas um plugin de entrada.

Type String (Obrigatório)

Defina como service_docker_stdout.
Stderr boolean (Opcional)

Indica se deve coletar o fluxo de erro padrão (stderr). Padrão: true.
- true: Coleta o stderr.
- false: Não coleta o stderr.
Stdout boolean (Opcional)

Indica se deve coletar o fluxo de saída padrão (stdout). Padrão: true.
- true: Coleta o stdout.
- false: Não coleta o stdout.

Exemplo

apiVersion: telemetry.alibabacloud.com/v1alpha1
kind: ClusterAliyunPipelineConfig
metadata:
  # Set a unique resource name within the Kubernetes cluster. 
  # This name is also used for the created Logtail collection configuration.
  name: new-stdio-config
spec:
  project:
    name: test-not-exist
  logstores:
    - name: new-stdio-logstore

  # Define the collection and processing configuration for LoongCollector (Logtail).
  config:
    # --- input plugin: Defines the log source ---
    inputs:
      # Use the service_docker_stdout plugin to collect container standard output logs.
      - Type: service_docker_stdout
        Stderr: true
        Stdout: true

    # --- processing plugin (Optional): Defines how to parse and process logs ---
    processors: []

    # --- output plugin: Defines the log destination ---
    flushers: # Configure one or more flushers to define log destinations. This example sends logs to two Logstores.
      - Type: flusher_sls    # Specify the SLS output plugin.
        Logstore: new-stdio-logstore1
      - Type: flusher_sls    # Specify the SLS output plugin.
        Logstore: new-stdio-logstore2

flushers (plugin de saída)

O plugin flusher_sls envia os logs coletados para um Logstore especificado em um Project. É possível configurar até cinco plugins de saída.

Type String (Obrigatório)

Defina como flusher_sls.
Logstore String (Obrigatório)

O nome do Logstore de destino, que determina onde os logs serão armazenados.
Nota
- O Logstore especificado deve existir ou estar declarado em spec.logstores.
- Ao configurar múltiplos destinos de saída, a configuração deixa de aparecer na lista de configurações do Logstore. Para gerenciar a configuração de múltiplos destinos, consulte How do I manage a multi-target configuration?.

Container text files

Finalidade: Coleta logs gravados em um caminho de arquivo específico dentro de um contêiner, como access.log ou app.log.

inputs (plugin de entrada)

Define a origem do log. Atualmente, é possível configurar apenas um plugin de entrada.

Type String (Obrigatório)

Defina como input_file.
FilePaths String (Obrigatório)

Uma lista de caminhos para os arquivos de log.
- Atualmente, é possível configurar apenas um caminho.
- Você pode usar os seguintes caracteres curinga:
  - *: Corresponde a nomes de arquivos em um diretório de nível único.
  - **: Corresponde recursivamente a subdiretórios de vários níveis. Pode ser usado apenas uma vez e deve ser colocado antes do nome do arquivo.
MaxDirSearchDepth integer (Opcional)

Profundidade máxima de diretório para busca recursiva quando o caminho contém **. Padrão: 0. Valores válidos: 0 a 1.000.
FileEncoding String (Opcional)

A codificação do arquivo. Padrão: utf8. Valores válidos:
- utf8
- gbk
EnableContainerDiscovery boolean (Opcional)

Indica se deve ativar a descoberta de contêineres. Padrão: true.

Nota
Este parâmetro só tem efeito quando o LoongCollector (Logtail) é executado no modo DaemonSet e o caminho de arquivo especificado está dentro do contêiner.

Exemplo

apiVersion: telemetry.alibabacloud.com/v1alpha1
kind: ClusterAliyunPipelineConfig
metadata:
  name: easy-row-config
spec:
  # Specify the target Project to which logs are sent.
  project:
    name: test-not-exist
  logstores:
    - name: easy-row-logstore

  # Define the collection and processing configuration for LoongCollector (Logtail).
  config:
    # Log sample (optional)
    sample: ''
    # --- input plugin: Defines the log source ---
    inputs:
      # Use the input_file plugin to collect text log files from containers.
      - Type: input_file         
        # ... Specific configuration for the input plugin ...
        # The file path inside the container.
        FilePaths:
          - /var/log/text1.log
        # The maximum directory monitoring depth.
        MaxDirSearchDepth: 0
        FileEncoding: utf8  
        # Enable the container discovery feature.
        EnableContainerDiscovery: true
        

    # --- processing plugin (Optional): Defines how to parse and process logs ---
    processors: []    

    # --- output plugin: Defines the log destination ---
    flushers: # Configure one or more flushers to define log destinations. This example sends logs to two Logstores.
      - Type: flusher_sls        # Specify the SLS output plugin.
        Logstore: easy-row-logstore1
      - Type: flusher_sls        # Specify the SLS output plugin.
        Logstore: easy-row-logstore2

flushers (plugin de saída)

O plugin flusher_sls envia os logs coletados para um Logstore especificado em um Project. É possível configurar até cinco plugins de saída.

Type String (Obrigatório)

Defina como flusher_sls.
Logstore String (Obrigatório)

O nome do Logstore de destino, que determina onde os logs serão armazenados.
Nota
- O Logstore especificado deve existir ou estar declarado em spec.logstores.
- Ao configurar múltiplos destinos de saída, a configuração deixa de aparecer na lista de configurações do Logstore. Para gerenciar a configuração de múltiplos destinos, consulte How do I manage a multi-target configuration?.

Configuração comum

Após concluir o minimal configuration, adicione plugins de processor para analisar, mascarar ou filtrar logs brutos.

Configuração principal: Para configurar plugins de processamento, adicione processors ao spec.config. Isso permite ativar vários plugins simultaneamente.

Este tópico aborda apenas plugins de processamento nativos que lidam com casos de uso comuns de processamento de log. Para mais recursos, consulte extended processing plugins .

Importante

Para Logtail 2.0+ e LoongCollector, siga estas diretrizes de ordenação de plugins:

Priorize plugins nativos.
Caso os plugins nativos não atendam às suas necessidades, configure plugins de extensão para executar após eles.
Plugins nativos só podem executar antes dos plugins de extensão.

Configuração estruturada

Regex parsing

Extrai campos de log usando uma expressão regular e analisa os logs em pares chave-valor.

Parâmetro

Exemplo

Type String (Obrigatório)

Fixo como processor_parse_regex_native.

 # ... under spec.config ...
 processors:
  # Use the regular expression parsing processor to parse log content.
  - Type: processor_parse_regex_native
    # Specify the source field, which is usually content.
    SourceKey: content

    # A regular expression to match and extract log fields.
    Regex: >-
      (\S+)\s-\s(\S+)\s$$([^]]+)$$\s"
      (\w+)\s(\S+)\s([^"]+)"
      \s(\d+)\s(\d+)\s"
      ([^"]+)"\s"
      ([^"]+).*

    # A list of extracted fields, corresponding to the regex groups in order.
    Keys:
      - remote_addr
      - remote_user
      - time_local
      - request_method
      - request_uri
      - request_protocol
      - status
      - body_bytes_sent
      - http_referer
      - http_user_agent

    # Whether to keep the source field if parsing fails.
    KeepingSourceWhenParseFail: true

    # Whether to keep the source field if parsing succeeds.
    KeepingSourceWhenParseSucceed: true

    # If the source field is kept, you can specify a new name for it.
    RenamedSourceKey: fail

SourceKey String (Obrigatório)

Nome do campo de origem.

Regex String (Obrigatório)

Expressão regular para analisar o log.

Keys String (Obrigatório)

Lista de chaves para os campos extraídos.

KeepingSourceWhenParseFail boolean (Opcional)

Indica se o campo de origem deve ser mantido quando a análise falhar. Padrão: false.

KeepingSourceWhenParseSucceed boolean (Opcional)

Indica se o campo de origem deve ser mantido quando a análise for bem-sucedida. Padrão: false.

RenamedSourceKey String (Opcional)

Novo nome para o campo de origem, caso ele seja mantido. Se omitido, o campo de origem não será renomeado.

Delimiter parsing

Analisa logs em pares chave-valor usando um delimitador de caractere único ou múltiplo.

Parâmetro

Exemplo

Type String (Obrigatório)

Fixo como processor_parse_delimiter_native.

# ... under spec.config ...
processors:
  # Delimiter parsing processor configuration
  - Type: processor_parse_delimiter_native
    # The source field, usually content
    SourceKey: content

    Separator: ','

    Quote: '"'

    # Define the names for the extracted fields in order.
    Keys:
      - time
      - ip
      - request
      - status
      - size
      - user_agent

SourceKey String (Obrigatório)

Nome do campo de origem.

Separator String (Obrigatório)

Delimitador de campo. Por exemplo, arquivos CSV usam vírgula (,).

Keys [String] (Obrigatório)

Lista de chaves para os campos extraídos.

Quote String (Opcional)

Caractere de aspas usado para envolver campos que contêm caracteres especiais, como o próprio delimitador.

AllowingShortenedFields boolean (Opcional)

Define se é permitido ter menos campos extraídos do que o definido em Keys. Padrão: true. Se não for permitido, a operação será tratada como falha de análise.

OverflowedFieldsTreatment String (Opcional)

Comportamento adotado quando mais campos são extraídos do que o definido em Keys. Padrão: extend. Valores válidos:

extend: Mantém os campos excedentes e os adiciona ao log como campos separados. Os campos recebem o nome _column$i_, onde $i é o índice do campo excedente, começando em 0.
keep: Mantém os campos excedentes, mas adiciona o conteúdo excedente ao log como um único campo chamado _column0_.
discard: Descarta os campos extras.

KeepingSourceWhenParseFail boolean (Opcional)

Indica se o campo de origem deve ser mantido se a análise falhar. Padrão: false.

KeepingSourceWhenParseSucceed boolean (Opcional)

Indica se o campo de origem deve ser mantido em caso de análise bem-sucedida. Padrão: false.

RenamedSourceKey String (Opcional)

Novo nome para o campo de origem, caso ele seja mantido. Se omitido, o campo de origem não será renomeado.

Standard JSON parsing

Analisa um objeto JSON de um campo de log em pares chave-valor.

Parâmetro

Exemplo

Type String (Obrigatório)

Fixo como processor_parse_json_native.

# ... under spec.config ...
processors:
  # JSON parsing processor configuration
  - Type: processor_parse_json_native
    # The source field of the raw log
    SourceKey: content
    KeepingSourceWhenParseFail: true
    RenamedSourceKey: raw_log

SourceKey String (Obrigatório)

Nome do campo de origem.

KeepingSourceWhenParseFail boolean (Opcional)

Indica se o campo de origem deve ser mantido quando a análise falhar. Padrão: false.

KeepingSourceWhenParseSucceed boolean (Opcional)

Indica se o campo de origem deve ser mantido em caso de análise bem-sucedida. Padrão: false.

RenamedSourceKey String (Opcional)

Novo nome para o campo de origem, caso ele seja mantido. Se omitido, o campo de origem não será renomeado.

Os nomes de parâmetros no YAML do CRD usam camelCase, como RenamedSourceKey. Nomes em snake_case, como renamed_source_key, não são válidos.

Nested JSON parsing

Achata um objeto JSON aninhado em pares chave-valor e permite especificar a profundidade de expansão.

Parâmetro

Exemplo

Type String (Obrigatório)

Fixo como processor_json.

# ... under spec.config ...
processors:
  # Configure the JSON field expansion processor.
  - Type: processor_json
    # Specify the source field to parse.
    SourceKey: content
    
    ExpandDepth: 0

    ExpandConnector: '_'

    Prefix: expand

    IgnoreFirstConnector: false

    # Whether to expand array elements into separate fields.
    ExpandArray: false

    # Whether to keep the source field content.
    KeepSource: true

    # Whether to report an error if the source field is missing.
    NoKeyError: true

    # Whether to use the source field name as a prefix for expanded field names.
    UseSourceKeyAsPrefix: false

    # Whether to keep the source log data if JSON parsing fails.
    KeepSourceIfParseError: true

SourceKey String (Obrigatório)

Nome do campo de origem.

ExpandDepth integer (Opcional)

Profundidade máxima de expansão para o objeto JSON aninhado. Padrão: 0.

0: Expande o objeto até o nível mais profundo analisável.
1: Expande apenas o nível superior do objeto, e assim por diante.

ExpandConnector String (Opcional)

Conector usado entre as chaves ao achatar um objeto JSON aninhado. Padrão: sublinhado (_).

Prefix String (Opcional)

Prefixo a ser adicionado a todos os nomes de campos expandidos.

IgnoreFirstConnector String (Opcional)

Define se o conector antes do campo de nível superior deve ser omitido. Padrão: false.

ExpandArray boolean (Opcional)

Define se tipos de array devem ser expandidos. Padrão: false.

false (padrão): Não expande o array.
true: O array é expandido. Por exemplo, {"k":["1","2"]} é expandido para {"k[0]":"1","k[1]":"2"}.

Nota

Este parâmetro é suportado no Logtail 1.8.0 e versões posteriores.

KeepSource boolean (Opcional)

Define se o campo original deve ser mantido no log analisado. Padrão: true.

true: Manter
false: Descartar

NoKeyError boolean (Opcional)

Define se um erro deve ser relatado caso o campo de origem especificado não seja encontrado. Padrão: true.

true: Relatar um erro.
false: Não relatar um erro.

UseSourceKeyAsPrefix boolean (Opcional)

Se definido como true, usa o nome do campo de origem como prefixo para todos os nomes de campos expandidos.

KeepSourceIfParseError boolean (Opcional)

Define se os logs brutos devem ser mantidos quando a análise falhar. Padrão: true.

true: Manter
false: Descartar

JSON array parsing

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

Parâmetro	Exemplo
Type `String` (Obrigatório) Tipo do plugin. O tipo do plugin SPL é `processor_spl`.	`# ... under spec.config ... processors: # Use an SPL script to process log fields. - Type: processor_spl # Script timeout in milliseconds. TimeoutMilliSeconds: 1000 # The SPL script, used to extract elements from the JSON array in the content field. Script: >- * \| extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')`
Script `String` (Obrigatório) Script SPL usado para extrair elementos de um array JSON no campo content.
TimeoutMilliSeconds `integer` (Opcional) Tempo limite de execução do script em milissegundos. O valor deve estar entre 0 e 10.000. Valor padrão: 1.000.

NGINX log parsing

Analisa logs do NGINX em pares chave-valor com base na sua definição de log_format. Caso o formato padrão não atenda aos seus requisitos, utilize um formato personalizado.

Parâmetro

Exemplo

Type String (Obrigatório)

Fixo como processor_parse_regex_native.

# ... under spec.config ...
processors:
  # NGINX log parsing processor configuration
  - Type: processor_parse_regex_native
    # The source field of the raw log
    SourceKey: content
    
    # Regular expression parsing rule
    Regex: >-
      (\S*)\s*-\s*(\S*)\s*\[
      (\d+/\S+/\d+:\d+:\d+:\d+)\s+\S+\]
      \s*"(\S+)\s+(\S+)\s+\S+"
      \s*(\S*)\s*(\S*)\s*(\S*)\s*(\S*)
      \s*"([^"]*)"\s*"([^"]*)".*
    
    # Map of extracted fields
    Keys:
      - remote_addr
      - remote_user
      - time_local
      - request_method
      - request_uri
      - request_time
      - request_length
      - status
      - body_bytes_sent
      - http_referer
      - http_user_agent
    
    # NGINX-specific configuration
    Extra:
      Format: >-
        log_format main  '$remote_addr - $remote_user [$time_local]
        "$request" ''$request_time $request_length ''$status
        $body_bytes_sent "$http_referer" ''"$http_user_agent"';
      LogType: NGINX

SourceKey String (Obrigatório)

Nome do campo de origem.

Regex String (Obrigatório)

Expressão regular para analisar o log do NGINX.

Keys String (Obrigatório)

Lista de chaves para os campos extraídos.

Extra

Format String (Obrigatório)

A diretiva log_format do seu arquivo de configuração do NGINX.

Em um ambiente de produção, este log_format deve ser consistente com a definição no arquivo de configuração do Nginx (geralmente localizado em /etc/nginx/nginx.conf).
LogType String (Obrigatório)

Fixo como NGINX.

KeepingSourceWhenParseFail boolean (Opcional)

Define se o campo original deve ser mantido se a análise falhar. Padrão: false.

KeepingSourceWhenParseSucceed boolean (Opcional)

Define se o campo original deve ser mantido em caso de análise bem-sucedida. Padrão: false.

RenamedSourceKey String (Opcional)

Novo nome para o campo de origem, caso ele seja mantido. Se omitido, o campo de origem não será renomeado.

Apache log parsing

Analisa logs do Apache em pares chave-valor com base no formato definido no seu arquivo de configuração do Apache.

Parâmetro

Exemplo

Type String (Obrigatório)

Fixo como processor_parse_regex_native.

# ... under spec.config ...
processors:
  # Configure the Apache Combined log parsing processor (based on a regular expression).
  - Type: processor_parse_regex_native
    # The source field, usually content.
    SourceKey: content

    # A regular expression to match and extract logs in Apache combined format.
    Regex: >-
      ([0-9.-]+)\s                          # remote_addr
      ([\w.-]+)\s                           # remote_ident
      ([\w.-]+)\s                           # remote_user
      (\[[^\[\]]+\]|-)\s                    # time_local
      "((?:[^"]|\")+)"\s                     # request_method + request_uri + request_protocol
      "((?:[^"]|\")+)"\s                     # request_uri (duplicate capture? check the logic)
      "((?:[^"]|\")+)"\s                     # request_protocol
      (\d{3}|-)\s                           # status
      (\d+|-)\s                             # response_size_bytes
      "((?:[^"]|\")+)"\s                     # http_referer
      "((?:[^"]|\"|')+)"                     # http_user_agent

    # A list of extracted fields, corresponding to the regex groups in order.
    Keys:
      - remote_addr
      - remote_ident
      - remote_user
      - time_local
      - request_method
      - request_uri
      - request_protocol
      - status
      - response_size_bytes
      - http_referer
      - http_user_agent

    # Extra plugin information (optional, used to describe the log format).
    Extra:
      Format: >-
        LogFormat "%h %l %u %t \"%r\" %>s %b
        \"%{Referer}i\" \"%{User-Agent}i\"" combined
      LogType: Apache
      SubType: combined

SourceKey String (Obrigatório)

Nome do campo de origem.

Regex String (Obrigatório)

Expressão regular para analisar o log do Apache.

Keys String (Obrigatório)

Lista de chaves para os campos extraídos.

Extra

Format String (Obrigatório)

A diretiva LogFormat do seu arquivo de configuração do Apache.
LogType String (Obrigatório)

Fixo como Apache.
SubType String (Obrigatório)

Formato do log.
- common
- combined
- custom

KeepingSourceWhenParseFail boolean (Opcional)

Define se o campo original deve ser mantido se a análise falhar. Padrão: false.

KeepingSourceWhenParseSucceed boolean (Opcional)

Define se o campo original deve ser mantido em caso de análise bem-sucedida. Padrão: false.

RenamedSourceKey String (Opcional)

Novo nome para o campo de origem, caso ele seja mantido. Se omitido, o campo de origem não será renomeado.

Mascaramento de dados

Utilize o plugin processor_desensitize_native para mascarar dados sensíveis nos seus logs.

Parâmetros

Exemplo

Type String (Obrigatório)

Defina como processor_desensitize_native.

# ... under spec.config ...
processors:
  # Configure the native log masking plugin
  - Type: processor_desensitize_native

    # The name of the source field
    SourceKey: content

    # Masking method, such as 'const' which replaces sensitive data with a fixed string
    Method: const

    # The string to replace sensitive data with
    ReplacingString: '********'

    # A regular expression for content preceding the sensitive data
    ContentPatternBeforeReplacedString: 'password'':'''

    # A regular expression for the sensitive data to be replaced
    ReplacedContentPattern: '[^'']*'

    # Specifies whether to replace all matches. Default is true.
    ReplacingAll: true

SourceKey String (Obrigatório)

Nome do campo de origem.

Method String (Obrigatório)

Método de mascaramento. Valores suportados:

const: Substitui dados sensíveis por uma string constante.
md5: Substitui dados sensíveis pelo seu hash MD5.

ReplacingString String (Opcional)

String constante que substitui os dados sensíveis. Este parâmetro é obrigatório quando Method está definido como const.

ContentPatternBeforeReplacedString String (Obrigatório)

Expressão regular para o conteúdo que precede os dados sensíveis.

ReplacedContentPattern String (Obrigatório)

Expressão regular que corresponde aos dados sensíveis.

ReplacingAll boolean (Opcional)

Define se todas as correspondências devem ser substituídas. Padrão: true.

Filtragem de conteúdo

Configure o plugin processor_filter_regex_native para comparar valores de campos de log com uma expressão regular e manter apenas os logs correspondentes.

Parâmetros	Exemplo
Type `String` (obrigatório) Tipo do plugin. Este valor deve ser `processor_filter_regex_native`.	`# ...under spec.config... processors: # Configure the regular expression filtering plugin (for log masking or sensitive word filtering). - Type: processor_filter_regex_native # Define a list of regular expressions to match log field content. FilterRegex: # Example: Matches log field values that contain "WARNING" or "ERROR". - WARNING\|ERROR # Specify the names of the log fields to filter. This example filters the 'level' field. FilterKey: - level`
FilterRegex `String` (obrigatório) Lista de expressões regulares para corresponder aos valores dos campos de log.
FilterKey `String` (obrigatório) Lista de nomes de campos de log aos quais os padrões FilterRegex serão aplicados.

Análise de tempo

Analise o campo de tempo em um log e utilize o resultado como o campo __time__ do log.

Campos principais

Exemplo

Type String (Obrigatório)

Tipo do plugin. Defina como processor_parse_timestamp_native.

# ...under spec.config...
processors:
  # Configure the native time parsing plugin.
  - Type: processor_parse_timestamp_native
    # The source field containing the timestamp, usually 'content'.
    SourceKey: content

    # The format of the source timestamp. Must match the log's format exactly.
    SourceFormat: '%Y-%m-%d %H:%M:%S'
    
    SourceTimezone: 'GMT+00:00'

SourceKey String (Obrigatório)

Nome do campo de origem.

SourceFormat String (Obrigatório)

O formato de tempo, que deve corresponder exatamente ao formato de tempo no log.

SourceTimezone String (Opcional)

Fuso horário do carimbo de data/hora de origem. Padrão: fuso horário da máquina que executa o LoongCollector.

Formato:

GMT+HH:MM: Fusos horários a leste de GMT
GMT-HH:MM: Fusos horários a oeste de GMT

Configurações avançadas

Após concluir o minimal configuration, utilize estas configurações avançadas para obter uma coleta mais granular:

Configurar coleta de logs multilinha: Ative o modo multilinha com uma expressão regular de padrão inicial para coletar entradas que abrangem várias linhas (como stack traces) como registros únicos de log.
Configurar tipos de tópicos de log: Atribua tópicos aos fluxos de log para facilitar a organização e a recuperação.
Especificar contêineres para coleta (filtragem e lista de bloqueios): Utilize listas de permissões e listas de bloqueios para coletar logs apenas de contêineres e caminhos específicos.
Enriquecer logs com tags: Adicione metadados de variáveis de ambiente e rótulos de pod aos seus logs na forma de tags.

Configurar coleta de logs multilinha

Por padrão, o SLS divide os logs linha por linha, separando entradas multilinha, como stack traces, em registros distintos.

Ative o modo multilinha e configure uma expressão regular de padrão inicial para agrupar entradas multilinha em registros únicos de log.

Configuração principal: Adicione o parâmetro Multiline à configuração spec.config.inputs.

Detalhes dos campos

Exemplo

Multiline

Habilita a coleta de logs multilinha.

Mode

Modo de coleta. O valor padrão é custom.
- custom: Usa uma expressão regular personalizada para corresponder ao início de uma linha.
- JSON: Formato JSON multilinha.
StartPattern

Expressão regular para o início de uma linha. Este parâmetro é obrigatório quando Mode está definido como custom.

# ...under spec.config...
inputs:
  - Type: input_file
    # Enable multiline log collection.
    Multiline:
      # Mode selection: custom indicates a custom regular expression to match the start of a line.
      Mode: custom
      # The regular expression matches the start of each log entry, which marks the beginning of a new log.
      StartPattern: '\d+-\d+-\d+\s\d+:\d+:\d+'

Tipos de tópicos de log

Configuração principal: Adicione o parâmetro global ao spec.config para definir o tópico do log.

Detalhes dos campos

Exemplo

TopicType

Tipo de tópico. Valores válidos:

machine_group_topic: Utiliza o tópico do grupo de máquinas onde esta configuração é aplicada. Útil para distinguir logs de diferentes grupos de máquinas.
filepath: Extrai um tópico do caminho do arquivo. Ajuda a diferenciar dados de log de diferentes usuários ou aplicações.
custom: Utiliza um tópico de log estático e personalizado.

Machine group topic

spec: 
  config:
    global: 
    # Use the topic of the machine group to which this configuration is applied as the log topic.
      TopicType: machine_group_topic

File path extraction

spec:  
  config:
    global: 
      TopicType: filepath
    # The topic format. Required when TopicType is filepath or custom.
    # The extraction results are __topic__: userA, __topic__: userB, and __topic__: userC.
      TopicFormat: \/data\/logs\/(.*)\/serviceA\/.*

Custom

spec:  
  config:
    global: 
      TopicType: custom
    # The topic format. Required when TopicType is filepath or custom.
      TopicFormat: customized://

TopicFormat

Formato do tópico. Este parâmetro é obrigatório quando TopicType está definido como filepath ou custom.

Filtragem e lista de bloqueios de contêineres

Filtragem

Colete logs apenas de contêineres que correspondam às condições especificadas. Múltiplas condições são combinadas com o operador lógico AND. Condições vazias são ignoradas. Todas as condições aceitam expressões regulares.

Configuração principal: Configure os parâmetros de filtragem de contêineres em ContainerFilters na seção spec.config.inputs.

Detalhes dos campos

Exemplo

ContainerFilters

Configurações de filtragem de contêineres.

Lista de permissões/bloqueios de rótulos de pod
- IncludeK8sLabel
  
  Lista de permissões de rótulos de pod K8s. Coleta logs de contêineres com os rótulos de pod especificados.
- ExcludeK8sLabel
  
  Lista de bloqueios de rótulos de pod K8s. Exclui logs de contêineres com os rótulos de pod especificados.
Lista de permissões/bloqueios de variáveis de ambiente
- IncludeEnv
  
  Lista de permissões de variáveis de ambiente.
- ExcludeEnv
  
  Lista de bloqueios de variáveis de ambiente.
Correspondência regex para nomes de pod/namespace/contêiner
- K8sNamespaceRegex
  
  Corresponde a nomes de namespace usando uma expressão regular.
- K8sPodRegex
  
  Corresponde a nomes de pod usando uma expressão regular.
- K8sContainerRegex
  
  Corresponde a nomes de contêiner usando uma expressão regular.

Toda correspondência de expressão regular baseia-se no mecanismo RE2 da linguagem Go, que possui certas limitações em comparação com mecanismos como PCRE. Escreva suas expressões regulares seguindo as diretrizes em Appendix: Regular expression limits for container filtering.

# ...under spec.config...
inputs:
  - Type: input_file # or input_container_stdio
    # When the input plugin type is input_file, you must set EnableContainerDiscovery to true.
    EnableContainerDiscovery: true
    # Container filtering
    ContainerFilters:
      # K8s pod label whitelist: Specifies the containers from which to collect logs.
      IncludeK8sLabel:
        # Example: Match all pods that have the app label with a value of nginx or redis.
        app: ^(nginx|redis)$

      # K8s pod label blacklist: Excludes log collection from containers that meet specific conditions.
      ExcludeK8sLabel:
        # Example: Exclude all pods with the app:test label.
        app: test
      
      # Environment variable whitelist.
      IncludeEnv:
        # Match all containers with NGINX_SERVICE_PORT=80 or NGINX_SERVICE_PORT=6379.
        NGINX_SERVICE_PORT: ^(80|6379)$

      # Environment variable blacklist.
      ExcludeEnv:
        # Exclude all containers with ENVIRONMENT=test.
        ENVIRONMENT: test
      
      # Match namespace names. Example: Match all containers in the default and nginx namespaces.
      K8sNamespaceRegex: ^(default|nginx)$
      # Match pod names. Example: Match containers in all pods whose names start with nginx-log-demo.
      K8sPodRegex: ^(nginx-log-demo.*)$
      # Match container names. Example: Match all containers named container-test.
      K8sContainerRegex: ^(container-test)$

Lista de bloqueios

Exclua arquivos que correspondam aos critérios especificados. Para isso, adicione os seguintes parâmetros em config.inputs na sua configuração YAML conforme necessário:

Detalhes dos campos

Example

# ...under spec.config...
inputs:
  - Type: input_file
    # File path blacklist. Excludes files based on the specified conditions. The path must be an absolute path and supports the * wildcard character.
    ExcludeFilePaths:
      - /var/log/*.log

    # File name blacklist. Excludes files based on the specified conditions. Supports the * wildcard character.
    ExcludeFiles:
      - test

    # Directory blacklist. Excludes directories based on the specified conditions. The path must be an absolute path and supports the * wildcard character.
    ExcludeDirs:
      - /var/log/backup*

ExcludeFilePaths

Lista de bloqueios de caminhos de arquivo. Exclui arquivos que correspondem aos caminhos absolutos especificados. Os caminhos podem incluir o caractere curinga *.

ExcludeFiles

Lista de bloqueios de nomes de arquivo. Exclui arquivos com nomes correspondentes. Os nomes podem incluir o caractere curinga *.

ExcludeDirs

Lista de bloqueios de diretórios. Exclui diretórios com base nos caminhos especificados. Os caminhos devem ser absolutos e podem incluir o caractere curinga *.

Enriquecimento de logs com tags

Configuração principal: No spec.config.inputs, configure ExternalEnvTag e ExternalK8sLabelTag para mapear variáveis de ambiente do contêiner e rótulos de pod para tags de log.

Detalhes dos campos

Exemplo

ExternalEnvTag

Mapeia o valor de uma variável de ambiente especificada para uma tag de log. O formato é <environment_variable_name>: <tag_name>.

# ...under spec.config...
inputs:
  - Type: input_file # or input_container_stdio
    ExternalEnvTag:
      <environment_variable_name>: <tag_name>
    
    ExternalK8sLabelTag:
      <pod_label_name>: <tag_name>

ExternalK8sLabelTag

Mapeia o valor de um rótulo de pod Kubernetes para uma tag de log. O formato é <pod_label_name>: <tag_name>.

Exemplos de configuração

Caso de uso 1: Analisar logs de acesso Nginx

Esta configuração analisa um log do Nginx e estrutura o conteúdo em múltiplos pares chave-valor com base na definição log_format.

Exemplo completo em YAML

apiVersion: telemetry.alibabacloud.com/v1alpha1
kind: ClusterAliyunPipelineConfig
metadata:
  name: nginx-config
spec:
  config:
    aggregators: []
    global: {}
    inputs:
      - Type: input_file
        FilePaths:
          - /root/log/text1.log
        MaxDirSearchDepth: 0
        FileEncoding: utf8
        EnableContainerDiscovery: true
    processors:
      - Type: processor_parse_regex_native
        SourceKey: content
        Regex: >-
          (\S*)\s*-\s*(\S*)\s*\[(\d+/\S+/\d+:\d+:\d+:\d+)\s+\S+\]\s*"(\S+)\s+(\S+)\s+\S+"\s*(\S*)\s*(\S*)\s*(\S*)\s*(\S*)\s*"([^"]*)"\s*"([^"]*)".*
        Keys:
          - remote_addr
          - remote_user
          - time_local
          - request_method
          - request_uri
          - request_time
          - request_length
          - status
          - body_bytes_sent
          - http_referer
          - http_user_agent
        Extra:
          Format: >-
            log_format main  '$remote_addr - $remote_user [$time_local]
            "$request" ''$request_time $request_length ''$status
            $body_bytes_sent "$http_referer" ''"$http_user_agent"';
          LogType: NGINX
    flushers:
      - Type: flusher_sls
        Logstore: my-log-logstore
    sample: >-
      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"
  project:
    name: my-log-project
  logstores:
    - name: my-log-logstore

Caso de uso 2: Processar logs multilinha

Por padrão, o SLS trata cada linha como uma entrada de log separada, dividindo logs multilinha, como stack traces, em vários registros.

Ative o modo multilinha com uma expressão regular de padrão inicial para agrupar todas as linhas de um log multilinha em uma única entrada.

Exemplo completo em YAML

apiVersion: telemetry.alibabacloud.com/v1alpha1
kind: ClusterAliyunPipelineConfig
metadata:
  name: multiline-config
spec:
  config:
    aggregators: []
    global: {}
    inputs:
      - Type: input_file
        FilePaths:
          - /root/log/text1.log
        MaxDirSearchDepth: 0
        FileEncoding: utf8
        Multiline:
          StartPattern: '\[\d+-\d+-\w+:\d+:\d+,\d+]\s\[\w+]\s.*'
          Mode: custom
          UnmatchedContentTreatment: single_line
        EnableContainerDiscovery: true
    processors: []
    flushers:
      - Type: flusher_sls
        Logstore: my-log-logstore
    sample: |-
      [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)
  project:
    name: my-log-project
  logstores:
    - name: my-log-logstore

FAQ

Gerenciamento de distribuição para múltiplos destinos

As configurações de distribuição para múltiplos destinos estão associadas a vários Logstores e devem ser gerenciadas na página de gerenciamento no nível do projeto:

Faça login no console do Simple Log Service e clique no nome do projeto desejado.
Na página do projeto, no painel de navegação à esquerda, clique em Resources > Configurations.

Nota
Esta página lista todas as configurações de coleta no projeto, incluindo configurações residuais de Logstores excluídos acidentalmente.

Enviar logs do ACK para um projeto entre contas

Instale o LoongCollector (Logtail) manualmente em um cluster ACK e configure-o com as credenciais da conta de destino para enviar logs a um projeto em outra conta Alibaba Cloud.

Caso de uso: Coletar logs de um cluster ACK em um projeto sob uma conta separada para fins de estrutura organizacional, isolamento de permissões ou monitoramento unificado.

Procedimento: Este procedimento mostra como instalar o LoongCollector manualmente. Para saber como instalar o Logtail, consulte Install and configure Logtail.

Conecte-se ao cluster Kubernetes e execute o comando correspondente à sua região para baixar o LoongCollector e suas dependências:

Regiões na China:

wget https://aliyun-observability-release-cn-shanghai.oss-cn-shanghai.aliyuncs.com/loongcollector/k8s-custom-pkg/3.0.12/loongcollector-custom-k8s-package.tgz; tar xvf loongcollector-custom-k8s-package.tgz; chmod 744 ./loongcollector-custom-k8s-package/k8s-custom-install.sh

Regiões fora da China:

wget https://aliyun-observability-release-ap-southeast-1.oss-ap-southeast-1.aliyuncs.com/loongcollector/k8s-custom-pkg/3.0.12/loongcollector-custom-k8s-package.tgz; tar xvf loongcollector-custom-k8s-package.tgz; chmod 744 ./loongcollector-custom-k8s-package/k8s-custom-install.sh

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

# ===================== Required Information =====================
# The name of the Project to which logs from this cluster are sent. Example: k8s-log-custom-sd89ehdq
projectName: ""
# The region where the Project is located. Example: cn-shanghai
region: ""
# The UID of the Alibaba Cloud account that owns the Project. Enclose the UID in quotation marks (""). Example: "123456789"
aliUid: ""
# The network type. Valid values: Internet and Intranet. Default value: Internet.
net: Internet
# The AccessKey ID and AccessKey secret of the Alibaba Cloud account or RAM user. The account or RAM user must have the AliyunLogFullAccess system policy permission.
accessKeyID: ""
accessKeySecret: ""
# A custom cluster ID. The ID can contain only uppercase letters, lowercase letters, digits, and hyphens (-).
clusterID: ""

No diretório loongcollector-custom-k8s-package, execute o seguinte comando para instalar o LoongCollector e suas dependências:
```
bash k8s-custom-install.sh install
```

Após a conclusão da 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.

# Check the pod status
kubectl get po -n kube-system | grep loongcollector-ds

O Simple Log Service também cria automaticamente os seguintes recursos. 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

Unidade de gerenciamento de recursos que isola logs de diferentes serviços.

Grupo de máquinas

k8s-group-${cluster_id}

Conjunto de nós de coleta de logs.

Importante

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

Múltiplas coletas para uma única fonte

Por padrão, o SLS restringe cada fonte de log a uma única configuração de coleta para evitar duplicação:

Um arquivo de log de texto pode corresponder a apenas uma configuração de coleta do Logtail.
A saída padrão (stdout) de um contêiner pode corresponder a apenas uma configuração de coleta de saída padrão.

Faça login no console do Simple Log Service e acesse o projeto desejado.
No painel de navegação à esquerda, selecione Logstores e localize o logstore desejado.
Clique no ícone ao lado do nome para expandir o logstore.
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.
Na página Logtail Configurations, clique em Edit e role para baixo 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.

Apêndice: Limites de regex (filtragem de contêineres)

As expressões regulares para filtragem de contêineres utilizam o mecanismo Go RE2, que apresenta limitações de sintaxe em comparação ao PCRE:

1. Diferenças na sintaxe de grupos nomeados

O Go utiliza a sintaxe (?P<name>...) para grupos nomeados. Ele não oferece suporte à sintaxe (?<name>...) usada no PCRE.

Exemplo correto: (?P<year>\d{4})
Sintaxe incorreta: (?<year>\d{4})

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

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

Asserções: (?=...), (?!...), (?<=...), (?<!...)
Expressões condicionais: (?(condition)true|false)
Correspondência recursiva: (?R), (?0)
Referências de subprograma: (?&name), (?P>name)
Grupos atômicos: (?>...)

3. Recomendações

Ao depurar regex com uma ferramenta como o Regex101, selecione o modo Golang (RE2). Sintaxes não suportadas impedem que o plugin analise ou faça a correspondência corretamente.