あらすじ

AWS CloudTrailをLogstashで加工したときにGrok Filterでハマったので、つまづき事例の投稿です。
タイトルの「①」は今後もハマるような気がするからですｗ

利用バージョン

Logstash 6.6.2

Logstashでやろうと思ったこと

AWS CloudTrailのuserIdentity.principalIdの:(コロン)の右側の値である
(例)abcde@sample.co.jpをKibanaの分析に利用するためにGrok Filterを使います。

sample_log

    "userIdentity": {
        "type": "AssumedRole",
        "principalId": "FVG2RTG1FCDFW1R5SVK2:abcde@sample.co.jp",
        "arn": "arn:aws:sts::xxxxxxxxxxxx:assumed-role/iam-user/abcde@sample.co.jp",
        "accountId": "xxxxxxxxxxxx"

※CloudTrailのログサンプルの一部抜粋です。

Grok Constructorを使う

LogstashのGrok Filterを使う上で欠かせないデバッグツールであるGrok Constructorを使います。
①Matchタブを選択し、②に正規化したい文字列を張り付けます。
※今回は1レコードのみですが、複数レコードを張り付けて全てにマッチする正規化フィルタになっているか確認が出来ます。

コロンの左側(FVG2RTG1FCDFW1R5SVK2)は大文字英字と数値の組み合わせ
コロンの右側(abcde@sample.co.jp)はメールアドレス(小文字英字、数値、@、_、-、.等の記号の組み合わせ)
なので、grok-patternsにあるWORDとGREEDYDATAを利用します。
③には%{WORD:principalid}:%{GREEDYDATA:userid}と入力します。

grok-patternsの抜粋

WORD \b\w+\b
GREEDYDATA .*

Go!ボタンを押すと下部に結果が出ます。こんな感じです。マッチしているので、OKですね！

※1つ目のField名をprincipalid、2つ目をField名をuseridとしています。

Logstashのconfを書く

Grok Constructorの結果を踏まえ、/etc/logstash/conf.d/logstash.confを書いてみました。
※以下、filter句の抜粋です。

logstash.confの抜粋

filter {
  json {
    source => "message"
  }
  grok {
    match => { "userIdentity.principalId" => "%{WORD:principalid}:%{GREEDYDATA:userid}" }
    tag_on_failure => [ "_userIdentity.principalId_parse_failure" ]
  }

結果はなんとtags: _userIdentity.principalId_parse_failureとなり、grok filterがマッチしませんでした。ここから原因特定のための切り分けを開始しましたが、以下の2点をまず疑いました。

2つのgrok patternsの間に挟まっている:(コロン)をエスケープする必要があったのか？
grok patternsのファイルをなぜか認識出来ていないのでは？

これまでそんなことでハマったことはなく、\(バックスラッシュ)で:(コロン)をエスケープしてもNG
わざわざ、patterns_dirで明示的にパスをしてもNGでした。あたり前ですよねｗ

ちなみにRPMでlogstashをインストールしている場合、grok patternsは以下にあります。
/usr/share/logstash/vendor/bundle/jruby/2.3.0/gems/logstash-patterns-core-4.1.2/patterns

ここは勘に頼ることになりましたが、userIdentity.principalIdというField名を認識出来ていないのでは？と思い、.(ドット)表記を止めて、[userIdentity][principalId]とすることで解決しました。

logstash.confのOK版

filter {
  json {
    source => "message"
  }
  grok {
    match => { "[userIdentity][principalId]" => "%{WORD:principalid}:%{GREEDYDATA:userid}" }
    tag_on_failure => [ "_userIdentity.principalId_parse_failure" ]
  }

まとめ

1～2時間ハマってしまいましたが、無事解決出来てホッとしました。
LogstashのPluginによって、.(ドット)で認識出来ない場合もあるので、注意が必要だなと改めて思いました。
階層構造になっているFieldを扱う場合は、[](角括弧)を使う方が無難ですね。

ハマったネタは恥ずかしがらずに公開すると意外と幸せになれる人がいると思っているので
投稿してみました^^;