Logstash analisando documento xml contendo várias entradas de log

8

Atualmente, estou avaliando se o logstash e o elasticsearch são úteis para nosso caso de uso. O que eu tenho é um arquivo de log contendo múltiplas entradas que são da forma

<root>
    <entry>
        <fieldx>...</fieldx>
        <fieldy>...</fieldy>
        <fieldz>...</fieldz>
        ...
        <fieldarray>
            <fielda>...</fielda>
            <fielda>...</fielda>
            ...
        </fieldarray>
    </entry>
    <entry>
    ...
    </entry>
    ...
<root>

Cada elemento entry conteria um evento de log. (Se você estiver interessado, o arquivo é, na verdade, uma exportação de registro de trabalho do Time Timesheets (An Atlassian JIRA Plug-in).)

É possível transformar esse arquivo em vários eventos de log sem escrever meu próprio codec?

    
por dualed 24.07.2014 / 16:14

2 respostas

11

Tudo bem, encontrei uma solução que funcione para mim. O maior problema com a solução é que o plugin XML é ... não instável, mas mal documentado e com erros ou mal e incorretamente documentado.

TLDR

Linha de comando do Bash:

gzcat -d file.xml.gz | tr -d "\n\r" | xmllint --format - | logstash -f logstash-csv.conf

Configuração do Logstash:

input {
    stdin {}
}

filter {
    # add all lines that have more indentation than double-space to the previous line
    multiline {
        pattern => "^\s\s(\s\s|\<\/entry\>)"
        what => previous
    }
    # multiline filter adds the tag "multiline" only to lines spanning multiple lines
    # We _only_ want those here.
    if "multiline" in [tags] {
        # Add the encoding line here. Could in theory extract this from the
        # first line with a clever filter. Not worth the effort at the moment.
        mutate {
            replace => ["message",'<?xml version="1.0" encoding="UTF-8" ?>%{message}']
        }
        # This filter exports the hierarchy into the field "entry". This will
        # create a very deep structure that elasticsearch does not really like.
        # Which is why I used add_field to flatten it.
        xml {
            target => entry
            source => message
            add_field => {
                fieldx         => "%{[entry][fieldx]}"
                fieldy         => "%{[entry][fieldy]}"
                fieldz         => "%{[entry][fieldz]}"
                # With deeper nested fields, the xml converter actually creates
                # an array containing hashes, which is why you need the [0]
                # -- took me ages to find out.
                fielda         => "%{[entry][fieldarray][0][fielda]}"
                fieldb         => "%{[entry][fieldarray][0][fieldb]}"
                fieldc         => "%{[entry][fieldarray][0][fieldc]}"
            }
        }
        # Remove the intermediate fields before output. "message" contains the
        # original message (XML). You may or may-not want to keep that.
        mutate {
            remove_field => ["message"]
            remove_field => ["entry"]
        }
    }
}

output {
    ...
}

Detalhado

Minha solução funciona porque, pelo menos até o nível entry , minha entrada XML é muito uniforme e, portanto, pode ser manipulada por algum tipo de correspondência de padrões.

Como a exportação é basicamente uma linha muito longa de XML, e o plug-in logstash xml essencialmente funciona apenas com campos (leia-se: colunas em linhas) que contêm dados XML, tive que alterar os dados para um formato mais útil. / p>

Shell: Preparando o arquivo

  • gzcat -d file.xml.gz | : Foram dados demais - obviamente você pode pular isso
  • tr -d "\n\r" | : remova as quebras de linha nos elementos XML: Alguns dos elementos podem conter quebras de linha como dados de caractere. O próximo passo requer que eles sejam removidos ou codificados de alguma forma. Mesmo assumindo que neste momento você tem todo o código XML em uma linha massiva, não importa se este comando remove qualquer espaço em branco entre os elementos

  • xmllint --format - | : Formate o XML com xmllint (vem com libxml)

    Aqui, a única linha de spaghetti com XML ( <root><entry><fieldx>...</fieldx></entry></root> ) está formatada corretamente:

    <root>
      <entry>
        <fieldx>...</fieldx>
        <fieldy>...</fieldy>
        <fieldz>...</fieldz>
        <fieldarray>
          <fielda>...</fielda>
          <fieldb>...</fieldb>
          ...
        </fieldarray>
      </entry>
      <entry>
        ...
      </entry>
      ...
    </root>
    

Logstash

logstash -f logstash-csv.conf

(Veja o conteúdo completo do arquivo .conf na seção TL; DR.)

Aqui, o filtro multiline faz o truque. Pode mesclar várias linhas em uma única mensagem de log. E é por isso que a formatação com xmllint foi necessária:

filter {
    # add all lines that have more indentation than double-space to the previous line
    multiline {
        pattern => "^\s\s(\s\s|\<\/entry\>)"
        what => previous
    }
}

Isso basicamente diz que toda linha com recuo com mais de dois espaços (ou é </entry> / xmllint faz recuo com dois espaços por padrão) pertence a uma linha anterior. Isso também significa que os dados de caractere não devem conter novas linhas (removidos com tr no shell) e que o xml deve ser normalizado (xmllint)

    
por 06.08.2014 / 12:41
1

Eu tive um caso semelhante. Para analisar este xml:

<ROOT number="34">
  <EVENTLIST>
    <EVENT name="hey"/>
    <EVENT name="you"/>
  </EVENTLIST>
</ROOT>

Eu uso esta configuração para logstash:

input {
  file {
    path => "/path/events.xml"
    start_position => "beginning"
    sincedb_path => "/dev/null"
    codec => multiline {
      pattern => "<ROOT"
      negate => "true"
      what => "previous"
      auto_flush_interval => 1
    }
  }
}
filter {
  xml {
    source => "message"
    target => "xml_content"
  }
  split {
    field => "xml_content[EVENTLIST]"
  }
  split {
    field => "xml_content[EVENTLIST][EVENT]"
  }
  mutate {
    add_field => { "number" => "%{xml_content[number]}" }
    add_field => { "name" => "%{xml_content[EVENTLIST][EVENT][name]}" }
    remove_field => ['xml_content', 'message', 'path']
  }
}
output {
  stdout {
    codec => rubydebug
  }
}

Espero que isso possa ajudar alguém. Eu precisei de muito tempo para consegui-lo.

    
por 23.12.2016 / 13:14

Tags