Grok の構文を検証する Grok Debugger を試してみた #Kibana

こんにちは、藤本です。

現地時間 7/6 に Elastic Stack 5.5.0 がリリースされました。

早速、新機能を試してみました。まずは先日参加した Machine Learning ワークショップの中で Elastic 大谷さんが触れていた Kibana で Grok Pattern の動作確認ができるようになる、と言っていたのが実装されたようですので試してみました。

https://dev.classmethod.jp/server-side/elasticsearch/elastic-xpack-machine-learning-workshop/

Elastic Stack と Grok

Elastic Stack のよく見るログ可視化のユースケースとして、Apache のアクセスログを Elasticsearch にインデキシングして、Kibana で可視化する、というものがあります。アクセスログは 1行づつのメッセージで構成される非構造化データです。一方で Kibana で可視化するためには意味のあるデータ単位で分割する必要があります。このデータ変換に Grok フィルターが利用されています。Elastic Stack は Grok フィルターを Logstash の Grok filter plugin を利用するパターン、Elasticsearch の Ingest Node の Grok Processor を利用するパターンがあります。前者はアプリケーションサーバ側(もしくはログ変換専用サーバ)でデータ変換を行い、後者は Elasticsearch側 でデータ変換を行います。

Grok の動作を Logstash の場合を例に簡単に説明します。下記のようなアクセスログがあったとします。ログフォーマットは Apache 標準の common で設定しています。

127.0.0.1 - - [19/Jun/2017:01:44:41 +0900] "GET / HTTP/1.1" 200 16121

Grok filter plugin を使って、パースする時、下記のような Grok Pattern を指定します。

  grok {
    match => {
      "message" => '%{HTTPD_COMMONLOG}'
    }
  }

これだと、分かりづらいので下記のようにも表現できます。

  grok {
    match => {
      "message" => '%{IPORHOST:clientip} %{HTTPDUSER:ident} %{HTTPDUSER:auth} \[%{HTTPDATE:timestamp}\] "(?:%{WORD:verb} %{NOTSPACE:request}(?: HTTP/%{NUMBER:httpversion})?|%{DATA:rawrequest})" %{NUMBER:response} (?:%{NUMBER:bytes}|-)'
    }
  }

この Grok filter plugin を通ることでアクセスログは下記のような Key/Value 形式に置き換わります。

Key Value
clientip 127.0.0.1
ident -
auth -
timestamp 19/Jun/2017:01:44:41 +0900
verb GET
request /
httpversion HTTP/1.1
rawrequest GET / HTTP/1.1
response 200
bytes 16121

Grok filter plugin は正規表現で定義した Grok Pattern にマッチした文字列を Key 名とマッピングして抽出します。例えば、clientip が 127.0.0.1 というところに着目すると、%{IPORHOST:clientip}の Grok Pattern を定義することで IPORHOST に一致した文字列を clientip の Key名にマッピングして抽出します。IPORHOST とは何でしょうか。正規表現には見えません。これは IPORHOST という文字列に一致するかどうかではなく、IPORHOST という正規表現のエイリアス(Grok Pattern)に一致するかどうかです。Logstash の Grok filter plugin はよく利用される正規表現パターンをエイリアスで定義しています。エイリアスの定義は<LOGSTASH_GEM_DIR>/logstash-patterns-core-4.1.1/patterns/配下のファイルに用意されています。例えば、IPORHOST はgrok-patternsファイルで定義されています。IPORHOST は(?:%{IP}|%{HOSTNAME})と表記されいてます。今度は IP と HOSTNAME というエイリアスが出てきました。同ファイルに HOSTNAME が定義されていて\b(?:[0-9A-Za-z][0-9A-Za-z-]{0,62})(?:\.(?:[0-9A-Za-z][0-9A-Za-z-]{0,62}))*(\.?|\b)の正規表現で表記されています。先に記載した%{HTTPD_COMMONLOG}は後のパターンのエイリアスとなります。

HOSTNAME は用意されているものですが、この条件を満たす正規表現を自分で考えるのは難しいですよね。Logstash コマンドに --config.test_and_exit オプションはありますが、設定ファイルのフォーマットしか見てくれません。Grok Pattern の妥当性は検証しません。

そこで今回リリースされた Grok Debbuger の出番です。

Grok Debbuger

