logstash timestamp no rollover do ano

3

Usamos o logstash para armazenar / pesquisar logs de nossos servidores de e-mail. Percebi hoje que não tivemos nenhum índice a partir deste ano (2015). A investigação rápida mostrou que os registros atuais estavam sendo armazenados como 2014.01.05 (ou seja, no mesmo dia, mas no ano passado) e esses índices estavam sendo excluídos por um cron job que procura índices antigos.

A reinicialização do logstash consertou as coisas, então presumo que o logstash esteja preenchendo as informações do ano com base na hora em que ele foi iniciado.

Estamos executando o Logstash 1.4.1 com o Elasticsearch 1.2.4. Portanto, não é a versão mais recente do Elasticsearch, mas não vejo nada relevante no changelog para o 1.4.2.

As entradas de log são enviadas para logstash usando syslog-config abaixo, junto com o exemplo de linha de entrada e saída analisada.

Existe uma solução melhor para isso do que apenas lembrar de reiniciar o Logstash no dia de Ano Novo?

Exemplo de linha de entrada

Jan  5 15:03:35 cheviot22 exim[15034]: 1Y89Bv-0003uU-DD <= [email protected] H=adudeviis.ncl.ac.uk (campus) [10.8.232.56] P=esmtp S=2548 [email protected]

{
  "_index": "logstash-2014.01.05",
  "_type": "mails",
  "_id": "HO0TQs66SA-1QkQBYd9Jag",
  "_score": null,
  "_source": {
    "@version": "1",
    "@timestamp": "2014-01-05T15:03:35.000Z",
    "type": "mails",
    "priority": 22,
    "timestamp": "Jan  5 15:03:35",
    "logsource": "cheviot22",
    "program": "exim",
    "pid": "15034",
    "severity": 6,
    "facility": 2,
    "facility_label": "mail",
    "severity_label": "Informational",
    "msg": "1Y89Bv-0003uU-DD <= [email protected] H=adudeviis.ncl.ac.uk (campus) [10.8.232.56] P=esmtp S=2548 [email protected]",
    "tags": [
      "grokked",
      "exim_grokked",
      "dated"
    ],
    "xid": "1Y89Bv-0003uU",
    "exim_rcpt_kv": "[email protected] H=adudeviis.ncl.ac.uk (campus) [10.8.232.56] P=esmtp S=2548 [email protected]",
    "H": "adudeviis.ncl.ac.uk",
    "P": "esmtp",
    "S": "2548",
    "id": "[email protected]"
  },
  "sort": [
    1388934215000,
    1388934215000
  ]
}

Configuração do Logstash (com bits irrelevantes removidos) ...

input {
    syslog {
        codec => "plain"
        debug => false
        port => 514
        type => "mails"
    }
}

filter {
    mutate {
        remove_field => [ "path", "host" ]
    }

    if [type] == "mails" {
        grok {
            patterns_dir => [ "/etc/logstash/patterns" ]
            match => [ "message",  "(?<msg>.*)" ]
            add_tag => [ "grokked" ]
            break_on_match => true
            remove_field => [ "message" ]
        }
    }

    date {
        match => [ "timestamp", "ISO8601", "MMM dd HH:mm:ss", "MMM  d HH:mm:ss"]
        add_tag => [ "dated" ]
    }
}

output {
        elasticsearch {
                cluster => "logstash"
        host => "iss-logstash01"
        flush_size => 1000
        index => "logstash-%{+YYYY.MM.dd}"
        }
}
    
por Paul Haldane 05.01.2015 / 17:03

1 resposta

2

Encontrei um ponteiro para responder no grupo do logstash-users do Google (que passou despercebido). Uma discussão recente apontou para o link que (a) confirma que outras pessoas estão vendo o mesmo que eu e (b) oferece algumas soluções possíveis.

A opção 1 é um patch para o Elasticsearch (não na distribuição padrão) que atualiza a ideia da Logstash do ano atual.

A opção 2 é não analisar o registro de data e hora da linha do syslog e, em vez disso, confiar apenas na hora em que a mensagem chega com o Logstash. Esta é provavelmente uma solução aceitável para nós, já que o pedido de linhas é mais importante que o tempo exato (desde que seja próximo).

    
por 05.01.2015 / 17:15

Tags