Simple Log Service:Coletar logs de texto de pods do Kubernetes (modo sidecar)

1. Modificar a configuração YAML do pod

1. Definir volumes compartilhados

   Em spec.template.spec.volumes, adicione três volumes compartilhados no mesmo nível de containers:

   volumes:
     # Shared log directory (written by the application container, read by the sidecar)
     - name: ${shared_volume_name} # <-- The name must match the name in volumeMounts
       emptyDir: {}
     # Signal directory for inter-container communication (for graceful start/stop)
     - name: tasksite
       emptyDir:
         medium: Memory  # Use memory as the medium for better performance
         sizeLimit: "50Mi"
     # Shared host time zone configuration: Synchronizes the time zone for all containers in the pod
     - name: tz-config # <-- The name must match the name in volumeMounts
       hostPath:
         path: /usr/share/zoneinfo/Asia/Shanghai  # Modify the time zone as needed
   

2. Configurar montagens do contêiner da aplicação

   Na seção volumeMounts do seu contêiner de aplicação, como your-business-app-container, adicione as seguintes montagens de volume:

   Garanta que o contêiner da aplicação grave logs no diretório ${shared_volume_path} para que o LoongCollector possa coletá-los.

   volumeMounts:
     # Mount the shared log volume to the application log output directory
     - name: ${shared_volume_name}
       mountPath: ${shared_volume_path}  # Example: /var/log/app
     # Mount the communication directory
     - name: tasksite
       mountPath: /tasksite  # Shared directory for communication with the LoongCollector container
     # Mount the timezone file
     - name: tz-config
       mountPath: /etc/localtime
       readOnly: true
   

3. Injetar o contêiner sidecar do LoongCollector

   No array spec.template.spec.containers, anexe a seguinte definição de contêiner sidecar:

   - name: loongcollector
     image: aliyun-observability-release-registry.cn-shenzhen.cr.aliyuncs.com/loongcollector/loongcollector:v3.1.1.0-20fa5eb-aliyun
     command: ["/bin/bash", "-c"]
     args:
       - |
         echo "[$(date)] LoongCollector: Starting initialization"
         # Start the LoongCollector service
         /etc/init.d/loongcollectord start
         # Wait for the configuration to download and the service to be ready
         sleep 15
         # Verify the service status
         if /etc/init.d/loongcollectord status; then
           echo "[$(date)] LoongCollector: Service started successfully"
           touch /tasksite/cornerstone
         else
           echo "[$(date)] LoongCollector: Failed to start service"
           exit 1
         fi
         # Wait for the application container to complete (via the tombstone file signal)
         echo "[$(date)] LoongCollector: Waiting for application container to complete"
         until [[ -f /tasksite/tombstone ]]; do
           sleep 2
         done
         # Allow time to upload remaining logs
         echo "[$(date)] LoongCollector: Business completed, waiting for log transmission"
         sleep 30
         # Stop the service
         echo "[$(date)] LoongCollector: Stopping service"
         /etc/init.d/loongcollectord stop
         echo "[$(date)] LoongCollector: Shutdown complete"
     # health check
     livenessProbe:
       exec:
         command: ["/etc/init.d/loongcollectord", "status"]
       initialDelaySeconds: 30
       periodSeconds: 10
       timeoutSeconds: 5
       failureThreshold: 3
     # resource configuration
     resources:
       requests:
         cpu: "100m"
         memory: "128Mi"
       limits:
         cpu: "2000m"
         memory: "2048Mi"
     # environment variable configuration
     env:
       - name: ALIYUN_LOGTAIL_USER_ID
         value: "${your_aliyun_user_id}"
       - name: ALIYUN_LOGTAIL_USER_DEFINED_ID
         value: "${your_machine_group_user_defined_id}"
       - name: ALIYUN_LOGTAIL_CONFIG
         value: "/etc/ilogtail/conf/${your_region_config}/ilogtail_config.json"
       # Enable full drain mode to ensure all logs are sent before the pod terminates
       - name: enable_full_drain_mode
         value: "true"  
       # Append pod environment information as log tags
       - name: ALIYUN_LOG_ENV_TAGS
         value: "_pod_name_|_pod_ip_|_namespace_|_node_name_|_node_ip_"
       # Automatically inject pod and node metadata as log tags
       - name: "_pod_name_"
         valueFrom:
           fieldRef:
             fieldPath: metadata.name
       - name: "_pod_ip_"
         valueFrom:
           fieldRef:
             fieldPath: status.podIP
       - name: "_namespace_"
         valueFrom:
           fieldRef:
             fieldPath: metadata.namespace
       - name: "_node_name_"
         valueFrom:
           fieldRef:
             fieldPath: spec.nodeName
       - name: "_node_ip_"
         valueFrom:
           fieldRef:
             fieldPath: status.hostIP
     # Volume mounts (shared with the application container)
     volumeMounts:
       # Read-only mount for the application log directory
       - name: ${shared_volume_name} # <-- Shared log directory name
         mountPath: ${dir_containing_your_files} # <-- Path to the shared directory in the sidecar
         readOnly: true
       # Mount the communication directory
       - name: tasksite
         mountPath: /tasksite
       # Mount the timezone
       - name: tz-config
         mountPath: /etc/localtime
         readOnly: true
   

2. Adaptar a lógica do ciclo de vida do contêiner da aplicação

Dependendo do tipo de carga de trabalho, modifique o contêiner da aplicação para suportar uma saída coordenada com o sidecar:

# 1. Wait for LoongCollector to be ready
echo "[$(date)] Application: Waiting for LoongCollector to be ready..."
until [[ -f /tasksite/cornerstone ]]; do
  sleep 1
done
echo "[$(date)] Application: LoongCollector is ready, starting application logic"
# 2. Execute core application logic (ensure logs are written to the shared directory)
echo "Hello, World!" >> /app/logs/business.log
# 3. Save the exit code
retcode=$?
echo "[$(date)] Application: Task completed with exit code: $retcode"
# 4. Notify LoongCollector that the application task is complete
touch /tasksite/tombstone
echo "[$(date)] Application: Tombstone created, exiting"
exit $retcode

