現在、logstashとelasticsearchが私たちのユースケースに役立つかどうかを評価しています。私が持っているのはlog fileという形式の複数のエントリを含みます
<root>
<entry>
<fieldx>...</fieldx>
<fieldy>...</fieldy>
<fieldz>...</fieldz>
...
<fieldarray>
<fielda>...</fielda>
<fielda>...</fielda>
...
</fieldarray>
</entry>
<entry>
...
</entry>
...
<root>
各entry
要素には、1つのログイベントが含まれます。 (興味がある場合、ファイルは実際にはテンポタイムシート(Atlassian JIRAプラグイン)作業ログエクスポートです。)
独自のコーデックを作成せずに、そのようなファイルを複数のログイベントに変換することは可能ですか?
申し分なく、私にはうまくいく解決策を見つけました。ソリューションの最大の問題は、XMLプラグインが非常に不安定ではないということです...しかし、ドキュメントが不十分でバグが多いか、またはドキュメントが不十分で誤ってドキュメント化されています。
Bashコマンドライン:
gzcat -d file.xml.gz | tr -d "\n\r" | xmllint --format - | logstash -f logstash-csv.conf
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 {
...
}
少なくともentry
レベルまで、私のXML入力はvery均一であり、ある種のパターンマッチングで処理できるため、私のソリューションは機能します。
エクスポートは基本的にXMLの非常に長い1行であり、logstash xmlプラグインは基本的にXMLデータを含むフィールド(読み取り:行の列)でのみ機能するため、データをより有用な形式に変更する必要がありました。
gzcat -d file.xml.gz |
:データが多すぎました-明らかにそれをスキップできますtr -d "\n\r" |
:XML要素内の改行を削除:一部の要素には、文字データとして改行を含めることができます。次のステップでは、これらを削除するか、何らかの方法でエンコードする必要があります。この時点ではすべてのXMLコードが1つの大きな行にあると想定していましたが、このコマンドで要素間の空白を削除しても問題ありません
xmllint --format - |
:xmllintでXMLをフォーマットします(libxmlに付属)
ここでは、XMLの単一の巨大なスパゲッティ行(<root><entry><fieldx>...</fieldx></entry></root>
)適切にフォーマットされています:
<root>
<entry>
<fieldx>...</fieldx>
<fieldy>...</fieldy>
<fieldz>...</fieldz>
<fieldarray>
<fielda>...</fielda>
<fieldb>...</fieldb>
...
</fieldarray>
</entry>
<entry>
...
</entry>
...
</root>
logstash -f logstash-csv.conf
(.conf
ファイルはTL; DRセクションにあります。)
ここでは、multiline
フィルターがうまく機能します。複数の行を1つのログメッセージにマージできます。そして、これがxmllint
によるフォーマットが必要だった理由です:
filter {
# add all lines that have more indentation than double-space to the previous line
multiline {
pattern => "^\s\s(\s\s|\<\/entry\>)"
what => previous
}
}
これは基本的に、インデントのあるすべての行が2つ以上のスペース(または</entry>
/xmllintは、デフォルトで2つのスペースでインデントを行います)、前の行に属します。これは、文字データに改行を含めてはならず(シェルではtr
で取り除かれている)、xmlを正規化する必要があることも意味します(xmllint)
私にも似たような事件がありました。このxmlを解析するには:
<ROOT number="34">
<EVENTLIST>
<EVENT name="hey"/>
<EVENT name="you"/>
</EVENTLIST>
</ROOT>
この構成を使用して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
}
}
これが誰かの役に立つことを願っています。それを手に入れるのに長い時間がかかりました。