Entenda o poder do SystemD e Journald no gerenciamento de sistemas Linux
E ai, Qual teu papo?
O objetivo deste bate papo e abordar sobre um componente do SystemD chamado Journald que atua na coleta e gerenciamento de entradas de registros diários de todas as partes do sistema. Mas antes disso, vamos entender o que é SystemD.
O SystemD tornou-se o daemon para gerenciamento de sistemas em várias distribuições de Linux nos últimos anos. Ele foi introduzido inicialmente no Fedora, porém outras distribuições, como o Arch Linux, o openSUSE e o CoreOS, já fizeram uso deste recurso. O Red Hat Enterprise Linux (RHEL) e suas distribuições downstream como o CentOS começaram a usar SystemD nativamente a partir da versão 7. Outra grande distribuição, o Ubuntu – que introduziu outro daemon de gerenciamento de serviços chamado Upstart – agora vem com o SystemD desde a versão 15.
A razão para essa adoção em larga escala é a versatilidade do SystemD. Ele gerencia não apenas os daemons e processos em um sistema Linux, mas também vários outros recursos, como: dispositivos, soquetes ou pontos de montagem. Quando o sistema inicializa, ele não carrega serviços sequencialmente como o System V, o que economiza um tempo significativo na inicialização. Os serviços são carregados em paralelo e um serviço aguarda até que outros recursos necessários para ele também sejam ativados.
O SystemD é retrocompatível com seus predecessores, como o System V init e o Upstart. Isso significa que qualquer serviço que ainda esteja usando scripts de inicialização mais antigos do System V para inicialização funcionará no SystemD e você ainda poderá usar comandos SystemD como systemctl para iniciar, parar e verificar o status de um serviço. Outra vantagem do SystemD é sua facilidade de configuração. O SystemD é controlado por arquivos de unidade que são declarativos por natureza e fáceis de entender. Isso contrasta com o System V, onde o desenvolvedor do aplicativo tinha que criar scripts de shell complicados para iniciar, parar ou recarregar o serviço.
Como veremos mais adiante, o SystemD possui um serviço de registro sofisticado que pode ser usado em vez do tradicional serviço de SysLog. Também pode ser usado para complementar o SysLog.
Unidades e Alvos
No coração do SystemD estão os arquivos unitários . Um arquivo de unidade é um arquivo de texto simples que vive no diretório /lib/systemd/system e possui um tipo associado a ele. Um arquivo de unidade basicamente descreve um recurso e informa ao SystemD como ativar esse recurso. O padrão de nomenclatura para um arquivo de unidade é <resource_name>. <Unit_type> . Os diferentes tipos de unidades incluem serviço, caminho, ponto de montagem, automount, swap, destino, timer, dispositivo e soquete. Portanto, temos arquivos unitários como cron.service, tmp.mount, syslog.socket ou graphical.target. Para cada unidade de serviço ativada, um link simbólico para o arquivo de unidade é colocado no diretório /etc/systemd/system/<target>.wants/.
Uma unidade alvo é um tipo especial de arquivo de unidade porque não representa um único recurso; em vez disso, agrupa outras unidades para levar o sistema a um estado particular. As unidades de destino no SystemD se assemelham vagamente aos níveis de execução no System V, no sentido de que cada unidade de destino representa um determinado estado do sistema. Por exemplo, a unidade graphical.target representa um sistema que foi inicializado no modo gráfico multiusuário, semelhante ao runlevel5 do System V. Multi-user.target, por outro lado, é semelhante ao runlevel3 (modo de texto multiusuário, com rede ativada). No entanto, os destinos também são diferentes dos níveis de execução porque no System V, uma caixa do Linux pode existir em apenas um nível de execução a qualquer momento. No SystemD, as unidades de destino são inclusivas, onde uma unidade de destino pode agrupar outras unidades de destino quando estiver chegando, portanto é possível que um sistema permaneça em mais de um destino.
Básico do Journal SystemD
O Journal é um componente do SystemD, onde é centralizado todas as mensagens registradas pelos diferentes componentes de um sistema Linux ativado pelo SystemD, incluindo mensagens de kernel, de inicialização e que sejam provenientes do SysLog ou serviços diferentes.
No Linux tradicional, durante a fase de inicialização, diferentes subsistemas ou daemons de aplicativos registrariam todas as mensagens em diferentes arquivos de texto em todo o sistema. Cada sistema registraria suas mensagens com vários níveis de detalhes. Ao solucionar problemas, um administrador normalmente teria que passar por mensagens de vários arquivos em diferentes intervalos de tempo e correlacionar as entradas. O journauling elimina essa dificuldade registrando as mensagens tanto do sistema operacional como também a nível de aplicação em um só lugar.
O journauling é controlado pelo daemon systemd-journald e coleta informações de diferentes fontes e carrega as mensagens no journal.
O journal do SystemD não é um arquivo de texto grande, na verdade é um arquivo binário mantido pelo daemon. Portanto, não pode ser aberto com um editor de texto. Como veremos mais adiante, a localização e o tamanho desse arquivo binário é controlado pelo arquivo de configuração do próprio daemon. Ele não precisa ser persistente: usando parâmetros de configuração, um administrador pode desativar o registro no diário ou mantê-lo na memória, por isso é de natureza volátil. Com o Journal na memória, o SystemD cria seus arquivos de diário no diretório /run/log/journal, caso não exista o diretório será criado. Com armazenamento persistente, o diário é criado no diretório /var/log/journal, novamente o diretório é criado pelo SystemD, se necessário. Se esse diretório for excluído por algum motivo, o systemd-journald não o recriará automaticamente, em vez disso, ele gravará os logs em /run/log/journal de maneira não persistente e recriará o diretório somente quando o daemon for reiniciado.
Aqui está um exemplo do journal do systemd:
ls -l /var/log/journal drwxr-sr-x 2 systemd-journal 4096 Jun 25 00:06 fd8cf26e06e411e4a9d004010897bd01
ls -l /var/log/journal/ fd8cf26e06e411e4a9d004010897bd01 / -rw-r—– 1 raiz do root 109051904 Jun 27 23:00 system.journal
Com o journal do SystemD, não há opção ou motivo para um utilitário tradicional de SysLog como logrotate. O systemd-journald pode ser configurado para aumentar seus arquivos até uma certa porcentagem do tamanho do volume total em que está hospedado. Em seguida, o daemon excluirá automaticamente as entradas de diário antigas para manter o tamanho abaixo desse limite. Existem várias opções para controlar o tamanho do diário, como poderemos ver mais adiante.
Configuração do Journald
O arquivo de configuração principal do systemd-journald é o /etc/systemd/journald.conf. No entanto, outros pacotes podem criar seus arquivos de configuração que podem estar em qualquer um desses diretórios com uma extensão .conf:
- /ETC/SYSTEMD/JOURNALD.CONF.D/*.CONF
- /RUN/SYSTEMD/JOURNALD.CONF.D/*.CONF
- /USR/LIB/SYSTEMD/JOURNALD.CONF.D/*.CONF
O arquivo de configuração principal é lido antes de qualquer um dos arquivos * .conf personalizados. Se houver configurações personalizadas presentes, elas substituirão os principais parâmetros de configuração.
Uma olhada no arquivo de configuração padrão mostra as seguintes entradas:
Como você pode ver, todos os parâmetros são comentados, o que significa que os valores já são conhecidos pelo SystemD como valores padrão. Se algum dos valores precisar ser alterado, eles precisarão ser descomentados e o systemd-journald.service será reiniciado.
Uma breve descrição de alguns dos parâmetros de configuração é mostrada abaixo. Os parâmetros estão relacionados com:
- PERSISTÊNCIA DE MENSAGENS DOS EVENTOS DO JOURNAL
- GERENCIAMENTO DE ESPAÇO EM DISCO
- ENCAMINHAMENTO PARA OUTROS SYSLOGS E OUTRAS MÍDIAS DE SAÍDA
| Parâmetro | Finalidade e Valores Possíveis |
|---|---|
| Storage | Existem quatro valores possíveis para ele: “none”: isso efetivamente desativa o registro no Journal. Qualquer mensagem de log recebida será descartada. No entanto, qualquer redirecionamento para o console ou syslog ou buffer de log do kernel ainda estaria em vigor. “volatile”: os dados do Journal são salvos na memória e temporariamente disponíveis no diretório /run/log/journal. O diretório será criado se não existir. “persistent”: os dados do Journal são salvos de forma persistente no disco, no diretório /var/log/journal. O diretório será criado se não existir. Se o volume do disco não estiver acessível ou gravável, os arquivos serão criados em /run/log/journal. “auto”: o modo de armazenamento é como persistente – os dados serão gravados no disco; no entanto, se o diretório /var/log/journal não existir, ele será criado em /run/log/journal. |
| Compress | Se esse parâmetro estiver ativado, os dados armazenados no journal que forem maiores que um limite serão compactados antes de serem gravados no disco. A opção está ativada por padrão. |
| SystemKeepFree | Este é um dos vários parâmetros que controlam o tamanho que o Journal pode atingir. Este parâmetro se aplica caso o SystemD estiver salvando journals no diretório /var/log/journal. Ele especifica quanto espaço em disco o daemon systemd-journald deixará para outros aplicativos no sistema de arquivos em que o journal está hospedado. O padrão é 15%. |
| RuntimeKeepFree | O mesmo que o SystemKeepFree, exceto que isso se aplica quando a opção de armazenamento de registro no journal é definida como “volatile”, o que significa que os arquivos de diário são criados em /run/log/journal. |
| SystemMaxuse | Esse parâmetro controla o espaço máximo em disco que o journal pode consumir quando é persistente. Este padrão é 10% do espaço em disco. |
| RuntimeMaxUse | O mesmo que SystemMaxUse, aplicável para armazenamento de journal volátil (quando os arquivos são salvos em /run/log/journal). Novamente, o padrão é 10%. |
| SystemMaxFileSize | Isso especifica o tamanho máximo de um arquivo de journal para armazenamento persistente. Isso padroniza para um oitavo do tamanho do parâmetro SystemMaxUse. |
| RuntimeMaxFileSize | O mesmo que SystemMaxFileSize: aplica-se a arquivos em /run/log/journal. |
| MaxRetentionSec | O tempo máximo para armazenar entradas no diário. Arquivos de diário contendo registros que são mais antigos que este período serão excluídos automaticamente. No entanto, o valor não precisa ser especificado apenas em segundos. Pode ser sufixado com “ano”, “mês”, “semana”, “dia”, “h” ou “m”. O padrão é 0. Esse parâmetro não precisa ser definido a partir do valor padrão 0 porque o parâmetro SystemMaxUse garantirá que o journal não cresça e preencha todo o espaço em disco. |
| MaxFileSec | Isso é o mesmo que o parâmetro MaxRetentionSec, exceto que isso se aplica a arquivos de journal individuais. Esse parâmetro tem um valor padrão de um mês e controla o tempo máximo para manter entradas de journal em um único arquivo de diário. Novamente, isso pode ser desativado com um valor 0 porque o parâmetro SystemMaxFileSize pode controlar o tamanho máximo de um arquivo individual. |
| ForwardToSyslog | Este parâmetro especifica se as mensagens de log recebidas pelo daemon systemd-journald também serão encaminhadas para um daemon syslog. O padrão é sim, mas se nenhum processo estiver sendo lido no soquete, nada acontece. |
| ForwardToWall | Se as mensagens de log recebidas pelo systemd-journald também serão enviadas como mensagens de parede para todos os usuários que efetuaram login. O padrão é sim. |
| ForwardToKMsg | Se as mensagens de log recebidas pelo systemd-journald também serão encaminhadas para o buffer de log do kernel. O padrão é não. |
| ForwardToConsole | Se as mensagens de log recebidas pelo systemd-journald também serão encaminhadas para o console do sistema. Se esse parâmetro estiver ativado, outro parâmetro TTYPath determinará o TTY do console para o envio de mensagens. O valor padrão desse parâmetro é /dev/console. |
| MaxLevelStore | Esse parâmetro pode assumir qualquer um dos seguintes valores:
Todas as mensagens iguais ou abaixo do nível especificado serão armazenadas no disco. O valor padrão é “debug”, que significa todas as mensagens de log de “emerg” para “debug”. |
| MaxLevelSyslog | Controla o nível máximo de mensagem de log encaminhada ao SysLog. Novamente, o valor padrão é “debug”. |
| MaxLevelKMsg | Controla o nível máximo de mensagem de log encaminhada ao buffer de log do kernel. O valor padrão é “aviso”. |
| MaxLevelConsole | Controla o nível máximo de mensagem de log encaminhada ao console do sistema com um valor padrão de “info”. |
| MaxLevelWall | Controla o nível máximo de mensagem de log encaminhada para as paredes dos usuários que efetuaram login. O padrão é “emergir” – o que significa que, se ativado, os usuários serão imediatamente notificados sobre eventos de emergência. |
Aqui foi um breve resumo da ferramenta Journalctl do SystemD, se você quiser acompanhar alguns testes com esse comando em produção para se convencer do poder da ferramenta, te convido para assistir o video abaixo, onde mostrarei algumas das principais situações onde é possível visualizar o potencial da obtenção de informação através desta ferramenta.
No mais, espero que tenham gostado… um forte abraco.. e até a próxima!
About author
Você pode gostar também
Como Implementar a Análise de Qualidade de Código com DevOps e SonarQube
Dentro da ótica do DevOps e de como implementar agilidade com qualidade, temos os testes automatizados como um dos principais pilares para manter a essência do CI (Continuous Integration), porém
Melhore a segurança do seu ambiente Kubernetes com práticas eficazes
A ampla utilização do Kubernetes (K8S) em ambientes produtivos traz uma alerta, de como esses ambientes estão sendo usados em relação as configurações e boas práticas de segurança da informação.
Como criar uma federação de usuários com Keycloak e LDAP: um tutorial passo a passo
Na primeira parte dessa série de posts, vimos de maneira geral o funcionamento do Keycloak. Nessa segunda parte veremos como criar um user federation para importar usuários da nossa base
