LogStash で GROK を使用して非構造化データをログから ELK スタックに変換するためのヒントとテクニック

GROK を使用した非構造化データの構造化

Elastic (ELK) スタックを使用していて、カスタム Logstash ログを Elasticsearch にマッピングすることに興味がある場合は、この投稿が最適です。

ELK スタックは、Elasticsearch、Logstash、Kibana という XNUMX つのオープン ソース プロジェクトの頭字語です。 これらは一緒になってログ管理プラットフォームを形成します。

• Elasticsearch は検索および分析システムです。
• ログスタッシュ は、複数のソースから同時にデータを取り込み、変換して、Elasticsearch などの「スタッシュ」に送信するサーバー側のデータ処理パイプラインです。
• 木場 ユーザーは Elasticsearch でチャートやグラフを使用してデータを視覚化できます。

ビート 後から登場した軽量のデータ シッパーです。 Beats の導入により Elk Stack は Elastic Stack に変わりましたが、重要なのはそこではありません。

この記事は、Grok について説明します。Grok は、ログをスタッシュに送信する前に変換できる Logstash の機能です。 ここでは、目的のために、Logstash から Elasticsearch へのデータの処理についてのみ説明します。

Grok は、非構造化データを構造化されたクエリ可能なデータに解析するために使用される Logstash 内のフィルターです。 これは正規表現 (regex) の上に位置し、テキスト パターンを使用してログ ファイル内の文字列と一致します。

次のセクションで説明するように、Grok を使用すると、効率的なログ管理という点で大きな違いが生じます。

Grok がないとログ データは構造化されていません

Grok を使用しない場合、ログが Logstash から Elasticsearch に送信され、Kibana でレンダリングされるとき、ログはメッセージ値にのみ表示されます。

すべてのログ データが XNUMX つのキーに保存されているため、この状況で意味のある情報をクエリすることは困難です。 ログメッセージがもっとよく整理されていればもっと良いでしょう。

ログからの非構造化データ

localhost GET /v2/applink/5c2f4bb3e9fda1234edc64d 400 46ms 5bc6e716b5d6cb35fc9687c0

生データをよく見ると、実際にはスペースで区切られたさまざまな部分で構成されていることがわかります。

経験豊富な開発者であれば、おそらく各部分の意味と、API 呼び出しからのログ メッセージが何であるかを推測できるでしょう。 各項目の概要は以下のとおりです。

データの構造化されたビュー

• localhost == 環境
• GET ==メソッド
• ​ /v2/applink/5c2f4bb3e9fda1234edc64d == url
• 400 == 応答ステータス
• 46ms == 応答時間
• ​ 5bc6e716b5d6cb35fc9687c0 == user_id

構造化データでわかるように、非構造化ログにも順序があります。 次のステップは、生データのソフトウェア処理です。 ここがGrokが輝くところです。

Grok テンプレート

組み込みの Grok テンプレート

Logstash には、非構造化データを構造化するための 100 を超える組み込みテンプレートが付属しています。 Apache、Linux、haproxy、aws などの一般的な syslog では、可能な限りこれを利用する必要があります。

ただし、上記の例のようなカスタム ログがある場合はどうなるでしょうか? 独自の Grok テンプレートを構築する必要があります。

カスタム Grok テンプレート

独自の Grok テンプレートを構築してみる必要があります。 私が使用した Grok デバッガー и Grok パターン.

Grok テンプレートの構文は次のとおりであることに注意してください。 %{SYNTAX:SEMANTIC}

最初にやろうとしたのは、タブに移動することでした 分析による現状把握 Grok デバッガーで。 このツールが Grok パターンを自動的に生成できれば素晴らしいだろうと思いましたが、一致するものが XNUMX つしか見つからなかったため、あまり役に立ちませんでした。

この発見を利用して、Elastic Github ページにある構文を使用して、Grok デバッガーで独自のテンプレートの作成を開始しました。

さまざまな構文を試した結果、最終的に希望どおりにログ データを構造化することができました。

Grok デバッガー リンク https://grokdebug.herokuapp.com/

原文:

localhost GET /v2/applink/5c2f4bb3e9fda1234edc64d 400 46ms 5bc6e716b5d6cb35fc9687c0

パターン：

%{WORD:environment} %{WORD:method} %{URIPATH:url} %{NUMBER:response_status} %{WORD:response_time} %{USERNAME:user_id}

最後に何が起こったのか

{
  "environment": [
    [
      "localhost"
    ]
  ],
  "method": [
    [
      "GET"
    ]
  ],
  "url": [
    [
      "/v2/applink/5c2f4bb3e9fda1234edc64d"
    ]
  ],
  "response_status": [
    [
      "400"
    ]
  ],
  "BASE10NUM": [
    [
      "400"
    ]
  ],
  "response_time": [
    [
      "46ms"
    ]
  ],
  "user_id": [
    [
      "5bc6e716b5d6cb35fc9687c0"
    ]
  ]
}

Grok テンプレートとマップされたデータを用意したら、最後のステップはそれを Logstash に追加することです。

Logstash.conf 構成ファイルの更新

ELK スタックをインストールしたサーバーで、Logstash 構成に移動します。

sudo vi /etc/logstash/conf.d/logstash.conf

変更を貼り付けます。

input { 
  file {
    path => "/your_logs/*.log"
  }
}
filter{
  grok {
    match => { "message" => "%{WORD:environment} %{WORD:method} %{URIPATH:url} %{NUMBER:response_status} %{WORD:response_time} %{USERNAME:user_id}"}
  }
}
output {
  elasticsearch {
    hosts => [ "localhost:9200" ]
  }
}

変更を保存した後、Logstash を再起動し、ステータスをチェックして、まだ動作していることを確認します。

sudo service logstash restart
sudo service logstash status

最後に、変更が有効になっていることを確認するために、 Kibana の Logstash の Elasticsearch インデックスを必ず更新してください。

Grok を使用すると、ログ データが構造化されます。

上の画像でわかるように、Grok はログ データを Elasticsearch と自動的に照合できます。 これにより、ログの管理が容易になり、情報を迅速にクエリできるようになります。 デバッグのためにログ ファイルを調べる代わりに、環境や URL など、探しているもので単純にフィルタリングできます。

Grok 式を試してみてください。 これを行う別の方法がある場合、または上記の例に問題がある場合は、以下にコメントを書いてお知らせください。

読んでいただきありがとうございます。さらに興味深いソフトウェア エンジニアリングの記事を読むために、Medium で私をフォローしてください。

リソース

https://www.elastic.co/blog/do-you-grok-grok
https://github.com/elastic/logstash/blob/v1.4.2/patterns/grok-patterns
https://grokdebug.herokuapp.com/

PS ソースリンク

電報チャンネルによる Elasticsearch

出所： habr.com