solução de problemas é uma das principais razões pelas quais as pessoas criam logs. Quando um problema ocorre, você vai querer diagnosticá-lo para entender por que isso aconteceu e qual foi a causa. Uma mensagem de erro ou uma sequência de eventos podem dar-lhe pistas sobre a causa raiz, indicar como reproduzir o problema e guiá-lo para soluções. Esta seção apresenta cenários onde você pode usar logs Linux para solucionar problemas.,
falha
falhas de Login
para fins de segurança, poderá querer saber quais os utilizadores que entraram ou tentaram entrar no seu sistema. Você pode verificar seus registros de autenticação para tentativas falhadas, que ocorrem quando os usuários fornecem credenciais incorretas ou não têm permissão para fazer login. Isso muitas vezes ocorre ao usar o SSH para acesso remoto ou ao usar o comando su para executar um comando como outro usuário. Estes tipos de eventos de autenticação são registados pelo módulo de autenticação pluggable (PAM)., Eventos falhados muitas vezes contêm strings como “Failed password” e “user unknown”, enquanto eventos de autenticação bem sucedidos muitas vezes contêm strings como “Accepted password” e “session opened”.”
exemplos de eventos de falha incluem:
exemplos de logins bem sucedidos incluem:
Se quisermos descobrir quais contas de usuário têm os logins mais falidos, primeiro precisamos extrair o nome do usuário do log de auth. Usaremos os comandos grep, cut, sort e uniq para fazer isso., O Grep devolve linhas que contêm “utilizador inválido”, corta extrai os nomes de utilizador, ordena a lista de nomes e o uniq conta o número de nomes únicos:
outras aplicações e serviços poderão usar formatos diferentes, por isso terá de adaptar este comando para cada aplicação. Os sistemas de gerenciamento de Log podem efetivamente fazer isso para você, processando automaticamente campos como o nome de usuário. Isto permite-lhe ver e filtrar rapidamente as logins falhadas com um único clique. Neste exemplo, podemos ver que o usuário root tentou fazer login mais de 300 vezes.,
nomes de utilizador associados a tentativas de autenticação falhadas mostradas no loggly dynamic field explorer.
Sistemas de gerenciamento de Log também permitem que você veja gráficos ao longo do tempo para detectar tendências incomuns. Se alguém teve um ou dois logins falhados em poucos minutos, pode ser que um usuário real se esqueceu de sua senha. No entanto, se há centenas de logins falhados ou são todos nomes de utilizador diferentes, é mais provável que alguém esteja a tentar atacar o sistema. Aqui você pode ver um súbito aumento nas tentativas de logins como um administrador., É evidente que não se trata de uma utilização legítima do sistema.
Surge na tentativa de login de raiz. © 2019 SolarWinds, Inc. Todos os direitos reservados.
causa
causa de reinicialização
às vezes um servidor pode parar devido a um estoiro ou reinicialização do sistema. Como é que sabes quando aconteceu e quem foi?
Shutdown Command
Se alguém executou o comando shutdown manualmente, você pode vê-lo no ficheiro de registo de autenticação. Aqui você pode ver que alguém se conectou remotamente como o usuário ubuntu e, em seguida, desligar o sistema.,
inicialização do Kernel
Se quiser ver quando o servidor reiniciou independentemente da razão (incluindo estoiros), poderá procurar no ficheiro de registo do kernel(/var/log/kern.log). Syslog também aplica a facilidade “kern” para logs de kernel. Os seguintes registros foram gerados imediatamente após o boot. Note que o intervalo de tempo entre os parêntesis é 0: isto acompanha a quantidade de tempo desde que o ‘kernel’ começou. Você também pode encontrar logs de inicialização procurando por “BOOT_IMAGE”.,
detect
detecta problemas de memória
Existem várias razões pelas quais um servidor pode falhar, mas uma causa comum está a ficar sem memória.
Quando RAM e espaço de troca estão completamente esgotados, o kernel vai começar a matar processos—tipicamente aqueles que usam mais memória e mais de curta duração. O erro ocorre quando o seu sistema está usando toda a sua memória, e um processo novo ou existente tenta acessar a memória adicional. Procure nos seus ficheiros de registo por strings como” fora da memória ” ou por avisos de kernel., Estas cadeias de caracteres indicam que o seu sistema matou intencionalmente o processo ou a aplicação, em vez de permitir que o processo estoire.
exemplos:
tenha em mente grep usa a memória, por isso você pode causar um erro de falta de memória apenas executando grep. Esta é outra razão pela qual é uma idéia fabulosa centralizar seus registros!
cron
registar erros de trabalho do Cron
o servidor do cron é um escalonador que executa comandos em datas e horas especificadas. Se o processo não funcionar ou não terminar, então um erro de cron aparece em seus arquivos de log., Você pode encontrar esses arquivos no /var/log/cron /var/log/messages e /var/log/syslog dependendo da sua distribuição. Há muitas razões pelas quais um trabalho de cron pode falhar. Normalmente os problemas estão com o processo e não com o próprio daemon de cron.
Por omissão, as tarefas cron saem para o syslog e aparecem no ficheiro /var/log/syslog. Você também pode redirecionar a saída de seus comandos cron para outro destino, como saída padrão ou outro arquivo. Neste exemplo, nós pipe “Hello world” para o comando logger., Isso cria dois eventos de log: um de cron, e um do comando logger. O parâmetro-t define o nome do aplicativo para “helloCron”::
$ crontab -e*/5 * * * * echo 'Hello World' 2>&1 | /usr/bin/logger -t helloCron
o Que cria as entradas de log:
Cada tarefa do cron será registo de forma diferente com base no tipo específico de trabalho e como ele saídas de dados. Esperançosamente há pistas para a causa raiz dos problemas dentro dos logs, ou você pode adicionar o registro adicional conforme necessário. Na maioria dos casos, você deve simplesmente deixar o cron registrar a saída de seus comandos.