Phenquestions
Entender os logs é importante: se você cair em um servidor que tem um bug ou foi hackeado, geralmente sua única maneira de entender o que aconteceu é por meio de logs. O aplicativo principal que vamos usar é o journalctl, daí o nome do artigo. Portanto, ouça com atenção, pois no dia certo, você pode ficar feliz em saber como funciona.
Onde são armazenados os logs do systemd? E em que formato está armazenado?
Vamos supor que você tem um sistema normal, porque o systemd pode ser personalizado para estar em locais excepcionais. Além disso, algumas distribuições de Linux como o Ubuntu 16.04 desabilitou o log persistente por padrão, o que impede o systemd de fazer seu trabalho corretamente. Se você tiver essa distribuição, edite / etc / systemd / journald.arquivo conf, altere Storage = auto para Storage = persistent e, finalmente, reinicie.
Portanto, você encontrará normalmente os arquivos de log do systemd em / var / log / journal. O sistema de journaling é em si um serviço chamado system-journald.serviço. Vamos tentar listar os arquivos neste diretório:
# ls / var / log / journal / -R/ var / log / journal /:
15e43c1734090ac7fbea6b40fcd99d31
/ var / log / journal / 15e43c1734090ac7fbea6b40fcd99d31:
sistema @ a39da368947bd2ba-231f9bfc18a7a356.diário ~
sistema @ 62ac1299826d036cb043d6c06a9493b7-0000000000000001-00067d6410099a19.Diário
user-1000 @ b27e98812223a9bc-387e0521703f73d9.diário ~
user-1000 @ 2123bc076b58569fe1fb13e9dbc1b0e0-0000000000000001-0007fe36ac2810e0.Diário
usuário-1000.Diário
[muitos outros arquivos como os acima ...]
Como quero que você continue lendo, tive que encurtar a saída, pois contém muitos arquivos (no meu exemplo, mais de 60 arquivos), desculpe por isso! Tentado a abrir um talvez?
# head --bytes = 512 / var / log / journal / 15e43c1734090ac7fbea6b40fcd99d31 / [email protegido]b58569fe1fb13e9dbc1b0e0-0000000000000001-0007fe36ac2810e0.Diário
?s, q?n / FLz???Ulz?eu?]????
?_?b???z????o?y1KN ?eu?eO??C?você? ?=?x0?eu?d?7??X4n #?e? d3l?
p??o | MFO:?!qs?.tK??R?\??1?| 5 ????$?g??#?S??;??B7???????t???Y????mN?q????ZQ
?Yv?e?????BD?C?? wF??d |
?2?? 7???????[??Un?= 8????c?2 = p?E?" ?0
????*????_?? ???
5?????yk?G? ?6?|??você??w: # 12?Y??
3 TU;???'?jX??2?x '?=??[[email protegido]
[email protegido]?_?>??3S???,lR?.?$?g?eu???s?/ E??M1??q???
Ei, veja, isso realmente não se parece com os arquivos de log usuais que você vê direito? Não se preocupe, este arquivo não está corrompido, você acabou de descobrir um aspecto do systemd: o systemd armazena arquivos em formato binário. É por isso que é o menor possível: dados estruturados, como hora ou local, são armazenados diretamente em binário, o que geralmente leva menos bytes do que o texto. Mas essa não é a única razão.
systemd não armazena apenas linhas de registro. Sua intenção é facilitar o monitoramento e a exploração de registros. Para ajudar nesta tarefa, as mensagens de log são, na verdade, uma linha de texto acompanhada de dados como a gravidade do log (aviso, erro, etc.), ou mesmo campos que seriam úteis apenas para o seu aplicativo (URL solicitado, por exemplo).
# journalctl --output = verbose --allPRIORIDADE = 6
_UID = 0
_GID = 0
_CAP_EFFECTIVE = 3fffffffff
_BOOT_ID = ee4cc2ce7e8273aaffb5fc59c873ce7b
_MACHINE_ID = bc422e0feaab64bb7dd218c24e6830e5
_HOSTNAME = linux
SYSLOG_FACILITY = 3
SYSLOG_IDENTIFIER = systemd
UNIT = dnf-makecache.serviço
_TRANSPORT = diário
_PID = 1
_COMM = systemd
_EXE = / usr / lib / systemd / systemd
_CMDLINE = / usr / lib / systemd / systemd --switched-root --system --deserialize 76
_SYSTEMD_CGROUP = / init.alcance
_SYSTEMD_UNIT = init.alcance
_SYSTEMD_SLICE =-.fatiar
_SELINUX_CONTEXT = system_u: system_r: init_t: s0
CODE_FILE = src / core / job.c
CODE_LINE = 795
CODE_FUNCTION = job_log_status_message
MESSAGE_ID = a76e08846f5f0971371dbb11126e62e1
MESSAGE = Iniciado dnf makecache.
# journalctl --catalog --lines = 3000 --pager-end "_TRANSPORT = kernel" RESULT = done
_SOURCE_REALTIME_TIMESTAMP = 1532886335471422
Eu disse que há muitos campos (aqui há 25 campos, ou 29 marcações de tempo de contagem), todo o trecho acima é apenas para uma única mensagem de log! A grande vantagem é que você pode executar uma pesquisa filtrando em qualquer campo desta mensagem de log. Isso realmente permite a filtragem avançada.
Um dos filtros mais óbvios que você deseja é filtrar pelo serviço. Como você pode ver acima, há um campo UNIT para que você possa filtrar facilmente para obter apenas mensagens de log de um serviço. Eu vou te contar mais sobre isso mais tarde.
Mas essa quantidade de dados também significa outra coisa: em quase todos os casos, você nunca abrirá um arquivo de log manualmente e nunca tocará na pasta / var / log / journal. Você usará o journalctl para qualquer tarefa relacionada ao registro. Não existe tal rotação de log, tudo é gerenciado pelo tempo de mensagem de log.
Da mesma forma, o número de campos dependerá de quão boa é a integração do systemd em sua aplicação. Quanto mais campos uma mensagem de log contiver, melhor será. Para os serviços do sistema básico, o systemd já cuidou de fazer uma boa integração, mas para outros aplicativos e serviços, a qualidade da integração varia muito. Normalmente, isso deve melhorar com o tempo, à medida que as pessoas se acostumam com o systemd.
Ok, agora é hora de descobrir os recursos do journalctl.
Comandos mais usados para journalctl
O primeiro comando que você pode querer dar uma olhada é aquele que mostra os logs do kernel do Linux. Sim, o systemd também lida com o armazenamento de logs do kernel, então você também pode obter os logs de inicializações anteriores. Aqui está o comando:
# journalctl --catalog --lines = 3000 --pager-end "_TRANSPORT = kernel"Mostra um pager onde você pode ver as últimas mensagens. Você pode rolar até as últimas 3.000 linhas usando as teclas de seta (↑ / ↓) ou Page Up / Page Down. O sinalizador -catalog instrui o journalctl a mostrar o contexto em torno das linhas de log, muito parecido com reinicializações do computador ou, em outros contextos, um serviço parando / iniciando. Eu sempre coloco este sinalizador porque o contexto sempre importa, ajuda saber em qual situação a linha de registro apareceu, então você pode adivinhar porque você obteve esta linha de registro.
Agora, talvez você queira ver apenas as linhas de registro da inicialização atual:
# journalctl --catalog --lines = 35000 --pager-end --boot "_TRANSPORT = kernel"Observe que o argumento da linha de comando -boot funciona em todas as situações, não apenas com os logs do kernel. Se você preferir começar do início:
# journalctl --catalog --boot "_TRANSPORT = kernel"Não sei se é o seu caso, mas tenho logs de kernel suficientes! E que tal ter uma visão geral de sua máquina?
# journalctl --catalog --lines = 3000 --pager-endUau, há muitas coisas acontecendo no seu sistema! Um pouco de filtragem seria útil aqui. Um dos filtros mais usados é combinar um serviço específico (como seu servidor SSH ou servidor HTTP), o nome de arquivo da unidade systemd para o serviço SSH é sshd.serviço, então:
# journalctl --catalog --lines = 3000 --pager-end --unit = sshd.serviçoQue legal né? Bem, só pode ser usado se você souber o nome do serviço - mas, em muitos casos, você não sabe o nome desse serviço. Se você está nessa situação, pode desejar uma lista dos serviços, suas descrições e status:
# systemctl list-units --type = serviçoOk, este problema agora está resolvido. Mas, às vezes, você recebe uma mensagem de erro que recebe de um sistema externo, como seu próprio site, ou de um aplicativo em seu desktop. Então você provavelmente vai querer pesquisar uma palavra ou frase específica na mensagem de log. Desde o systemd v237, agora é possível.
No journalctl, a pesquisa não diferencia maiúsculas de minúsculas se a palavra que você pesquisa estiver toda em minúsculas. Portanto, se você pesquisar a palavra porta, ele também pesquisará a palavra porta com letras maiúsculas. Um exemplo:
# journalctl --catalog --lines = 3000 --pager-end --grep = "port"Agora, se você pesquisar uma palavra como CPU, ele pesquisará apenas CPU com todas as letras maiúsculas, não pesquisará CPU.
# journalctl --catalog --lines = 3000 --pager-end --grep = "CPU"Você se lembra da mensagem de erro do sistema externo? Geralmente, essas mensagens contêm um carimbo de data / hora. Para filtrar a mensagem de registro, você pode querer usar esse carimbo de data / hora. O journalctl pode listar todas as mensagens de log desde uma data e hora específicas com o argumento -since:
# journalctl --catalog --since = "2018-07-30 09:30:00"Se esse sistema externo for remoto ou estiver usando carimbos de data / hora UTC, você desejará filtrar com base em uma data e hora UTC e exibir no terminal os carimbos de data / hora UTC para que você não precise convertê-los em sua cabeça, que tende a ser realmente confuso. Para fazer isso, você precisará adicionar UTC após a string de tempo no argumento -since. Você precisará adicionar o sinalizador -utc. Então, por exemplo:
# journalctl --catalog --since = "2018-07-30 10:45:00 UTC" --utcObserve que você pode usar a sinalização -utc sozinha, neste caso ela basicamente exibirá todas as datas e horas no fuso horário UTC.
# journalctl --catalog --lines = 3000 --pager-end --utcOs registros são melhor gerenciados com o journalctl
Como você pode ver com todos os comandos anteriores, o diário do systemd torna a filtragem e a depuração mais fáceis, pois você pode selecionar todas as linhas de log usando um único comando, journalctl. Alguns de vocês provavelmente conheceram tempos antigos onde você tinha que abrir manualmente cada arquivo em / var / log para ter uma idéia geral do problema e do que aconteceu. Com todas as dicas que aprendeu aqui, você terá ferramentas sólidas para ver suas mensagens de registro da maneira que VOCÊ quiser.