# Define the signal handler function
_term_handler() {
    echo "[$(date)] [nginx-demo] Caught SIGTERM, starting graceful shutdown..."
    # Send a QUIT signal to Nginx for a graceful stop
    if [ -n "$NGINX_PID" ]; then
        kill -QUIT "$NGINX_PID" 2>/dev/null || true
        echo "[$(date)] [nginx-demo] Sent SIGQUIT to Nginx PID: $NGINX_PID"
        # Wait for Nginx to stop gracefully
        wait "$NGINX_PID"
        EXIT_CODE=$?
        echo "[$(date)] [nginx-demo] Nginx stopped with exit code: $EXIT_CODE"
    fi
    # Notify LoongCollector that the application container has stopped
    echo "[$(date)] [nginx-demo] Writing tombstone file"
    touch /tasksite/tombstone
    exit $EXIT_CODE
}
# Register the signal handler
trap _term_handler SIGTERM SIGINT SIGQUIT
# Wait for LoongCollector to be ready
echo "[$(date)] [nginx-demo]: Waiting for LoongCollector to be ready..."
until [[ -f /tasksite/cornerstone ]]; do 
    sleep 1
done
echo "[$(date)] [nginx-demo]: LoongCollector is ready, starting application logic"
# Start Nginx
echo "[$(date)] [nginx-demo] Starting Nginx..."
nginx -g 'daemon off;' &
NGINX_PID=$!
echo "[$(date)] [nginx-demo] Nginx started with PID: $NGINX_PID"
# Wait for the Nginx process
wait $NGINX_PID
EXIT_CODE=$?
# Also notify LoongCollector if the exit was not caused by a signal
if [ ! -f /tasksite/tombstone ]; then
    echo "[$(date)] [nginx-demo] Unexpected exit, writing tombstone"
    touch /tasksite/tombstone
fi
exit $EXIT_CODE

3. Definir o período de tolerância de encerramento

Em spec.template.spec, defina um período de tolerância de encerramento suficientemente longo para permitir que o LoongCollector envie todos os logs restantes.

spec:
  # ... Your other existing spec configurations ...
  template:
    spec:
      terminationGracePeriodSeconds: 600  # 10-minute graceful stop period

4. Variáveis

5. Aplicar a configuração e verificar

1. Execute o comando a seguir para implantar as alterações:

   kubectl apply -f <YOUR-YAML>

2. Verifique o status do pod para confirmar se o contêiner do LoongCollector foi injetado com sucesso:

   kubectl describe pod <YOUR-POD-NAME>

   Se você visualizar dois contêineres (o contêiner da aplicação e o loongcollector) com o status Running, a injeção foi bem-sucedida.

Global Configurations:

• Configuration Name: Um nome personalizado para a configuração de coleta. Deve ser exclusivo dentro do Project. Não pode ser alterado após a criação. Convenções de nomenclatura:

  • Pode conter apenas letras minúsculas, dígitos, hifens (-) e sublinhados (_).

  • Deve começar e terminar com uma letra minúscula ou um dígito.

Input Configurations:

• Type: Selecione Text Log Collection.

• Logtail Deployment Mode: Selecione Sidecar.

• File Path Type:

  • Path in Container: Coleta arquivos de log de dentro de um contêiner.

  • Host Path: Coleta logs de serviços locais do host.

  • dockerFile: Se os arquivos de log que você deseja coletar estiverem localizados dentro de um contêiner (consulte a opção de caminho do contêiner acima), será necessário definir dockerFile: true na configuração de coleta. Caso contrário, o Logtail tratará a configuração como uma coleta de arquivos comuns e não conseguirá detectar os arquivos de log dentro do contêiner, resultando em perda de logs.

    • Console: Em Advanced Options, selecione a coleta de arquivos de contêiner. Alternativamente, o console também oferece um ponto de entrada separado para coleta de dados chamado Docker File - Container.

    • CRD: Defina dockerFile: true em inputDetail.

• File Path: O caminho para coleta de logs.

  • Linux: O caminho deve começar com uma barra (/). Por exemplo, /data/mylogs/**/*.log especifica todos os arquivos com extensão .log no diretório /data/mylogs e seus subdiretórios.

  • Windows: O caminho deve começar com uma letra de unidade, como C:\Program Files\Intel\**\*.Log.

• Maximum Directory Monitoring Depth: Especifica a profundidade máxima de diretório para o curinga ** no File Path. O valor padrão 0 monitora apenas o diretório atual.

• dockerFile: Especifica se o arquivo alvo está localizado dentro de um contêiner. Ao coletar arquivos de log de dentro de um contêiner no modo Sidecar, você deve definir este parâmetro como true. Caso contrário, o arquivo será coletado como um arquivo comum do host, o que não corresponde ao comportamento de coleta esperado. Tipo: Booleano. Obrigatório: Não. Valor padrão: false.

2. Processamento e estruturação de logs

Configure regras de processamento de logs para transformar logs brutos e não estruturados em dados estruturados e pesquisáveis. Isso melhora a eficiência das consultas e análises de logs. Recomendamos que você adicione uma amostra de log antes de configurar as regras:

Na página Logtail Configuration, na área Processor Configurations, clique em Add Sample Log e insira o conteúdo do log a ser coletado. O sistema identifica o formato do log com base na amostra e ajuda a gerar expressões regulares e regras de análise, simplificando a configuração.

Cenário 1: Lidar com logs multilinha (como stack traces do Java)

Logs como pilhas de exceções do Java e objetos JSON frequentemente abrangem várias linhas. No modo de coleta padrão, eles são divididos em vários registros incompletos, causando perda de contexto. Para evitar isso, ative o modo multilinha e configure uma expressão regular de início de linha para mesclar linhas consecutivas do mesmo log em uma única entrada completa.

Exemplo:

