Home Comunidade Eventos YouTube Networks Desafios // produtos Academy News CTI | CVE Contato

03 - Tamanho e Rotação

02 - Persistência vs Volátil 05 - Journald (Coleta de Logs)
video explicativo
Video explicativoEspaco reservado para o video desta anotação — adicione video: https://youtu.be/... no frontmatter da nota.

1. Algoritmos de Limitação de Espaço e Cotas de Disco

O systemd-journald implementa um subsistema autônomo e contínuo de verificação de limites de armazenamento. O controle de cota é configurado no arquivo /etc/systemd/journald.conf e é dividido rigidamente entre o ecossistema não volátil (gravado em /var/log/journal/) e o ecossistema volátil em memória (residente em /run/log/journal/).

A alocação de cota aplica a técnica de Cota Dinâmica Reativa, onde o daemon calcula a área de armazenamento disponível inspecionando duas variáveis principais do sistema de arquivos através da chamada de sistema statvfs(): a capacidade total da partição e o espaço livre restante no disco.

1.1. Matriz de Parâmetros de Cota (Persistente vs. Volátil)

As diretivas que governam o espaço máximo ocupado pelo journal em disco (System*) e em RAM (Runtime*) obedecem à seguinte taxonomia:

[Journal]
# Limites para armazenamento persistente (/var/log/journal/)
SystemMaxUse=4G
SystemKeepFree=1G
SystemMaxFileSize=512M
SystemMaxFiles=100

# Limites para armazenamento volátil (/run/log/journal/)
RuntimeMaxUse=512M
RuntimeKeepFree=128M
RuntimeMaxFileSize=64M
RuntimeMaxFiles=100

Dicionário de Parâmetros Arquiteturais:

  1. SystemMaxUse= / RuntimeMaxUse=: Define o limite absoluto de espaço em disco/RAM que o conjunto total de arquivos .journal pode consumir no diretório correspondente.
    * Comportamento Padrão: Se omitido, o systemd-journald calcula um teto dinâmico equivalente a 10% do tamanho total da partição física montada.

  2. SystemKeepFree= / RuntimeKeepFree=: Define a margem de segurança de espaço livre que o journald obrigatoriamente deve reservar para o restante do sistema operacional na partição.
    * Comportamento Padrão: Se omitido, é definido automaticamente em 15% do tamanho total da partição. O journald reduzirá preemptivamente o seu próprio consumo para manter essa margem intacta se outros processos começarem a encher a partição /var.

  3. Regra do Limite Mais Restritivo (The Tighter Constraint Rule): O teto efetivo de espaço utilizado é calculado aplicando uma operação binária MIN() entre o valor declarado em SystemMaxUse= e o resultado derivado da subtração (Espaço_Total_Partição - SystemKeepFree). O menor número resultante prevalece como teto inflexível de gravação.

  4. SystemMaxFileSize= / RuntimeMaxFileSize=: O tamanho máximo que um único arquivo binário .journal ativo (ex: system.journal) pode atingir antes de ser forçado a sofrer rotação atômica.
    * Comportamento Padrão: Corresponde a aproximadamente 1/8 (12.5%) do valor computado para o SystemMaxUse=. Isso impede que um único arquivo monstrutivo monopolize o índice de busca, distribuindo os registros em múltiplos arquivos rotacionados.

  5. SystemMaxFiles= / RuntimeMaxFiles=: O número máximo de arquivos .journal preservados (somando o arquivo ativo e os arquivos arquivados/rotacionados). Atingido este limite, a rotação do arquivo ativo forçará a purga imediata do arquivo arquivado mais antigo.

2. A Mecânica da Rotação Atômica (File Rotation)

A rotação de arquivos no systemd-journald é o processo pelo qual um arquivo binário ativo de gravação (system.journal) é selado contra modificações futuras, tornando-se um arquivo estático e somente leitura, abrindo caminho para a criação de um novo arquivo ativo limpo.

+-------------------------------------------------------------------------+
|                  PROCESSO DE ROTAÇÃO ATÔMICA                            |
|                                                                         |
|   1. Gatilho Disparado (Tamanho, Tempo, Cota ou Invocação Manual)       |
|                                │                                        |
|                                ▼                                        |
|   2. Selamento Criptográfico (FSS) e Fechamento do Dirty Bit            |
|      do arquivo ativo `system.journal`                                  |
|                                │                                        |
|                                ▼                                        |
|   3. Renomeação Atômica no VFS:                                         |
|      `system.journal` ---> `system@<hash_boot_e_timestamp>.journal`     |
|                                │                                        |
|                                ▼                                        |
|   4. Criação do novo `system.journal` zerado e alocação de cabeçalho    |
|                                │                                        |
|                                ▼                                        |
|   5. Execução do Algoritmo de Vacuumnation (Purga de Arquivos Antigos)   |
+-------------------------------------------------------------------------+

2.1. Gatilhos de Rotação (Rotation Triggers)

