política e ferramentas de logs sensatos

Question

O que é uma política de logs sensata?

Por um lado, eu gostaria de manter tudo para sempre. Por outro lado, não quero perder tempo em tarefas administrativas e evitar que os discos fiquem cheios nos servidores de produção.

O que é uma política de logs sensata? Quais ferramentas estão lá (livres ou não) para ajudar você a implementar a política.

    

Answer 1

Você está girando seus registros? Esse provavelmente será seu melhor plano de ação. Usar o logrotate torna muito fácil salvar logs antigos, compactá-los, se desejar, e mantê-los pelo tempo que desejar.

    "/export/log/non-local/mail.log" {
      daily
      rotate 7
      missingok
      postrotate
         /etc/init.d/syslog-ng reload >/dev/null
      endscript
      compress
      notifempty 
    }

    "/export/log/non-local/lab-submit" {
        rotate 5
        monthly
        postrotate
         /etc/init.d/syslog-ng reload >/dev/null
        endscript
        notifempty
    }

Isso é um trecho de um dos meus arquivos de logrotate. A primeira estrofe gira o registro de correio todos os dias, mantendo cópias antigas por sete dias. "missingok" significa que ele irá ignorar o arquivo se não estiver onde deveria estar. O postrotate. . . A seção endscript contém comandos que serão executados após o arquivo ter sido rotacionado. Compactar é autoexplicativo, o padrão é gzip. Você pode alterar a compactação usando algo como

   compresscmd /usr/bin/bzip2
   compressext .bz2 

O log de envio de laboratório é girado uma vez por mês e mantido por 5 meses.

Espero que isso ajude. Estou supondo (obviamente) que você atualmente não está rodando seus logs, que você está executando algum tipo de linux, e que você iria querer usar o logrotate, dependendo da sua distribuição e tipo de log você pode não querer usar o logrotate . Se alguma das minhas suposições estiver incorreta, avise-me e tentarei revisar minha resposta.

    

Answer 2

Meu curso geral de ação, depende da quantidade de disco que eu posso confortavelmente manter para as informações de log, enquanto luto com aquele evento de depuração catastrófico que pode causar um aumento dramático no uso do espaço em disco.

Log remoto, sempre, devido ao seguinte:

• Você nunca sabe quando uma máquina vai explodir,
• Quando isso acontece, você precisa saber o porquê o mais rápido possível
• Acessar um servidor de log central provavelmente é mais rápido do que reinicializar o referido servidor no modo de usuário único)

No servidor central, mantenha os logs por quanto tempo você achar necessário (ou necessário). Eu geralmente mantenho registros [compactados] entre 6 e 12 meses para tendências, mas 1 ou 2 meses podem ser bons para você.

Registro e rotação locais:

• Gire uma vez por hora, mantendo até quatro horas no disco
  • (ou se você tiver espaço extra e espaço de E / S: uma vez por semana, até sete dias no disco)
• Comprimir a cada duas horas
  • (renice sua tarefa de compactação para não interferir em tarefas mais importantes)

O registro local mantém você coberto apenas no caso de perder a conectividade de rede em algum momento.

    

Answer 3

Para certas coisas, quero manter os logs por um longo tempo - por exemplo, meus logs do Apache para o interesse histórico. Mas mesmo assim, tenho um trabalho cron em execução todos os dias e / ou semanas para fazer uma análise simples de visitantes únicos que são enviados para uma conta do Gmail que estabeleci apenas para esse tipo de coisa.

No entanto, minha abordagem geral é que não quero ou preciso mais dos dados desses registros que retornem mais do que alguns dias.

Eu já sei que eu nunca vou "ficar por aí" quando se trata de fazer qualquer gráfico ou análise histórica porque, francamente, estou muito ocupado fazendo meu trabalho "real":)

Se você estiver executando um syslog collector, talvez seja necessário segurar esses logs por mais tempo - só porque eles estão pegando tudo, de quantos servidores você estiver coletando.

A última vez que eu tive uma configuração do servidor syslog , nós tínhamos um par de DL180s antigos com discos rígidos de 18GB rodando o Ubuntu. Ambos cruzaram o outro via nfs ( <othersys>/path/to/log @ <currentsys>/path/to/backup ).

Nós rotacionamos nossos logs diariamente, comprimindo por bzip2 . Quando o espaço em disco atingiu > 90% usado, descartamos o arquivo mais antigo.

Já foi mencionado antes * , mas você também pode querer investigar um analisador de log como < href="https://fedorahosted.org/epylog/"> epylog ou Splunk como um componente do seu log política.

    

Answer 4

What is a sensible logs policy?

Bem, no mundo real, falta dinheiro e tempo tende a atrapalhar; mas aqui estão as principais preocupações IMHO:

a) Colete os registros em um repositório central. Colete os registros em um local seguro, para

• evite que eles sejam adulterados se você for hackeado
• para dar a você uma visão geral do trabalho do dia a dia, ou seja, acompanhar eventos em várias máquinas.

b) Use a pesquisa em tempo real & filtrar para cortar e cortar dados de registro quando necessário.

• Registre quase tudo - talvez não todos os pacotes defeituosos que chegam ao firewall externo, mas certamente todos os eventos importantes de seus servidores, talvez eventos de PCs de sua estação de trabalho também, etc.
• Use a pesquisa & filtrando no repositório central de logs para extrair o significado de todos esses dados quando necessário.

c) Configure alertas. Configure alertas significativos para o seu sistema. Isso tem uma grande sobreposição com outros sistemas, como Munin ou Nagios; eles podem fazer praticamente o mesmo. Qual sistema você preferirá alertar você será uma questão de opinião e circunstâncias caso a caso.

• Certifique-se de extrair o máximo de valor possível, ou seja, reserve um tempo para configurar alertas para problemas comuns. Isso ajudará você a ser mais proativo na administração do seu sistema.

d) Mantenha tudo por pelo menos 90 dias. Você pode jogar fora dados menos importantes depois de mais de 90 dias se precisar, mas pode não ser necessário. Por exemplo, se você usar o MySQL com o Mecanismo de armazenamento de arquivos para dados históricos, poderá armazenar grande quantias de dados baratas, mas principalmente somente leitura e com baixa indexação. Dividir os dados em "hot" e "near-line" pode funcionar bem.

Good & sistemas baratos que permitem o acima? Eu ainda estou procurando. As soluções parecem divididas em duas IMHO: 1) sistemas open source / baratos baseados em um banco de dados e alguns scripts, e 2) grandes empresas 'nós ajudamos você com sistemas de conformidade regulatória que são caros. Nem parece certo para mim.