Log bruto sem nenhum processamento	No modo de coleta padrão, cada linha é tratada como um log independente. O stack trace é fragmentado e o contexto é perdido.	Com o modo multilinha ativado, uma expressão regular de início de linha identifica logs completos, preservando a estrutura semântica integral.
2025-11-13 10:52:20.557 ERROR [app-thread-0] --- java.sql.SQLException: No suitable driver found for jdbc:mysql://db.host:3306/prod_db at com.datastore.util.DataProcessor.save(DataProcessor.java:434) at io.awesomeapp.util.PaymentGateway.fetchData(PaymentGateway.java:463) at org.awesomeapp.util.UserService.processRequest(UserService.java:252) at io.datastore.service.DatabaseConnector.fetchData(DatabaseConnector.java:172) at org.datastore.service.UserService.fetchData(UserService.java:517)	No modo padrão, este log é dividido em 6 registros independentes: o primeiro contém apenas a mensagem de erro java.sql.SQLException, enquanto os 5 frames de pilha restantes (como at com.datastore.util.DataProcessor.save(...)) são armazenados como entradas separadas. Os frames de pilha não podem ser correlacionados com a exceção original por meio de consultas, exigindo esforço manual para reconstruir o contexto durante a solução de problemas.	Após ativar o modo multilinha, o log de erro java.sql.SQLException: No suitable driver found for jdbc:mysql://db.host:3306/prod_db juntamente com 5 frames de pilha (DataProcessor.save → UserService.fetchData) é coletado como um único registro no serviço de consulta de logs. A coluna de metadados também exibe IP, hostname, caminho do log e outros campos.

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