Uma rotação é iniciada no exato instante em que qualquer uma das seguintes quatro condições for satisfeita:

  1. Gatilho de Tamanho Físico: O arquivo ativo atual atinge o tamanho limite configurado na diretiva SystemMaxFileSize=.
  2. Gatilho Temporável (MaxFileSec=): Define o tempo máximo de vida de um arquivo .journal ativo. Se configurado como MaxFileSec=1month, o systemd-journald rotacionará o arquivo ativo ao completar um mês, mesmo que ele não tenha atingido o tamanho máximo em bytes. Útil para garantir que buscas temporais fiquem segmentadas em arquivos mensais ou semanais.

  3. Gatilho de Mutações de Estado do Sistema: Ocorrem eventos críticos no ciclo de vida do SO, tais como:
    * Instrução direta recebida via sinal IPC (journalctl --rotate).
    * Atingimento da chave de alteração de Boot ID se a diretiva interna de agrupamento for alterada.
    * Detecção de erros estruturais de gravação de bloco ou corrupção de ponteiro B-Tree no cabeçalho do arquivo ativo.

  4. Gatilho de Mudança do Relógio da Máquina (MaxRetentionSec=): Intervenção por expiração absoluta da janela temporal de retenção histórica de registros.

2.2. A Transição de Estado e Integridade de Leitura

O processo de rotação é projetado para garantir leituras concorrentes não bloqueantes (múltiplas instâncias de journalctl lendo dados enquanto o journald grava e rotaciona):

  1. O systemd-journald calcula o HMAC e o selo FSS final do arquivo ativo e atualiza o campo de cabeçalho state para o valor OFFLINE (desativando o dirty bit).
  2. Invocando a chamada de sistema rename(), o arquivo system.journal é renomeado atomicamente no kernel para uma string que codifica o hash da máquina, o UUID do boot e os timestamps de início e fim daquele arquivo específico:
    system@0006245e12f34a8b-a1b2c3d4e5f60718.journal
  3. Um novo arquivo system.journal é criado instantaneamente com um novo cabeçalho binário, e o descritor de arquivo de gravação do journald é apontado para este novo arquivo.
  4. Como a chamada rename() é atômica no nível de VFS dos sistemas de arquivos Linux (ext4, XFS, Btrfs), os processos leitores mantêm seus descritores de leitura abertos sem sofrer perda de contexto ou erro de file descriptor.

3. O Processo de Purga e Descarte (Vacuuming)

Rotacionar arquivos resolve o problema da performance de índice e concorrência, mas não impede a partição de encher. A remoção física de dados históricos obsoletos para manter o consumo de armazenamento dentro do teto estipulado é conduzida pelo algoritmo de Vacuuming (Aspiragem / Expurgamento).

+-------------------------------------------------------------------------+
|                  ALGORITMO DE VACUUMING (PURGA)                         |
|                                                                         |
|  [Fila de Arquivos Arquivados: A.journal, B.journal, C.journal]         |
|                                                                         |
|  1. Inspeciona a lista de arquivos ordenados por Timestamp de Alteração  |
|  2. O arquivo ATIVO atual é marcado como IMUNE ao descarte             |
|  3. Aplica restrições:                                                  |
|     - --vacuum-size: Soma tamanhos. Deleta os mais antigos até          |
|       a soma ficar <= limite.                                           |
|     - --vacuum-time: Inspeciona o timestamp do último registro do       |
|       arquivo. Deleta se [Agora - Timestamp] > tempo_limite.            |
|     - --vacuum-files: Conta arquivos. Deleta os mais antigos até        |
|       [Total <= limite].                                                |
|  4. Executa unlink() no sistema de arquivos para liberar blocos         |
+-------------------------------------------------------------------------+

3.1. As Regras do Expurgamento

O algoritmo de vacuuming opera estritamente sobre arquivos arquivados/rotacionados. Ele possui uma trava de segurança absoluta: o arquivo .journal ativo em gravação NUNCA é deletado pelo processo de vacuuming, mesmo que o seu tamanho isolado ultrapasse a cota estipulada em SystemMaxUse=. Isso evita interrupções na gravação de logs do sistema em tempo de execução.

Quando os limites de cota são violados, o journald ordena todos os arquivos arquivados do mais antigo para o mais recente baseado no Realtime Timestamp registrado no cabeçalho dos arquivos. O processo de eliminação segue uma fila FIFO (First-In, First-Out):

  1. O arquivo rotacionado mais antigo da lista é selecionado.
  2. A chamada de sistema unlink() é emitida, deletando o arquivo físico do disco e liberando os blocos no sistema de arquivos.
  3. A soma do espaço ocupado pelos arquivos restantes é recomputada.
  4. O laço continua deletando os arquivos em ordem cronológica inversa até que o consumo total de espaço em disco caia abaixo do teto limite definido por SystemMaxUse= ou SystemKeepFree=.

