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 as montagens do contêiner da aplicação

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

   Certifique-se de que o contêiner da aplicação grave os 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, adicione 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 encerramento gracioso

Em spec.template.spec, defina um período de encerramento gracioso longo o suficiente 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 seguinte comando para implantar as alterações:

   kubectl apply -f <YOUR-YAML>

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

   kubectl describe pod <YOUR-POD-NAME>

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

Global Configurations:

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

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

  • 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ço locais do host.

• 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 a 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 de 0 monitora apenas o diretório atual.

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.

Configure regras de processamento para estruturar logs brutos em pares chave-valor pesquisáveis. Primeiro, adicione uma amostra de log:

Na seção Processor Configurations da página Logtail Configuration, clique em Add Sample Log e insira uma amostra de log. O sistema identifica o formato e gera regras de análise automaticamente.

Cenário 2: Logs estruturados

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: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/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. Adicione um plugin de análise: Clique em Add Processor e configure um plugin, como expressão regular, delimitador ou plugin de análise JSON, de acordo com o formato do seu log. Por exemplo, para coletar logs 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 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"';

   null

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

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

   • Campo original: Especifica o campo de origem a ser analisado. O padrão é content, que corresponde à entrada de log coletada inteira.

   • Manter campo original se a análise falhar: Recomendado. Se o plugin não conseguir analisar um log, esta opção mantém o conteúdo bruto do log no campo original.

   • Manter campo original se a análise for bem-sucedida: Se selecionada, esta opção mantém o conteúdo bruto do log mesmo após a análise bem-sucedida.

Por padrão, todos os logs são enviados para o logstore atual com compressão lz4. Para distribuir logs para vários logstores, configure destinos de saída adicionais.

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

• O índice de texto completo é habilitado por padrão, permitindo buscas por palavras-chave no conteúdo bruto dos logs.

• Para consultas precisas por campo, aguarde o carregamento de Preview Data e clique em Automatic Index Generation. O SLS gera um índice de campo com base na primeira entrada dos dados de pré-visualização.

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

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 de destino e clique em Search & Analyze. O intervalo de tempo padrã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 utilizada pelo contêiner. null Se várias imagens possuírem o mesmo hash, mas nomes ou tags diferentes, a configuração de coleta seleciona 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.

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

As configurações de distribuição para múltiplos destinos se aplicam 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 de destino.

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

   null

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

Na seção Processor Configurations da página Logtail Configuration, adicione processadores para estruturar logs brutos. Para adicionar um plugin de processamento a uma configuração existente:

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

2. Clique no ícone antes 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 os plugins de processamento mais utilizados, que cobrem os casos de uso comuns de processamento de log. Para mais recursos, consulte Extended processors.

Parsing com regex

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

Parsing com delimitador

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

Parsing JSON

{"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

Expansão de campos JSON

{"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"}}}}

Parsing de array JSON

[{"key1":"value1"},{"key2":"value2"}]

json1:{"key1":"value1"}
json2:{"key2":"value2"}

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

Parsing de log Apache

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]

Mascaramento de dados

[{'account':'1812213231432969','password':'04a23f38'}, {'account':'1812213685634','password':'123a'}]

[{'account':'1812213231432969','password':'********'}, {'account':'1812213685634','password':'********'}]

Parsing de tempo

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

1. Diferenças de sintaxe de grupos nomeados

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 motor RE2 não suporta os seguintes recursos de expressão regular comuns, porém complexos:

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

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

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

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

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

3. Recomendações

Use ferramentas como o Regex101 para depurar expressões regulares. Selecione o modo Golang (RE2) para garantir compatibilidade. Sintaxe não suportada impede que o plugin realize o parsing ou a correspondência corretamente.