• Type: Selecione Custom ou Multi-line JSON.

  • Custom: O formato do log bruto não é fixo. Você deve configurar uma Regex to Match First Line para identificar a linha inicial de cada entrada de log.

    • Regex to Match First Line: Pode ser gerada automaticamente ou inserida manualmente. A expressão regular deve corresponder a uma linha completa de dados. Por exemplo, a expressão regular de correspondência no exemplo anterior é \[\d+-\d+-\w+:\d+:\d+,\d+]\s\[\w+]\s.*.

      • Geração automática: Clique em Generate Regex Automatically. Em seguida, na caixa de texto Log Sample, selecione o conteúdo do log a ser extraído e clique em Generate Regex.

        O modo legado de coleta de saída padrão do Kubernetes não suporta os recursos Add Log Sample e geração automática de expressão regular. Para testar uma expressão regular, crie um LogStore do tipo log de texto, teste a expressão regular nele e depois cole a expressão regular na configuração do Logtail do LogStore alvo.

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

  • Multi-line JSON: Quando todos os logs brutos estão no formato JSON padrão, o Simple Log Service lida automaticamente com quebras de linha dentro de um único log JSON.

  • Processing Method If Splitting Fails:

    • Discard: Se um segmento de texto não corresponder à regra de início de linha, ele será descartado.

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

  Cenário 2: Logs estruturados

  Quando os logs brutos são textos não estruturados ou semiestruturados, como logs de acesso do NGINX ou logs de saída de aplicações, a consulta e análise diretas costumam ser ineficientes. O Simple Log Service fornece vários plug-ins de análise de dados que podem converter automaticamente logs brutos de diferentes formatos em dados estruturados. Isso fornece uma base sólida para análises, monitoramento e alertas subsequentes.

  Exemplo:

  Log bruto sem nenhum processamento	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

  Etapas de configuração: Na área Processor Configurations da página Logtail Configurations:

  1. Adicionar um plug-in de análise: Clique em Add Processor e configure um plug-in, como um plug-in de análise de expressão regular, delimitador ou JSON, com base no formato do seu log. Por exemplo, para coletar logs do 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:

     log_format main  '$remote_addr - $remote_user [$time_local] "$request" ''$request_time $request_length ''$status $body_bytes_sent "$http_referer" ''"$http_user_agent"';

     Importante

     A definição de formato deve corresponder exatamente ao log_format no seu servidor. Caso contrário, a análise falhará.

  3. Descrições gerais dos parâmetros de configuração: Os parâmetros a seguir são comuns a muitos plug-ins de análise e possuem funções consistentes.

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

     • Retain Original Field if Parsing Fails: Recomendado. Se o plug-in falhar ao analisar um log, esta opção mantém o conteúdo bruto do log no campo original.

     • Retain Original Field if Parsing Succeeds: Se selecionada, esta opção mantém o conteúdo bruto do log mesmo após uma análise bem-sucedida.

  3. Filtragem de logs

  Grandes volumes de logs de baixo valor (como níveis DEBUG ou INFO) desperdiçam armazenamento, aumentam custos, reduzem a eficiência das consultas e apresentam riscos de vazamento de dados. Configure políticas de filtragem para uma coleta de logs eficiente e segura.

  Filtragem de conteúdo

  É possível filtrar com base nos campos de conteúdo do log, como coletar apenas logs com nível WARNING ou ERROR.

  Exemplo:

  Log bruto sem nenhum processamento

  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 de log a ser filtrado.

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

  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, na área Input Configurations > Other Input Configurations, ative a Collection Blacklist e clique em Add.

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

  • 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" em diretó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 arquivos em todos os subdiretórios sob /home/admin/ que começam com "dir".

    • /home/admin/*/dir: Ignora todos os arquivos em subdiretórios chamados "dir" no segundo nível sob o diretório /home/admin/. Por exemplo, arquivos no diretório /home/admin/a/dir são ignorados, enquanto arquivos no diretório /home/admin/a/b/dir são coletados.

  Filtragem de contêineres

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

  Etapas de configuração: Na página Logtail Configurations, na área Input Configurations, ative a Container Filtering e clique em Add.

  Múltiplas condições têm uma relação "AND". Toda correspondência de expressão regular baseia-se no mecanismo de expressões regulares RE2 do Go, que possui algumas limitações em comparação com mecanismos como PCRE. Siga as diretrizes em Apêndice: Limitações de expressões regulares (filtragem de contêineres) ao escrever expressões regulares.

  • 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 contêineres com base nos rótulos de Pod de seus pods hospedeiros.

  • Correspondência regex de nome de Pod K8s: Filtra contêineres com base no nome do Pod.

  • Correspondência regex de Namespace K8s: Filtra contêineres com base no namespace.

  • Correspondência regex de nome de contêiner K8s: Filtra contêineres com base no nome.

  • Lista de bloqueios/permissões de rótulos de contêiner: Filtra contêineres com base em seus rótulos. Este método destina-se ao docker e não é recomendado para Kubernetes.

  4. Classificação de logs

  Quando várias aplicações compartilham o mesmo formato de log, distinguir as origens dos logs pode ser difícil. Configure tópicos de log e marcação de logs para automatizar a associação de contexto e a classificação lógica.

  Tópicos de log

  Quando várias aplicações possuem logs com o mesmo formato, mas caminhos diferentes (como /apps/app-A/run.log e /apps/app-B/run.log), gere um tópico para diferenciar os logs de cada service.

  Procedimento: Em Global Configurations > Other Global Configurations > Log Topic Type, selecione um método para gerar tópicos. Os três tipos a seguir são suportados:

  • 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 do servidor como campo __topic__ para upload. Adequado para cenários onde os logs são categorizados por host.

  • Custom: O formato é customized://<custom_topic_name>, por exemplo, customized://app-login. Adequado para cenários de tópicos estáticos com identificadores de service 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. Adequado para situações onde vários 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, mas os subcaminhos e nomes de arquivos são iguais, a origem não pode ser distinguida apenas pelo nome do arquivo. Por exemplo:

    /data/logs
    ├── userA
    │   └── serviceA
    │       └── service.log
    ├── userB
    │   └── serviceA
    │       └── service.log
    └── userC
        └── serviceA
            └── service.log

    Neste caso, configure 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.

    Regra de extração de caminho de arquivo: Baseada em grupos de captura de expressão regular

    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. As regras são as seguintes:

    Na expressão regular para o caminho do arquivo, é necessário escapar a barra (/).

    Tipo de grupo de captura	Cenário	Campo gerado	Exemplo de regex	Exemplo de caminho correspondente	Exemplo de campo gerado
    Grupo de captura único (apenas um (.*?))	Apenas uma dimensão é necessária para distinguir a origem (como nome de usuário, ambiente)	Gera o campo __topic__	\/logs\/(.*?)\/app\.log	/logs/userA/app.log	__topic__: userA
    Múltiplos grupos de captura não nomeados (vários (.*?))	Várias dimensões são necessárias para distinguir a origem, mas nenhuma tag semântica é requerida	Gera um campo de tag __tag__:__topic_{i}__, onde {i} é o número ordinal 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>.*?))	Várias dimensões são necessárias para distinguir a origem, e deseja-se que os significados dos campos sejam claros para facilitar consultas e análises	Gera um campo de tag __tag__:{name}	\/logs\/(?P<user>.*?)\/(?P<service>.*?)\/app\.log	/logs/userA/svcA/app.log	__tag__:user:userA; __tag__:service:svcA

  Marcação de logs

  Ative o enriquecimento de tags de log para extrair informações-chave das variáveis de ambiente do contêiner ou dos rótulos de Pod do Kubernetes como tags para agrupamento refinado de logs.

  Etapas de configuração: Na área Input Configurations da página Logtail Configurations, ative o Log Tag Enrichment e clique em Add.

  • Environment Variables: Configure o nome da variável de ambiente e o nome da tag. O valor da variável de ambiente é armazenado como o valor da tag.

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

    • Nome da Tag: O nome da tag.

  • Pod Labels: Configure o nome do rótulo do Pod e o nome da tag. O valor do rótulo do Pod é armazenado como o valor da tag.

    • Nome do Rótulo do Pod: O nome do rótulo do Pod do Kubernetes a ser extraído.

    • Nome da Tag: O nome da 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 para múltiplos LogStores, configure destinos de saída adicionais.

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

  Importante

  • A distribuição 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, a configuração de coleta deixa de aparecer na lista de configurações de coleta do LogStore atual. Para visualizar, modificar ou excluir uma configuração de distribuição para múltiplos destinos, consulte Gerenciar configurações de distribuição para múltiplos destinos.

  Etapas de configuração: Na área Output Configurations da página Logtail 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: lz4 e zstd são suportados.

     • Route Settings: Roteie logs com base em campos de tag. O sistema envia os logs correspondentes para o LogStore de destino. Se esta configuração estiver vazia, o sistema enviará todos os logs coletados para este destino.

       • Tag Name: O nome do campo de tag usado para roteamento. Insira apenas o nome do campo (por exemplo, __path__), sem o prefixo __tag__:. Os campos de tag dividem-se em duas categorias:

         As tags estão descritas em Gerenciar tags de coleta do LoongCollector .

         • Relacionadas ao agente: Referem-se ao agente de coleta e independem de plug-ins. Exemplos incluem __hostname__ e __user_defined_id__.

         • Relacionadas ao plug-in de entrada: Fornecidas por plug-ins de entrada para enriquecer logs com informações contextuais. Exemplos incluem __path__ para coleta de arquivos e _pod_name_ ou _container_name_ para coleta no Kubernetes.

       • Tag Value: Se o campo de tag de um log corresponder a este valor, o sistema enviará o log para este LogStore de destino.

       • Discard this tag?: Se ativado, o sistema remove este campo de tag dos logs antes de enviá-los.

  Etapa 4: Configurar consulta e análise

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

  • O sistema ativa o índice de texto completo por padrão, permitindo realizar buscas por palavras-chave no conteúdo original do log.

  • Para realizar consultas precisas por campo, aguarde o carregamento dos Preview Data na página e clique em Automatic Index Generation. O Simple Log Service gera um índice de campo com base na primeira entrada dos dados de visualização.

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

  Etapa 5: Visualizar logs enviados

  Depois de criar uma configuração de coleta e aplicá-la a um grupo de máquinas, ela é implantada automaticamente e começa a coletar logs incrementais.

  1. Verificar novas entradas de log: O LoongCollector coleta apenas logs incrementais. Execute tail -f /path/to/your/log/file e use sua aplicação para gerar novas entradas de log.

  2. Consultar logs: Acesse a página Search & Analyze do LogStore alvo e clique em Search & Analyze. O intervalo de tempo padrão são os últimos 15 minutos. Verifique se novos logs aparecem. Os campos padrão para logs de texto de contêiner são os seguintes:

     Parâmetro	Descrição
     tag:hostname	O nome do host do contêiner.
     tag:path	O caminho do arquivo de log no contêiner.
     tag:container_ip	O endereço ip do contêiner.
     tag:image_name	O nome da imagem usada pelo contêiner. Nota Se várias imagens tiverem o mesmo hash, mas nomes ou tags diferentes, a configuração de coleta selecionará um dos nomes com base no hash. Não há garantia de que o nome selecionado corresponda ao definido no arquivo YAML.
     tag:pod_name	O nome do pod.
     tag:namespace	O namespace ao qual o pod pertence.
     tag:pod_uid	O identificador exclusivo (UID) do pod.

  Configurações essenciais para integridade dos logs

  Estes parâmetros de configuração afetam diretamente a integridade e a confiabilidade da coleta de logs.

  Configuração de recursos do LoongCollector

  A alocação adequada de recursos é fundamental para o desempenho da coleta em cenários de alto volume. Parâmetros principais:

  # Configure CPU and memory resources based on the log generation rate
  resources:
    limits:
      cpu: "2000m"       
      memory: "2Gi"
  # Parameters that affect collection performance
  env:
    - name: cpu_usage_limit
      value: "2"      
    - name: mem_usage_limit
      value: "2048"  
    - name: max_bytes_per_sec
      value: "209715200"
    - name: process_thread_count
      value: "8"                             
    - name: send_request_concurrency
      value: "20"                            
  

  Para configurar o Logtail com base no seu volume de dados, consulte Tipos de rede do Logtail, parâmetros de inicialização e arquivos de configuração.

  Configuração de cotas no servidor

  Limites de cota no servidor ou problemas de rede podem bloquear a transmissão de dados, criando contrapressão que afeta a integridade dos logs. Use o CloudLens para SLS para monitorar cotas de recursos do Project.

  Otimização da configuração inicial de coleta

  A política inicial de coleta de arquivos na inicialização do pod afeta a integridade dos logs, especialmente em cenários de alta vazão.

  O tamanho inicial de coleta especifica onde a coleta começa em um novo arquivo. Padrão: 1024 KB.

  • Se um arquivo for menor que 1024 KB, a coleta começa do início dele.

  • Se um arquivo for maior que 1024 KB, a coleta começa 1024 KB antes do final dele.

  • O tamanho inicial de coleta pode variar de 0 a 10.485.760 KB (10 GB).

  enable_full_drain_mode

  Garante que o LoongCollector conclua toda a coleta e transmissão de dados antes de encerrar ao receber um sinal SIGTERM.

  # Parameter that affects collection integrity
  env:
    - name: enable_full_drain_mode
      value: "true"                          # Enable full drain mode
  

  FAQ

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

  As configurações de distribuição para múltiplos destinos aplicam-se a vários LogStores e devem ser gerenciadas no nível do Project:

  1. Faça login no console do Log Service e clique no nome do Project alvo.

  2. Na página do Project alvo, no painel de navegação à esquerda, clique em Resources > Configurations.

     Nota

     Esta página centraliza o gerenciamento de todas as configurações de coleta dentro do Project, incluindo aquelas remanescentes após a exclusão de um LogStore.

  Próximas etapas

  1. Visualização de dados: Utilize um painel de visualização para monitorar tendências em métricas principais.

  2. Alertas automatizados para anomalias de dados: Configure políticas de alerta para detectar anomalias do sistema em tempo real.

  3. O SLS coleta apenas logs incrementais. Para coletar logs históricos, consulte Importar arquivos de log históricos.

  Apêndice: Exemplo de YAML

  Uma configuração completa do Kubernetes com um contêiner de aplicação Nginx e um contêiner sidecar do LoongCollector.

  Antes de usar esta configuração, substitua os seguintes espaços reservados:

  1. Substitua ${your_aliyun_user_id} pelo ID da sua conta Alibaba Cloud.

  2. Substitua ${your_machine_group_user_defined_id} pelo identificador personalizado do grupo de máquinas criado na Etapa 3. O valor deve corresponder exatamente.

  3. Substitua ${your_region_config} pelo nome da configuração que corresponde à região e ao tipo de rede do seu Project no SLS.

     Exemplo: Se o seu Project estiver na região China (Hangzhou), use cn-hangzhou para acesso à rede interna ou cn-hangzhou-internet para acesso à rede pública.

  Tarefas de curta duração (Job/CronJob)

  apiVersion: batch/v1
  kind: Job
  metadata:
    name: demo-job
  spec:
    backoffLimit: 3                   
    activeDeadlineSeconds: 3600        
    completions: 1                     
    parallelism: 1                    
    template:
      spec:
        restartPolicy: Never         
        terminationGracePeriodSeconds: 300 
        containers:
          # Application container
          - name: demo-job
            image: debian:bookworm-slim
            command: ["/bin/bash", "-c"]
            args:
              - |
                # Wait for LoongCollector to be ready.
                echo "[$(date)] Business: Waiting for LoongCollector to be ready..."
                until [[ -f /tasksite/cornerstone ]]; do 
                  sleep 1
                done
                echo "[$(date)] Business: LoongCollector is ready, starting business logic"
                # Run the application logic.
                echo "Hello, World!" >> /app/logs/business.log
                # Save the exit code.
                retcode=$?
                echo "[$(date)] Business: Task completed with exit code: $retcode"
                # Notify LoongCollector that the task is finished.
                touch /tasksite/tombstone
                echo "[$(date)] Business: Tombstone created, exiting"
                exit $retcode
            # Resource requests and limits
            resources:
              requests:
                cpu: "100m"
                memory: "128Mi"
              limits:
                cpu: "500"
                memory: "512Mi"
            # volume mounts
            volumeMounts:
              - name: app-logs
                mountPath: /app/logs
              - name: tasksite
                mountPath: /tasksite
          # LoongCollector sidecar container
          - name: loongcollector
            image: aliyun-observability-release-registry.cn-hongkong.cr.aliyuncs.com/loongcollector/loongcollector:v3.1.1.0-20fa5eb-aliyun
            command: ["/bin/bash", "-c"]
            args:
              - |
                echo "[$(date)] LoongCollector: Starting initialization"
                # Start the LoongCollector service.
                /etc/init.d/loongcollectord start
                # Wait for the configuration to download and the service to be ready.
                sleep 15
                # Verify the service status.
                if /etc/init.d/loongcollectord status; then
                  echo "[$(date)] LoongCollector: Service started successfully"
                  touch /tasksite/cornerstone
                else
                  echo "[$(date)] LoongCollector: Failed to start service"
                  exit 1
                fi
                # Wait for the application container to finish.
                echo "[$(date)] LoongCollector: Waiting for business container to complete"
                until [[ -f /tasksite/tombstone ]]; do 
                  sleep 2
                done
                echo "[$(date)] LoongCollector: Business completed, waiting for log transmission"
                # Allow sufficient time to send remaining logs.
                sleep 30
                echo "[$(date)] LoongCollector: Stopping service"
                /etc/init.d/loongcollectord stop
                echo "[$(date)] LoongCollector: Shutdown complete"
            # health check
            livenessProbe:
              exec:
                command: ["/etc/init.d/loongcollectord", "status"]
              initialDelaySeconds: 30
              periodSeconds: 10
              timeoutSeconds: 5
              failureThreshold: 3
            # Resource requests and limits
            resources:
              requests:
                cpu: "100m"
                memory: "128Mi"
              limits:
                cpu: "500m"
                memory: "512Mi"
            # environment variables
            env:
              - name: ALIYUN_LOGTAIL_USER_ID
                value: "your-user-id"
              - name: ALIYUN_LOGTAIL_USER_DEFINED_ID
                value: "your-user-defined-id"
              - name: ALIYUN_LOGTAIL_CONFIG
                value: "/etc/ilogtail/conf/cn-hongkong/ilogtail_config.json"
              - name: ALIYUN_LOG_ENV_TAGS
                value: "_pod_name_|_pod_ip_|_namespace_|_node_name_"
              # Inject pod metadata.
              - name: "_pod_name_"
                valueFrom:
                  fieldRef:
                    fieldPath: metadata.name
              - name: "_pod_ip_"
                valueFrom:
                  fieldRef:
                    fieldPath: status.podIP
              - name: "_namespace_"
                valueFrom:
                  fieldRef:
                    fieldPath: metadata.namespace
              - name: "_node_name_"
                valueFrom:
                  fieldRef:
                    fieldPath: spec.nodeName
            # volume mounts
            volumeMounts:
              - name: app-logs
                mountPath: /app/logs
                readOnly: true
              - name: tasksite
                mountPath: /tasksite
              - name: tz-config
                mountPath: /etc/localtime
                readOnly: true
        # Volume definitions
        volumes:
          - name: app-logs
            emptyDir: {}
          - name: tasksite
            emptyDir:
              medium: Memory
              sizeLimit: "10Mi"
          - name: tz-config
            hostPath:
              path: /usr/share/zoneinfo/Asia/Shanghai
  

  Serviços de longa duração (Deployment / StatefulSet)

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: nginx-demo
    namespace: production
    labels:
      app: nginx-demo
      version: v1.0.0
  spec:
    replicas: 3
    strategy:
      type: RollingUpdate
      rollingUpdate:
        maxUnavailable: 1      
        maxSurge: 1          
    selector:
      matchLabels:
        app: nginx-demo
    template:
      metadata:
        labels:
          app: nginx-demo
          version: v1.0.0    
      spec:
        terminationGracePeriodSeconds: 600  # 10-minute graceful shutdown period
        containers:
          # Application container - Web application
          - name: nginx-demo
            image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6          
            # Startup command and signal handling
            command: ["/bin/sh", "-c"]
            args:
              - |
                # Define the signal handler.
                _term_handler() {
                    echo "[$(date)] [nginx-demo] Caught SIGTERM, starting graceful shutdown..."
                    # Send the QUIT signal to Nginx for a graceful stop.
                    if [ -n "$NGINX_PID" ]; then
                        kill -QUIT "$NGINX_PID" 2>/dev/null || true
                        echo "[$(date)] [nginx-demo] Sent SIGQUIT to Nginx PID: $NGINX_PID"
                        # Wait for Nginx to stop gracefully.
                        wait "$NGINX_PID"
                        EXIT_CODE=$?
                        echo "[$(date)] [nginx-demo] Nginx stopped with exit code: $EXIT_CODE"
                    fi
                    # Notify LoongCollector that the application container has stopped.
                    echo "[$(date)] [nginx-demo] Writing tombstone file"
                    touch /tasksite/tombstone
                    exit $EXIT_CODE
                }
                # Register the signal handler.
                trap _term_handler SIGTERM SIGINT SIGQUIT
                # Wait for LoongCollector to be ready.
                echo "[$(date)] [nginx-demo]: Waiting for LoongCollector to be ready..."
                until [[ -f /tasksite/cornerstone ]]; do 
                  sleep 1
                done
                echo "[$(date)] [nginx-demo]: LoongCollector is ready, starting business logic"
                # Start Nginx.
                echo "[$(date)] [nginx-demo] Starting Nginx..."
                nginx -g 'daemon off;' &
                NGINX_PID=$!
                echo "[$(date)] [nginx-demo] Nginx started with PID: $NGINX_PID"
                # Wait for the Nginx process to exit.
                wait $NGINX_PID
                EXIT_CODE=$?
                # If the process exits without a signal, notify LoongCollector.
                if [ ! -f /tasksite/tombstone ]; then
                    echo "[$(date)] [nginx-demo] Unexpected exit, writing tombstone"
                    touch /tasksite/tombstone
                fi
                exit $EXIT_CODE
            # Resource requests and limits
            resources:
              requests:
                cpu: "200m"
                memory: "256Mi"
              limits:
                cpu: "1000m"
                memory: "1Gi"
            # volume mounts
            volumeMounts:
              - name: nginx-logs
                mountPath: /var/log/nginx
              - name: tasksite
                mountPath: /tasksite
              - name: tz-config
                mountPath: /etc/localtime
                readOnly: true
          # LoongCollector sidecar container
          - name: loongcollector
            image: aliyun-observability-release-registry.cn-shenzhen.cr.aliyuncs.com/loongcollector/loongcollector:v3.1.1.0-20fa5eb-aliyun
            command: ["/bin/bash", "-c"]
            args:
              - |
                echo "[$(date)] LoongCollector: Starting initialization"
                # Start the LoongCollector service.
                /etc/init.d/loongcollectord start
                # Wait for the configuration to download and the service to be ready.
                sleep 15
                # Verify the service status.
                if /etc/init.d/loongcollectord status; then
                  echo "[$(date)] LoongCollector: Service started successfully"
                  touch /tasksite/cornerstone
                else
                  echo "[$(date)] LoongCollector: Failed to start service"
                  exit 1
                fi
                # Wait for the application container to finish.
                echo "[$(date)] LoongCollector: Waiting for business container to complete"
                until [[ -f /tasksite/tombstone ]]; do 
                  sleep 2
                done
                echo "[$(date)] LoongCollector: Business completed, waiting for log transmission"
                # Allow sufficient time to send remaining logs.
                sleep 30
                echo "[$(date)] LoongCollector: Stopping service"
                /etc/init.d/loongcollectord stop
                echo "[$(date)] LoongCollector: Shutdown complete"
            # health check
            livenessProbe:
              exec:
                command: ["/etc/init.d/loongcollectord", "status"]
              initialDelaySeconds: 30
              periodSeconds: 10
              timeoutSeconds: 5
              failureThreshold: 3
            # Resource requests and limits
            resources:
              requests:
                cpu: "100m"
                memory: "128Mi"
              limits:
                cpu: "2000m"
                memory: "2048Mi"
            # environment variables
            env:
              - name: ALIYUN_LOGTAIL_USER_ID
                value: "${your_aliyun_user_id}"
              - name: ALIYUN_LOGTAIL_USER_DEFINED_ID
                value: "${your_machine_group_user_defined_id}"
              - name: ALIYUN_LOGTAIL_CONFIG
                value: "/etc/ilogtail/conf/${your_region_config}/ilogtail_config.json"
              # Enable full drain mode to send all logs when the pod stops.
              - name: enable_full_drain_mode
                value: "true"
              # Append pod environment information as log tags.
              - name: "ALIYUN_LOG_ENV_TAGS"
                value: "_pod_name_|_pod_ip_|_namespace_|_node_name_|_node_ip_"
              # Get pod and node information.
              - name: "_pod_name_"
                valueFrom:
                  fieldRef:
                    fieldPath: metadata.name
              - name: "_pod_ip_"
                valueFrom:
                  fieldRef:
                    fieldPath: status.podIP
              - name: "_namespace_"
                valueFrom:
                  fieldRef:
                    fieldPath: metadata.namespace
              - name: "_node_name_"
                valueFrom:
                  fieldRef:
                    fieldPath: spec.nodeName
              - name: "_node_ip_"
                valueFrom:
                  fieldRef:
                    fieldPath: status.hostIP
            # volume mounts
            volumeMounts:
              - name: nginx-logs
                mountPath: /var/log/nginx
                readOnly: true
              - name: tasksite
                mountPath: /tasksite
              - name: tz-config
                mountPath: /etc/localtime
                readOnly: true
        # Volume definitions
        volumes:
          - name: nginx-logs
            emptyDir: {}
          - name: tasksite
            emptyDir:
              medium: Memory
              sizeLimit: "50Mi"
          - name: tz-config
            hostPath:
              path: /usr/share/zoneinfo/Asia/Shanghai
  

  Apêndice: Processadores nativos

  Na página Logtail Configuration, na área Processor Configurations, é possível adicionar 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, localize a configuração do Logtail desejada e clique em Manage Logtail Configuration na coluna Actions.

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

  Esta seção apresenta apenas plug-ins de processamento comumente usados que cobrem cenários típicos de processamento de logs. Para 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):

  • Plug-ins de processamento nativos e de extensão podem ser usados independentemente ou em combinação, conforme necessário.

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

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

  Restrição de ordem:

  Todos os plug-ins são executados sequencialmente na ordem em que foram configurados, formando uma cadeia de processamento. Nota: 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 Regex

  Use expressões regulares para extrair campos dos logs em pares chave-valor para consulta e análise independentes.

  Exemplo:

  Log bruto sem nenhum processamento

  Usando o plug-in de análise de expressão regular

  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

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

  • Regular Expression: Uma expressão regular para corresponder ao conteúdo do log. Pode ser gerada automaticamente ou inserida manualmente.

    • Geração automática:

      • Clique em Generate.

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

      • Clique em Generate Regular Expression.

        Por exemplo, se você colar um log no formato Apache Combined na caixa Log Sample, ele conterá campos como ip do cliente, timestamp, método e caminho da requisição, código de status, Referer e User-Agent.

    • Entrada manual: Manually Enter Regular Expression com base no formato do log.

    Após inserir a expressão, clique em Validate para testar se ela analisa corretamente o conteúdo do log.

  • Extracted Field: Defina um nome de campo (chave) para cada parte do conteúdo do log extraído (valor).

  • Para obter informações sobre outros parâmetros, consulte as descrições gerais de parâmetros em Cenário 2: Logs estruturados.

  Análise com delimitador

  Utilize a análise com delimitador para dividir o conteúdo do log em pares chave-valor. Suporta delimitadores de caractere único e múltiplos caracteres.

  Exemplo:

  Log bruto sem nenhum processamento	Dividir campos pelo caractere especificado ,
  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 seção Processor Configurations da página Logtail Configurations, clique em Add Processor e selecione Native Processor > Data Parsing (Delimiter Mode).

  • Delimiter: O caractere usado para dividir o conteúdo do log.

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

  • Quote: Quando o valor de um campo contém o delimitador, especifique um caractere de aspas para envolver o campo e evitar divisões incorretas.

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

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

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

    • Podem ter até 128 bytes de comprimento.

  • Para obter informações sobre outros parâmetros, consulte as descrições gerais de parâmetros em Cenário 2: Logs estruturados.

  Análise json

  Analisa logs formatados como objetos json em pares chave-valor.

  Exemplo:

  Log bruto sem nenhum processamento	Extração automática de chaves-valores json padrão
  {"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 seção Processor Configurations da página Logtail Configurations, clique em Add Processor e selecione Native Processor > Data Parsing (JSON Mode).

  • Original Field: O valor padrão é content. Este campo contém o log bruto a ser analisado.

  • Para obter informações sobre outros parâmetros, consulte as descrições gerais de parâmetros em Cenário 2: Logs estruturados.

  Expansão de campos json

  Expande um campo contendo um objeto json aninhado em múltiplos pares chave-valor.

  Exemplo:

  Log bruto sem nenhum processamento	Profundidade de expansão: 0, usando a profundidade de expansão como prefixo	Profundidade de expansão: 1, usando a profundidade de expansão como prefixo
  {"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 seção Processor Configurations da página Logtail Configurations, clique em Add Processor e selecione Extended Processor > Expand JSON Field.

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

  • JSON Expansion Depth: O nível de expansão do objeto json. Um valor de 0 (o padrão) expande totalmente o objeto, 1 expande apenas o nível atual, e assim por diante.

  • Character to Concatenate Expanded Keys: O caractere usado para unir nomes de campos durante a expansão json. O padrão é um sublinhado (_).

  • Name Prefix of Expanded Keys: Um prefixo a ser adicionado aos nomes dos campos após a expansão json.

  • Expand Array: Ative esta opção para expandir arrays em pares chave-valor com índices.

    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 para concluir o mapeamento.

  • Para obter informações sobre outros parâmetros, consulte as descrições gerais de parâmetros em Cenário 2: Logs estruturados.

  Análise de array json

  Utilize a função json_extract function para extrair objetos json de um array json.

  Exemplo:

  Log bruto sem nenhum processamento	Extrair estrutura de array json
  [{"key1":"value1"},{"key2":"value2"}]	json1:{"key1":"value1"} json2:{"key2":"value2"}

  Procedimento: Na página Logtail Configuration, na área Processor Configurations, alterne o Processing Method para SPL, configure a SPL Statement e use a função json_extract para extrair objetos json do array json.

  Exemplo: Extrair elementos do array json no campo de log content e armazenar os resultados em novos campos json1 e json2.

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

  Análise de logs Apache

  Estruture o conteúdo do log com base nas definições do seu arquivo de configuração de log do Apache, analisando-o em múltiplos pares chave-valor.

  Exemplo:

  Log bruto sem nenhum processamento	Análise do Formato de Log Comum Apache 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 seção Processor Configurations da página Logtail Configurations, clique em Add Processor e selecione Native Processor > Data Parsing (Apache Mode).

  • Log Format: combined

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

    Importante

    Garanta que o conteúdo preenchido automaticamente corresponda exatamente à definição LogFormat no arquivo de configuração do Apache do seu servidor (geralmente /etc/apache2/apache2.conf).

  • Para obter informações sobre outros parâmetros, consulte as descrições gerais de parâmetros em Cenário 2: Logs estruturados.

  Mascaramento de Dados

  Mascare dados sensíveis nos logs.

  Exemplo:

  Log bruto sem nenhum processamento	Resultado do mascaramento
  [{'account':'1812213231432969','password':'04a23f38'}, {'account':'1812213685634','password':'123a'}]	[{'account':'1812213231432969','password':'********'}, {'account':'1812213685634','password':'********'}]

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

  • Original Field: O campo de origem que contém o conteúdo do log antes da análise.

  • Data Masking Method:

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

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

  • Replacement String: Ao selecionar const para Data Masking Method, insira uma string para substituir o conteúdo sensível.

  • Content Expression that Precedes Replaced Content: Usado para localizar conteúdo sensível. Configure usando a sintaxe RE2.

  • Content Expression to Match Replaced Content: A expressão para o conteúdo sensível. Configure usando a sintaxe RE2.

  Análise de Tempo

  Analisa o campo de tempo no log e define o resultado da análise como o campo __time__ do log.

  Exemplo:

  Log bruto sem nenhum processamento	Análise de tempo
  {"level":"INFO","timestamp":"2025-09-23T19:11:47+0800","cluster":"yilu-cluster-0728","message":"User logged in successfully","userId":"user-123"}	Na visualização de detalhes de log do SLS, o log json é analisado corretamente em campos estruturados. Cada campo (cluster, level, message, time, userId) e seu valor são exibidos independentemente.

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

  • Original Field: O campo de origem que contém o conteúdo do log antes da análise.

  • Time Format: Defina o formato de tempo correspondente com base no conteúdo de tempo no log.

  • Time Zone: Selecione o fuso horário do campo de tempo do log. Por padrão, o fuso horário da máquina é usado, que é o fuso horário do ambiente onde o processo do LoongCollector (Logtail) está em execução.

  Limitações de expressões regulares para filtragem de contêineres

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

  1. Diferenças na sintaxe de grupos nomeados

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

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

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

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

  O mecanismo RE2 não suporta os seguintes recursos comuns, porém complexos, de expressões regulares:

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

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

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

  • Referências de subprograma: (?&name) e (?P>name)

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

  3. Recomendações

  Utilize ferramentas como o Regex101 para depurar expressões regulares. Selecione o modo Golang (RE2) para garantir compatibilidade. Sintaxes não suportadas impedem a análise ou correspondência correta.