4. Retenção Temporal por Conformidade (MaxRetentionSec=)

Enquanto o limite de tamanho (SystemMaxUse=) foca no espaço de disco físico, a diretiva MaxRetentionSec= no arquivo /etc/systemd/journald.conf é a ferramenta de conformidade jurídica e regulatória.

  • Propósito: Define o tempo máximo de retenção dos registros de log no sistema. Se configurado como MaxRetentionSec=90day, o systemd-journald garante que nenhuma mensagem de log com idade superior a 90 dias seja mantida no armazenamento local, independente de haver terabytes de espaço em disco sobrando na partição.
  • Aplicações Legais (LGPD / GDPR / Marco Civil da Internet): Exigem que certos dados de telemetria e rastreabilidade de acesso sejam expurgados impreterivelmente após o encerramento do prazo legal de retenção para proteger a privacidade dos usuários. O MaxRetentionSec= automatiza essa destruição de dados sem a necessidade de criação de scripts externos em cron ou ferramentas de limpeza de terceiros.

5. Operação Manual de Manutenção e Diagnóstico CLI

O administrador de sistemas dispõe de utilitários de linha de comando incorporados ao journalctl para invocar rotações forçadas, executar purgas manuais sob demanda e verificar estatísticas de integridade e consumo de disco em tempo real.

5.1. Inspecionando o Consumo Físico Atual

Para obter um relatório detalhado sobre o uso de disco corrente, quantidade de arquivos mantidos e abrangência das datas dos registros armazenados:

journalctl --disk-usage

Exemplo de Saída:
Archived and active journals take up 2.4G in the file system.

5.2. Forçando a Rotação de Arquivos via Linha de Comando

Para selar imediatamente o arquivo ativo atual e forçar a criação de um novo system.journal limpo (por exemplo, antes de realizar um congelamento de sistema ou imagem de backup):

journalctl --rotate

O comando emite uma chamada IPC D-Bus direcionada ao systemd-journald que bloqueia até que a renomeação atômica e a criação do novo arquivo ativo estejam concluídas no sistema de arquivos.

5.3. Intervenções Manuais de Aspiragem (Vacuuming)

Em cenários de emergência onde a partição do sistema atingiu 99% de ocupação e necessita da liberação imediata de espaço em disco, o administrador pode passar flags manuais de purga para o journalctl. Essas instruções ignoram os limites estáticos do /etc/systemd/journald.conf e aplicam a limpeza informada no argumento instantaneamente:

Purga por Limite Absoluto de Tamanho:

Reduz a base acumulada mantendo no máximo o tamanho especificado (ex: reduz para 1 Gigabyte):

journalctl --vacuum-size=1G

Purga por Intervalo Temporal:

Deleta todos os arquivos arquivados que contêm apenas registros mais antigos do que o período especificado (ex: expurga registros com mais de 2 semanas):

journalctl --vacuum-time=2weeks

Purga por Contagem de Arquivos:

Mantém estritamente a quantidade especificada de arquivos de log arquivados no disco, deletando os excedentes mais antigos:

journalctl --vacuum-files=5

6. Prevenção de Inundações de Log (Rate Limiting)

Além dos limites de espaço em disco por arquivos, o systemd-journald implementa um escudo de proteção de I/O em tempo de execução denominado Rate Limiting (Limitação de Taxa).

Se um aplicativo defeituoso entrar em um laço infinito (infinite loop) e tentar disparar 500.000 mensagens de erro por segundo no pipe do journald, a CPU da máquina seria exaurida parseando strings, e a partição de disco seria destruída por ciclos de gravação descontrolados.

6.1. Configuração do Rate Limiting

A limitação de taxa é controlada por duas diretivas primárias no /etc/systemd/journald.conf:

[Journal]
RateLimitIntervalSec=30s
RateLimitBurst=10000
  • Mecânica da Janela Deslizante: O journald rastreia a taxa de injeção de mensagens de cada serviço individualmente (atrelado ao seu cgroup ou _SYSTEMD_UNIT).
  • A Regra da Explosão (Burst): Se um único serviço tentar enviar mais do que 10.000 mensagens (RateLimitBurst=) dentro do intervalo de 30 segundos (RateLimitIntervalSec=), o systemd-journald suprime imediatamente a gravação do excesso de mensagens daquele serviço específico.
  • Marcador de Supressão: As mensagens excedentes são descartadas no espaço de memória, e o journald injeta um aviso explícito de aviso no log informando a quantidade de mensagens que foram suprimidas para proteger a estabilidade do sistema:
    Suppressed 45231 messages from /system.slice/badapp.service
  • Isolamento: A supressão de taxa aplicada a um serviço malicioso não afeta a gravação de logs dos outros serviços da máquina, garantindo que logs vitais do kernel e do sistema de autenticação SSH continuem sendo processados sem perdas.
02 - Persistência vs Volátil 05 - Journald (Coleta de Logs)