Grok Debbuger は Kibana の GUI 上から Grok Pattern の妥当性を検証する機能です。入力となるメッセージ、設定する Grok Pattern を入力すると、正常にパースできるか、正常にパースされる場合はどういう Key/Value になるか JSON 形式で出力されます。ちなみに Grok Debugger は X-Pack の機能としてリリースされました。X-Pack ってあの有償プラグインの?と思われる方いらっしゃるかもしれませんが、Grok Debbuger は BASIC サブスクリプションから利用できますので無償で利用可能です。BASIC サブスクリプションの機能が Amazon Elasticsearch Service との分かりやすい機能の差別化になってくるのかな。

話を戻して、早速試してみましょう。

環境

  • OS : CentOS 7
  • Elasticsearch : 5.5.0
  • Kibana : 5.5.0

X-Pack インストール

X-Pack は Elasticsearch、Kibana のプラグインとしてインストールしますので、コマンドにて簡単にインストールできます。今回は BASIC ライセンスではなく、Trial ライセンスです。

# /usr/share/elasticsearch/bin/elasticsearch-plugin install x-pack
-> Downloading x-pack from elastic
[=================================================] 100%
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@     WARNING: plugin requires additional permissions     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
* java.io.FilePermission \\.\pipe\* read,write
* java.lang.RuntimePermission accessClassInPackage.com.sun.activation.registries
* java.lang.RuntimePermission getClassLoader
* java.lang.RuntimePermission setContextClassLoader
* java.lang.RuntimePermission setFactory
* java.security.SecurityPermission createPolicy.JavaPolicy
* java.security.SecurityPermission getPolicy
* java.security.SecurityPermission putProviderProperty.BC
* java.security.SecurityPermission setPolicy
* java.util.PropertyPermission * read,write
* java.util.PropertyPermission sun.nio.ch.bugLevel write
* javax.net.ssl.SSLPermission setHostnameVerifier
See http://docs.oracle.com/javase/8/docs/technotes/guides/security/permissions.html
for descriptions of what these permissions allow and the associated risks.

Continue with installation? [y/N]y
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@        WARNING: plugin forks a native controller        @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
This plugin launches a native controller that is not subject to the Java
security manager nor to system call filters.

Continue with installation? [y/N]y
-> Installed x-pack

# /usr/share/kibana/bin/kibana-plugin install x-pack
Attempting to transfer from x-pack
Attempting to transfer from https://artifacts.elastic.co/downloads/kibana-plugins/x-pack/x-pack-5.5.0.zip
Transferring 119276235 bytes....................
Transfer complete
Retrieving metadata from plugin archive
Extracting plugin archive
Extraction complete
Optimizing and caching browser bundles...
Plugin installation complete

X−Pack をインストールしたら、Elasticsearch、Kibana を再起動します。

# systemctl restart elasticsearch
# systemctl restart kibana

Kibana へアクセス

Web ブラウザから Kibana へアクセスします。ログイン画面が表示されるので、デフォルトユーザー(elastic/changeme)でログインします。

Kibana 3

ログインしたら、左メニューの Dev Tools を選択し、Grok Debbuger を選択します。

Console_-_Kibana

Grok Debbuger の画面です。入力項目も少ないので分かりやすいですね。

Kibana 2

デバッグしてみる

それでは最初に記載したログメッセージと、2つ目の Grok Pattern で動作を確認してみましょう。

Kibana 4

想定通りの結果となりました。

ちなみに最初の Grok Pattern はどうでしょうか。

Kibana_2

あれ?エラーが発生しました。

先ほど Logstash の Grok Pattern のエイリアスディレクトリを説明しましたが、この機能で見る Grok Pattern のエイリアスディレクトリは Elasticsearch の Grok Processor のようです。Grok Processor で定義された Grok Pattern のエイリアスは下記をご参照ください。(公式ドキュメントでは Logstash と Ingest Node は共通のパターンライブラリを見ていると記載があるのですが、、)

Grok Processor 側に合わせると下記の記載となります。

%{COMMONAPACHELOG}

Grok Debugger でも正常にパースできました。

Kibana 5

まとめ

いかがでしたでしょうか? Grok Debbuger により正規表現の検証が簡単になりました。また Elasticsearch に登録されている Grok Pattern も検証に利用できるのでサードパーティの Grok 検証ツールを使うよりも効率的に検証できますね。