Logstash on @johtaniの日記 3rd

Logstash 2.0.0リリース（日本語訳）

Thu, 29 Oct 2015 16:19:57 +0900

※この記事は次のブログを翻訳したものになります。

Logstash 2.0.0が本日（10/28）リリースされました。このリリースはいくつかの設定に関する重要な変更があります。詳細については、changelogまたは、新しいbreaking changesドキュメントをご覧下さい。

これまでの2.0.0直前のリリースに関する変更点はこちらをご覧ください。

ここでは、2.0の主な変更点の概要を説明します。

Elasticsearch 2.0との互換性

多くの機能および改善を含んだElasticsearch 2.0がリリースされました。 Logstash 2.0はこのリリースに対応しています。 Logstashのこれまでのリリースでは、デフォルトで、Javaの node clientをElasticsearchとの通信として使用してきました。 2.0では、HTTPクライアントがデフォルトになります。これにより、シームレスにユーザのデータを取り込み、付加価値をつけ、Elasticsearchに保存して解析することができます。

HTTPは他のプロトコル（nodeやtransport）同等の機能を持っていますが、単一のクライアントに接続する時に、少しだけ遅いですが、管理や動作がより簡単です。 HTTPプロトコルを使うことで、Elasticsearchのバージョンのアップグレードが、Logstashのアップグレードすることなく行うことができます。デフォルトをHTTPに変更したさらに詳しい情報についてはbeta1のブログをご覧ください。

他のプロトコル（nodeとtransport）もサポートしますが、これらを利用する場合には、プラグインを別途インストールする必要があります。

bin/plugin install --version 2.0.0 logstash-output-elasticsearch_java

互換性のマトリックス

LogstashとElasticsearchのバージョンの互換性は次のようになります。

画像あり。 ※画像に関しては原文をご覧ください。 #Image https://www.elastic.co/assets/bltde5b69e2164aa82f%2Fcompat_matrix.png

Shield 2.0との互換性

このリリースはShield 2.0リリースにも対応しています。 HTTPプロトコルで、追加のプラグインは必要ありません。こちらのドキュメントをご覧ください。 transportプロトコルでは、Shield 2.0対応のプラグインを個別にインストールする必要があります。

bin/plugin install --version 2.0.0 logstash-output-elasticsearch_java_shield

パフォーマンスの改善

このリリースはまた、多くの部分のパフォーマンスの改善を含んでおり、Logstashを利用してデータをより早く処理することができます。いくつかをここで説明します。

UserAgentとGeoIPフィルタ：これらのフィルタで、LRUキャッシュを追加して改善しています。これにより、IPとユーザエージェントがまとまって現れるというWebリクエストの特性を用いています。ユーザエージェントフィルタのケースでは、サンプルデータセットにおいて3.7倍ほど早くなりました。 GeoIPでは、1.69倍早くなっています。
JSONプロセシング：LogstashでJSONのsiriaraizu/でシリアライズに利用しているJrJacksonを新しいバージョンにしました。これにより、JSONの処理が改善されています。
フィルタワーカーのより良い値をデフォルトに：以前のリリースでは、filter_workersの設定は1がデフォルトでした。これは、フィルタの処理を行うワーカーが1つであるという意味です。 filter_workersの設定のデフォルト値はCPUコア数の半分の値を設定します。フィルタ実行の並列性が上がります。ですので、複雑なgrokパターンやuseragentフィルタの処理がにとっては重要です。

Filebeat Support

Filebeatのベータバージョンを先日リリースしました。これは、Logstash Forwarderの次期バージョンです。 Filebeatはファイルベースのログをさらに処理するためにLogstashに送るためのエージェントです。 2.0.0はlogstash-input-beatsプラグインを使えばFilebeat 1.0.0-beta4とすぐに動作します。

シャットダウン操作

これまでのLogstashでは、シャットダウンが開始した時に、例外の機構でシャットダウンが開始したことをプラグインに通知していました。この処理はサードパーティのコードを使ったプラグインで問題を起こしていました。 Logstashはどの例外を処理するか知らないため、予期しない動作をしていました。これを修正するためにAPI呼び出し（例えばstop）を各プラグインにシャットダウンのイベントを通知し、プラグイン自身がきちんと停止するようにしました。これは、200以上のプラグインに新しいAPIを利用するように修正しないといけないことを意味しました。しかし、Logstashの停止についてはまだ完全にはフィックスしていません。とちゅうでおわっているoutputがシャットダウンを遅らせる可能性があるからです。 2.0でAPIの破壊的な変更は適切なリリースでの変更を繰り返すことができる出発点です。

プラグインの開発者へ：もし、Logstash　1.5のプラグインを開発しているなら、シャットダウンに関する新しいAPIのリストに関するbreaking changesのドキュメントに助言をください。また、example inputリポジトリにて、新しいシャットダウンメカニズムの使い方のサンプルコードを提供しています。

ドキュメント

2.0に更新されたドキュメントはこちらです。設定の変更についてもこちらをご覧ください。

2.0へのアップデート

2.0へアップデートする前に、アップデートガイドもご覧ください。

フィードバック

2.0のリリースできたことに、多くのコントリビューター、ユーザに感謝しています。このリリースに含まれている多くのパッチと全てのプレリリースのテストにも感謝しています。将来の修正やリリースなどについてはロードマップをご覧ください。 2.0は今日リリースされました。ご意見ご感想はWebフォーラムで！

Release, we have（日本語訳）

Thu, 29 Oct 2015 14:18:59 +0900

※この記事は次のブログを翻訳したものになります。

原文：Relase, we have ※画像に関しては原文をご覧ください。

Elasticにとって大きな1日（社内では「release bonanza」と呼んでいる）です。多くの主要なプロダクトを新たにリリースしました。そして、本日、それらを一緒に利用する時にそれらを一緒に利用する時にユーザの体験についてまとめてみました。

次の通りです。

Elasticsearch 2.0リリース。大きなマイルストーン、チームによる改善、そして、コミュニティからの素晴らしい貢献。 Pipeline Aggsと呼ばれる新しいタイプのaggregations、クエリとフィルタのコンセプトを統合することにより簡素化されたクエリDSL、 better compressionオプション、 JavaのSecurity Managerを有効にすることによる強化されたセキュリティ、 FSの挙動に関する強化（fsync、checksum、atmicなリネーム）、パフォーマンス、マッピングの挙動の一貫性などなどです。また、我々のチームによる改善も含まれているLucene 5ベースにアップグレードしています。

Kibana 4.2リリース。 Elasticsearch 2.0対応、ダークテーマ、カスタマイズ可能な地図、多くの改善。 Kibana 4.2の多くに作業については外部プラグインサポートといった、内蔵に関するものでした。この後の説明に続きます。

Marvel 2.0リリース。 Elasticsearch 2.0対応、合理化されたメトリックス、簡素化されたUI、多くはKibanaプラグイン（Kibanaプラットフォーム上に構築）としての書き換えです。このKibana拡張の最初の努力は、Kibanaのプラグインをどうやって書くか、 Kibanaユーザに公式に何をする必要があるかといったものを特定するのに役立ちました。おっと、忘れるところでした、Marvelを全てのユーザにフリーで使えるようにしました。マルチクラスタサポートについては有償となります。

Sense 2.0リリース。 2つ目のKibanaプラグインがこれです。 SenseをKibanaプラグインとして書き換えました。 Elasticsearch 2.0サポート、複数リクエストの実行、 curlへのコピーなどです。おっと、忘れるところでした。オープンソースとすることにしました！

Shield + Watcher 2.0リリース。ElasticsearchのためのセキュリティプラグインであるShieldと、アラート管理のためのプラグインであるWatcherにも多くの結果が入っています。最も要求のあった機能である、フィールドお呼びドキュメントレベルでのセキュリティについて、Luceneに落とし込んで実装しました。また、セキュリティの操作についてプラガブルに実装できるように変更しました。 Watcherは監視の無効化、SlackやHipChatへの通知（bot ops向け）が可能です。

Logstash 2.0リリース。 Elasticsearch 2.0のサポート、クリーンな停止、全面的なパフォーマンス改善、Beatsサポート。

ご覧の通り、すべてのプロダクトに関する大きな結果です。チーム間およびFoundの開発者との間での密な連携に感謝します。これらが私たちが公式にElasticsearch / KibanaをホストしているFoundで利用可能です。

ひゅう、息切れしました。チームがしてきたことは、感動的で、謙虚で、刺激的です！ Elasticが会社として、全てのユーザ、コントリビュータがどのように私たちの大きなミッションに対する結果をもたらしたかという素晴らしい良い例です。ユーザに愛され、楽しまれ、成功に導き、革新させる製品を是非ご利用ください。ありがとうございます。

“A Lion, in Africa?” - まだまだ終わりではありません。この文言で終わりにしますが、すぐに（本当にすぐに）戻ってきます。;)

Logstashを使ったElasticsearchの再インデックス（日本語訳）

Tue, 26 May 2015 16:08:10 +0900

※この記事は次のブログを翻訳したものになります。

原文：Reindex Elasticsearch With Logstash

Thanks David!

マッピングを変更したり、インデックスの設定を変更したり、あるサーバから他のサーバや、あるクラスタから他のクラスタ（例えば複数のデータセンターのような場合）にデータを再インデックスしたくなることがあるでしょう。

後者のような場合はSnapshotやRestoreの機能を利用することもできますが、インデックスの設定を変更をしたい場合はその他の方法が必要になります。

Logstash 1.5.0で、 elasticsearch inputとelasticsearch outputを使うことで、とても簡単に再インデックスができます。

ではやってみましょう。

古いクラスタ

elasticsearch 1.5.2 はすでにダウンロード済みとして、localhost:9200でoldという名前のクラスタを起動します。

bin/elasticsearch --cluster.name=old

クラスタにpersonという名前のインデックスが存在します。これは、5シャードで、100万件のドキュメントを持っています。

新しいクラスタ

次に新しいクラスタを起動します。 localhost:9201でnewという名前のクラスタを起動します。

bin/elasticsearch --cluster.name=new

こちらは、空です。

curl -XGET "http://localhost:9201/person"

{
   "error": "IndexMissingException[[person] missing]",
   "status": 404
}

Logstashのインストール

次に、Logstash 1.5.0をダウンロードして、インストールします。

wget http://download.elastic.co/logstash/logstash/logstash-1.5.0.tar.gz
tar xzf logstash-1.5.0.tar.gz
cd logstash-1.5.0

logstashの設定ファイルlogstash.confを次のように設定します。

input {
  # We read from the "old" cluster
  elasticsearch {
    hosts => [ "localhost" ]
    port => "9200"
    index => "person"
    size => 500
    scroll => "5m"
    docinfo => true
  }
}

output {
  # We write to the "new" cluster
  elasticsearch {
    host => "localhost"
    port => "9201"
    protocol => "http"
    index => "%{[@metadata][_index]}"
    index_type => "%{[@metadata][_type]}"
    document_id => "%{[@metadata][_id]}"
  }
  # We print dots to see it in action
  stdout {
    codec => "dots"
  }
}

実行と修正

実行します。

bin/logstash -f logstash.conf

ドキュメントのチェックと修正

何が起きたでしょう？

curl -XGET "http://localhost:9200/person/person/AU1wqyQWZJKU8OibfxgH"

{
   "_index": "person",
   "_type": "person",
   "_id": "AU1wqyQWZJKU8OibfxgH",
   "_version": 1,
   "found": true,
   "_source": {
      "name": "Tali Elyne",
      "dateOfBirth": "1955-05-03",
      "gender": "female",
      "children": 2,
      "marketing": {
         "cars": null,
         "shoes": null,
         "toys": null,
         "fashion": null,
         "music": null,
         "garden": null,
         "electronic": null,
         "hifi": null,
         "food": 846
      },
      "address": {
         "country": "Germany",
         "zipcode": "0099",
         "city": "Bonn",
         "countrycode": "DE",
         "location": [
            7.075943707068682,
            50.72883500730124
         ]
      }
   }
}

もう一方のクラスタと比較してみましょう。

curl -XGET "http://localhost:9201/person/person/AU1wqyQWZJKU8OibfxgH"

{
   "_index": "person",
   "_type": "person",
   "_id": "AU1wqyQWZJKU8OibfxgH",
   "_version": 1,
   "found": true,
   "_source": {
      "name": "Tali Elyne",
      "dateOfBirth": "1955-05-03",
      "gender": "female",
      "children": 2,
      "marketing": {
         "cars": null,
         "shoes": null,
         "toys": null,
         "fashion": null,
         "music": null,
         "garden": null,
         "electronic": null,
         "hifi": null,
         "food": 846
      },
      "address": {
         "country": "Germany",
         "zipcode": "0099",
         "city": "Bonn",
         "countrycode": "DE",
         "location": [
            7.075943707068682,
            50.72883500730124
         ]
      },
      "@version": "1",
      "@timestamp": "2015-05-20T09:53:44.089Z"
   }
}

Logstashは@versionと@timestampフィールドを追加してしました。これらを除去したいので、Mutate filter pluginのremove_fieldを使います。

filter {
  mutate {
    remove_field => [ "@timestamp", "@version" ]
  }
}

マッピングのチェックと修正

実際に、logstashは_sourceフィールドを既存のドキュメントから読み込み、それらを新しいクラスタに直接投入しています。しかし、logstashはマッピングについてはケアしていません。

古いマッピングと新しいマッピングを比較するために、マッピングを取得してみましょう。

curl -XGET "http://localhost:9200/person/person/_mapping"

{
   "person": {
      "mappings": {
         "person": {
            "properties": {
               "address": {
                  "properties": {
                     "city": {
                        "type": "string",
                        "index": "not_analyzed"
                     },
                     "country": {
                        "type": "string",
                        "index": "not_analyzed"
                     },
                     "countrycode": {
                        "type": "string",
                        "index": "not_analyzed"
                     },
                     "location": {
                        "type": "geo_point"
                     },
                     "zipcode": {
                        "type": "string"
                     }
                  }
               },
               "children": {
                  "type": "long"
               },
               "dateOfBirth": {
                  "type": "date",
                  "format": "dateOptionalTime"
               },
               "gender": {
                  "type": "string",
                  "index": "not_analyzed"
               },
               "marketing": {
                  "properties": {
                     "cars": {
                        "type": "long"
                     },
                     "electronic": {
                        "type": "long"
                     },
                     "fashion": {
                        "type": "long"
                     },
                     "food": {
                        "type": "long"
                     },
                     "garden": {
                        "type": "long"
                     },
                     "hifi": {
                        "type": "long"
                     },
                     "music": {
                        "type": "long"
                     },
                     "shoes": {
                        "type": "long"
                     },
                     "toys": {
                        "type": "long"
                     }
                  }
               },
               "name": {
                  "type": "string"
               }
            }
         }
      }
   }
}

curl -XGET "http://localhost:9201/person/person/_mapping"

{
   "person": {
      "mappings": {
         "person": {
            "properties": {
               "address": {
                  "properties": {
                     "city": {
                        "type": "string"
                     },
                     "country": {
                        "type": "string"
                     },
                     "countrycode": {
                        "type": "string"
                     },
                     "location": {
                        "type": "double"
                     },
                     "zipcode": {
                        "type": "string"
                     }
                  }
               },
               "children": {
                  "type": "long"
               },
               "dateOfBirth": {
                  "type": "date",
                  "format": "dateOptionalTime"
               },
               "gender": {
                  "type": "string"
               },
               "marketing": {
                  "properties": {
                     "cars": {
                        "type": "long"
                     },
                     "electronic": {
                        "type": "long"
                     },
                     "fashion": {
                        "type": "long"
                     },
                     "food": {
                        "type": "long"
                     },
                     "garden": {
                        "type": "long"
                     },
                     "hifi": {
                        "type": "long"
                     },
                     "music": {
                        "type": "long"
                     },
                     "shoes": {
                        "type": "long"
                     },
                     "toys": {
                        "type": "long"
                     }
                  }
               },
               "name": {
                  "type": "string"
               }
            }
         }
      }
   }
}

これにより、いくつかの相違を発見できます。

 "location": {
    "type": "geo_point"
 }

 "location": {
    "type": "double"
 }

データをインデックスする「前」に、実際に利用したいマッピングでインデックスを作成しておくことで、この問題に対処できます。この時点で、オリジナルのマッピングを望んだ形に変更することができます。例えば、アナライザを変更したりです。また、インデックスの設定を新しく定義することもできます。デフォルトでは、Elasticsearchは5つのシャードと各シャードに対して1つのレプリカを作成します。しかし、この時点でもう一度変更することが可能です。

curl -XDELETE "http://localhost:9201/person"
curl -XPUT "http://localhost:9201/person" -d'
{
  "settings": {
    "number_of_shards": 1,
    "number_of_replicas": 0
  }
}'
curl -XPUT "http://localhost:9201/person/person/_mapping" -d'
{
  "person": {
    "properties": {
      "address": {
        "properties": {
          "city": {
            "type": "string",
            "index": "not_analyzed"
          },
          "country": {
            "type": "string",
            "index": "not_analyzed"
          },
          "countrycode": {
            "type": "string",
            "index": "not_analyzed"
          },
          "location": {
            "type": "geo_point"
          },
          "zipcode": {
            "type": "string"
          }
        }
      },
      "children": {
        "type": "long"
      },
      "dateOfBirth": {
        "type": "date",
        "format": "dateOptionalTime"
      },
      "gender": {
        "type": "string",
        "index": "not_analyzed"
      },
      "marketing": {
        "properties": {
          "cars": {
            "type": "long"
          },
          "electronic": {
            "type": "long"
          },
          "fashion": {
            "type": "long"
          },
          "food": {
            "type": "long"
          },
          "garden": {
            "type": "long"
          },
          "hifi": {
            "type": "long"
          },
          "music": {
            "type": "long"
          },
          "shoes": {
            "type": "long"
          },
          "toys": {
            "type": "long"
          }
        }
      },
      "name": {
        "type": "string"
      }
    }
  }
}'

さて、もう一度再インデックスしましょう！

bin/logstash -f logstash.conf

インデックスやタイプ名の変更

もちろん、インデックス名やタイプ名、IDを変更したい場合も変更が可能です！:)

  elasticsearch {
    host => "localhost"
    port => "9201"
    protocol => "http"
    index => "europe_people"
    index_type => "someone"
    document_id => "%{[@metadata][_id]}"
  }

Logstashプラグインのエコシステムの変更（日本語訳）

Sun, 14 Dec 2014 01:00:40 +0900

※この記事は次のブログを翻訳したものになります。

原文：exciting logstash plugin ecosystem changes

Logstash 1.5.0 Beta 1(お試しはこちら)のリリースで、プラグインのインストール、管理、公開の方法を変更しています。ユーザやコミュニティからフィードバックをもらいました。その目的は、プラグインの利用や開発をより簡単にすることです。このプロジェクトは始まったばかりです。プラグインのコミュニティを探し、共有するためのワンストップソリューションを提供するこのアイデアを改善していく予定です。このブログで、この決定を行った理由を説明し、新しいワークフローをと今後のロードマップを説明します。

プラグインがあります！

Logstashは、プラグイン（input、filter、output、codec）が豊富にあります。これらは、Elasticsearchにより開発されたものと、コミュニティからコントリビュートされたものです。 Logstashの主な特長の1つは、これらのプラグインの有効性と動作を拡張するプラグインを追加するのが簡単なことです。現在、165以上のプラグインがエコシステムにあり、これらは、2つのプロジェクトに分かれています。

logstash-coreは最もよく使われるプラグインで、Logstashにデフォルトで含まれます
logstash-contribはコミュニティにより開発されたプラグインを含み、別途ダウンロードできます

新プラグインエコシステムの変更

1.5.0では、全てのプラグインは、Logstashコアから分離され、rubygemsを使って個別にパッケージングされます。 rubygemsを選択したのは、依存関係のあるライブラリの配布とパッケージングがパワフルで一般的なものだからです。さらに、rubygems.orgプラットフォームは配布や探索に影響があります。また、Logstashにプラグインをインストール、アップデート、削除するのが簡単な基盤も追加しました。 contribプロジェクトは徐々に終了します。全てのプラグインは個別のプロジェクトになります。

プラグインエコシステム変更の理由

多数のプラグインをもっていると、配布と公開に関して難題が出てきます。私たちが変更するに至った理由は次のようなものです。

現在は、プラグインの更新に伴い、Logstashの新バージョンのリリースが必要
開発者は、Logstashのリリース間隔とは別に、新バージョンをリリースをしたい
プラグイン開発者は、外部依存を記述できるようにしたい
Logstashコアの配布パッケージのダウンロードサイズを小さくし、ユーザは必要なプラグインのみインストール
logstash-contribを1つのリポジトリとして管理するのは難しい

詳細：

ソースコードの場所

Logstashのソースコードは、今後も現在のGitHubのリポジトリのままです。しかし、プラグインに関するコードやテストコードは含まなくなります。この分離により、個別のプラグインの改善と同様にコアの改善に集中できます。これにより、Logstashプロジェクトの全体の品質も向上します。

全プラグインのソースコードは、新しいGitHub organization、logstash-pluginsにて管理します。各プラグインは個別のリポジトリとして、ここに配置されます。一見すると、これはメンテナンスが難しくなるように思えます。しかし、テスト、Issue、依存関係を明確にすることができます。私たちの目的は、テスト、ドキュメント、gemの公開の自動化であり、これを簡単にするためのツールを追加します。

しかし、プラグインの開発者はプラグインのソースコードソースコードをlogstash-pluginsに置く必要はありません。ーコミュニティで利用可能にするために、rubygems.orgでそれを公開するだけで良いです。

ワークフロー

ここで、新プラグインエコシステムのやりとり/ワークフローについて、いくつかの観点から説明します。

logstashユーザ:

ユーザは、これまでのリリース同様にLogstashのバイナリをダウンロードします。 Logstash 1.5.0は、1.4.2でパッケージされていたプラグインと同等のものが含まれています。新しいシステムに簡単に移行できるようにです。そして、ユーザは、最初のデプロイの後に、Logstashプラグインのをインストール、アップグレードできるようになります。

$LS_HOME/bin/pluginスクリプトがプラグイン操作に関連するコマンドになります。

プラグインのインストール

プラグインのほとんどはgemとしてrubygems.orgにアップロードされます。例えば、もしユーザがApache Kafka outputプラグインをインストールする場合、次のコマンドを実行します。

bin/plugin install logstash-output-kafka

または、ファイルをダウンロード済みの場合は次のコマンドとなります。

bin/plugin install /path/to/logstash-output-kafka-1.0.0.gem

プラグインの削除

bin/plugin uninstall logstash-output-kafka

1つまた全プラグインのアップデート

bin/plugin update

bin/plugin update logstash-output-kafka

プラグインのリストアップ

bin/plugin list

bin/plugin list elasticsearch ( List all plugins containing a name )

bin/plugin list --group output ( list all outputs )

ドキュメント

プラグインが個別に管理されても、全プラグインのドキュメントは1カ所です。

logstash plugin開発者:

プラグイン開発者と作者は、Logstashエコシステムのためにプラグインを公開することができます。プラグインは、gemやJavaライブラリの依存関係を宣言できます。より重要なのは、Logstashのリリース間隔に関係なく、プラグインの改善版をリリースできます。

Rubygemsテクノロジはパッケージングシステム、依存関係管理、ホスティングのために選択されてきました。 Rubyのgemを公開することに慣れている開発者は、Logstashプラグインを簡単に公開することができます。 Elasticsearchはこれらの機能に関して開発者を支援するために、ツールを提供、メンテナンスします。

開発およびローカルでのテスト

JRuby 1.7.16がプラグインを開発するための唯一の前提条件です。プラグインにパッチを提供するのは以前と同様です。例えば、logstash-output-kafkaにパッチを送るのは次のようになります。

git clone https://github.com/logstash-plugins/logstash-output-kafka.git
変更
プラグインをローカルでテスト
- bundle install
- bundle exec rspec
- Logstashの他のバージョンもしくはローカルでテストする場合、Gemfileを編集し、次のように別のロケーションを加えます。gem "logstash", :github => "elasticsearch/logstash", :ref => "master"
新しいPull Requestをlogstash-output-kafkaに対して作成
コミュニティでコードレビューを受け、Elasticsearchがパッチを受け入れ

バージョン

バージョン情報は、それぞれのプラグインの.gemspecで管理します。例えば、Apache Kafka outputのgemspecはこちらです。バージョニングはsemantic versioningのルールに従い、 Logstashのバージョニングとは別に、プラグインの開発者によって管理されます。 Logstash 1.5.0がリリースされると、マイルストーン1のプラグインはバージョン1.0.0となり、マイルストーン2のプラグインはバージョン2.0.0となるでしょう。

公開

開発者が変更を加えプラグインを公開したいと思った時、.gemspecのバージョン番号を変更します。全テストが成功した時、Elasticsearchはrubygems.orgにプラグインを手動で公開します。もし、テストが失敗した場合、プラグインは公開されません。長期的には、プラグインの公開の自動化を行いたいと思っています。この変更は新しいため、公開の自動化を提供する前に、自動化についてより理解し、プラグインのテスト基盤を改良したいと思っています。

Issue

Issueは、各プラグインのGitHubリポジトリに対してオープンなければなりません。 Logstashコアのリポジトリは、コアのパイプラインや共通的な機能に関連するIssueについて扱います。

ドキュメント

プラグインのドキュメントはソースコード自体から生成されます。それぞれのプラグインのドキュメントは、そのプラグインのリポジトリに含まれます。 Elasticsearchは elasticsearch.org/guideに全てのプラグインのドキュメントを集め生成できる基盤を提供します。

移行

全ての新しいpull requestとissueはlogstash-plugin organisation配下にある各プラグインのリポジトリに対してオープンする必要があります。

すでにあるPRはどうすれば良いですか？

気にしないでください。すでにあるpull requestは開発者によって移行する必要はありません。 LogstashチームがLogstashコアリポジトリに対してのPRを、個別の関連するプラグインのリポジトリに対してマージします。

git clone … # clone the specific plugin repo
# now apply the patch
curl -s https://github.com/elasticsearch/logstash/pull/XXXX | git am --3way
git push

Note:このプロセスはすでにあるPRに対してgit historyを管理します

GitHub Issue

現在、LogstashリポジトリにオープンされているIssueは、それぞれのプラグインのリポジトリに移行します。 Logstashチームがgithub.com APIを利用してこの処理を自動的に行います。安心してください。私たちが個別のプラグインに対する既存のIssueを移行します。

今後のロードマップ

これは、最初のステップであり、これらの変更は、ユーザや開発者に対してエコシステムをよりよくするために、しっかりとした基盤を提供します。

短期的には、開発者のためにpull requestのフィードバックでテスト自動化を提供する基盤を追加していきます。プラグインリポジトリのブートストラップや管理のためのツールも提供していきます。

長期的には、すべてのLogstashプラグインを探し、公開するためのコミュニティポータルを提供したいと思っています。このアイデアは、Puppet ForgeやAWS marketplaceのようなものです。

Logstash 1.5.0 Beta 1をリリースし、これは新しいエコシステムを提供します。ぜひ、試していただき、これらの変更に関して感じたことを教えてください。あなたのフィードバック(TwitterもしくはGitHub)はとても貴重です！

Logstash 1.5.0 Beta1リリース(日本語訳)

Fri, 12 Dec 2014 17:17:26 +0900

※この記事は次のブログを翻訳したものになります。

原文：logstash 1.5.0.beta1 released

Logstash 1.5.0 Beta1をリリースしました。こちらのページからダウンロードできます。

Note: ベータリリースです。本番環境では使用しないでください。

1.5.0の主な変更点は？

1.5.0の主なテーマはプラグイン管理、パフォーマンス改善、Apache Kafkaインテグレーションです。Logstashの主な特徴の1つはプラグインを利用できることであり、パイプラインの動作を拡張するためにプラグインを追加するのが簡単なことです。このリリースで、プラグインの開発、管理、公開がより簡単になります。また、Logstashの速度をより良くしたため、より多くのデータを短時間に処理することができます。興味ありませんか？では、詳細を見ていきましょう。

plugin ecosystemの変更

Logstashは165ものプラグイン(inputs、filters、outputs、codecs)を持っており、これらはElasticsearchとコミュニティからのコントリビュートで開発されています。多くのプラグインを管理することは、使いやすさと素早さの間のトレードオフがあります。 Logstashの全てのプラグインをまとめることは使いやすさがある一方、プラグインの更新を取り込むために Logstashの新しいリリースを待ってもらうことになります。 Logstashからプラグインを分離して個別に配布する場合、更新は簡単になりますが、使いやすさ（特に新しいユーザに）に影響が出ます。

私たちは、プロジェクトを前進させるために、これらのバランスをとることを考えました。これまで、全ての利用可能なプラグインは’core’と’contrib’の2つに分割していました。 ‘core’にあるよく使われるプラグインは、Logstashに含めていました。コミュニティによりコントリビュートされたプラグインは’contrib’パッケージとして分離して配布していました。 1.5.0のリリースで、ユーザに対してより良いプラグイン管理をできるように変更しました。全てのプラグインは、それ自身によるパッケージに移行しました。パッケージングフレームワークとしてrubygemsを使い、rubygem.org経由でこれらのプラグインを配布、公開します。また、Logstashにプラグインのインストール、更新、削除を簡単にするための構造も追加しました。

例えば、S3 output pluginをインストールするには、以下のコマンドを実行します。

$LS_HOME/bin/plugin install logstash-output-s3

それだけです！Logstashがgemと依存するgemをrubygems.orgからダウンロードし、インストールします。あなたは、S3にデータを送ることができるようになります。

ダウンロード可能なLogstashリリースはプラグインをまだ多く含んでいますが、いつでも、個別にプラグインをアップグレードし、インストールすることができます。プラグインエコシステムの変更に関する詳細のブログ記事をお待ち下さい。

パフォーマンス改善

Logstash 1.5.0はより高速になっています。パフォーマンスが改善された2カ所について説明します。

grok filter

Grok filterはLogstashで、構造化データを抽出するためにパターンを記述するのに使われます。本リリースで、人気のある幾つかのパターンのgrok filterのスループットを100%に改善しました。言い換えると、grok filterを使うときに、Logstashを通してより多くのデータを処理することができます。

私たちのベンチマークテストで、1.5.0と1.4.2のスループットの比較をしました。利用したデータは690万件のApache Webアクセスlogで、COMBINEDAPACHELOGのgrok patternです。 1.5.0で、スループットは34,000 event per sec(eps)から50,000 epsに増加しました。両方のテストを8コアのマシンでLogstashで8つのワーカーを実行しました。これらのテストで、一つのgrok filterを実行し、 stdinとstdoutを使ったパイプラインでイベントのスループットを計測しました。全体的なパフォーマンスは、様々なハードウェアやLogstashのコンフィグによって変化することに注意してください。

json serialization / deserialization

JSONのシリアライズ/でシリアライズをJrJacksonライブラリを利用して実装しました。これにより、100%以上のスループットの改善がありました。先ほど説明したパフォーマンステストにおいて、1.3KBのサイズの500,00 JSONイベントを送信し、 16,000 epsから30,000 epsにスループットが改善しました。 45,000サイズのイベントで、850 epsから3500 epsにスループットが増加しました。すばらしいです。

apache kafka integration

いまでは、Apache Kafkaが大規模スケールデータ処理システムでよく利用されます。 Logstashの配備のスケーリングにおいて、Kafkaもまた、shippingインスタンスとindexingインスタンス間のデータを保存するための中間メッセージバッファとして使うことができます。

1.5.0で、Logstash Kafkaのinputとoutputのプラグインのビルトインサポートを追加しました。これは、Joseph Lawsonによって最初に開発されました。私たちは、これらのプラグインにインテグレーションテストとドキュメントを追加することにより改良し、新しいKafkaの機能を開発し続けます。また、Apache Avro codecを追加することで、Kafkaに保存されたイベントを簡単に取得でき、ELKスタックを使ってそれらを解析できるようにしました。

Kafka inputを追加するのは次のコマンドです。

$LS_HOME/bin/plugin install logstash-input-kafka

Kafka outputは次のコマンドです。

$LS_HOME/bin/plugin install logstash-output-kafka

セキュリティに関する改善

認証と経路暗号化のサポートを追加し、Elasticsearchのoutput、input、filterのセキュリティを改良しました。例えば、HTTPプロトコルでSSL/TLSにより暗号化を有効にでき、 HTTPベーシック認証をユーザ名とパスワードをリクエストに与えることで設定できます。これらの機能は、時期にリリースされるElasticsearch ShieldセキュリティプロダクトとLogstashを統合できます。

ドキュメント

これまで、Logstashのドキュメントは[logstash.net])(http://logstash.net/)に置いてあり、他のELKスタックと一緒に動かす時に、情報を探すのが厄介でした。 1.5.0および、今後のバージョンのドキュメントはelasticsearch.orgのLogstash Guideに移行します。この移行でelasticsearch.org/guideにELKスタックを利用、学習するためにドキュメントが1つになりました。このベータリリースのイテレーションで、私たちはプレゼンテーションとドキュメントの品質を改善することに活発に取り組んでいきます。 (過去のLogstashのドキュメントの全てはいままでのlogstash.netで引き続き公開していく予定です。)

バグフィックスと改善

ここまでの新しい機能に加えて、Logstash 1.5.0では、多くのバグフィックスと多くの機能改善があります。ここで、これらのいくつかを紹介します。

出力しない’metadata’をイベントに格納可能に。これは、例えば、date filterに使う中間フィールドのために必要。(#1834, #LOGSTASH-1798)
HTTPを利用しているときのファイルデスクリプタリークの修正。Logstashがストールするのを防ぎ、OOMエラーからクラッシュするケースも防ぎます。(#1604)
Twitter input:full_tweetオプションの追加、Twitter rate limitingエラーのハンドリング(#1471)
イベントを生成するfilter(multiline、clone、split、metrics)により、後続の条件文にこれらのイベントを正しく伝搬(#1431)
Elasticsearch output:Logstashはデフォルトでmessage.rawフィールドを作成しない。messageフィールドはElasticsearch によりnot_analyzedでマルチフィールドとして追加される。マルチフィールドはディスクスペースが2倍必要だが、利点がない。
bin/logstashの複数のサブコマンドを除去(#1797)

これらの機能、改善、バグフィックスについては、Logstash 1.5.0.Beta1 のchangelogをごらんください。

試してみてください！

ぜひ、Logstash 1.5.0 Beta 1をダウンロードして試してみてください。そして、感想をTwitter(@elasticsearch)などで教えて下さい。また、問題がありましたら、GitHub issues pageで報告をお願いします。

インデックステンプレートとLogstash

Tue, 25 Nov 2014 16:25:46 +0900

前回の「Logstashを利用したApacheアクセスログのインポート」の続きです。前回の記事では、Logstashの設定ファイルについて説明しました。今回は「Elasticsearchに設定するインデックステンプレート」について説明します。

テンプレートの設定

Elasticsearchでは、登録するデータの特性に合わせてMappingを定義する方がデータを効率良く扱うことができる場合があります。この場合、通常ですと、インデックス作成時にMappingを指定します。

ただ、今回は、インデックス名に「年」を含める形で指定してあります。「年」はLogstashで処理したデータによって決まります。このため、あらかじめMappingを指定してインデックスを作成するのは難しいです。

このような場合に便利な機能として、「インデックステンプレート」があります。

インデックステンプレートとは

実際のテンプレートの説明に入る前に、少しだけ説明を。インデックステンプレートとは、インデックスが作成されるタイミングで自動的に適用される設定をテンプレートとして登録できる機能のことです。実際にテンプレートが適用されるかどうかは、インデックス名で判断されます。

例えば、大して重要でもなく、データ量も少ないインデックス用のテンプレートとして、シャード数が1、レプリカ数が0、"_source"を保存しない設定のテンプレートを登録する場合、次のようになります。

curl -XPUT localhost:9200/_template/template_1 -d '
{
  "template" : "te*",
  "settings" : {
    "number_of_shards" : 1,
    "number_of_replicas" : 0
  },
  "mappings" : {
    "type1" : {
      "_source" : { "enabled" : false }
    }
  }
}
'

_templateがインデックステンプレートを登録するためのエンドポイントです。 template_1がこのテンプレートのIDです。削除などについては、このIDを利用します。

そして、重要なのは、"template“の設定です。 “template“には、このテンプレートが適用されるべきインデックス名を記載します。上記サンプルではte*となっているため、teで始まる名前のインデックスを作成した場合にテンプレートにある設定が適用されます。

今回利用するテンプレート

私がJJUG CCCや第7回Elasticsearch勉強会のKibana4のデモで利用したインデックスのテンプレートは次のものになります。 “template“には、前回の記事で紹介したoutput/elasticsearchの設定に合致するnew_demo_access_log-*を指定しています。

curl -XPUT localhost:9200/_template/new_access_log_for_demo -d '
{
  "template": "new_demo_access_log-*",
  "settings": {
    "number_of_shards": "2",
    "number_of_replicas": "0"
  },
  "mappings": {
    "_default_": {
      "dynamic_templates": [
        {
          "string_template": {
            "mapping": {
              "index": "not_analyzed",
              "type": "string"
            },
            "match_mapping_type": "string",
            "match": "*"
          }
        }
      ],
      "properties": {
        "path": {
          "type": "multi_field",
          "fields": {
            "no_analyzed": {
              "index": "not_analyzed",
              "type": "string"
            },
            "analyzed": {
              "index": "analyzed",
              "type": "string"
            }
          }
        },
        "referer": {
          "type": "multi_field",
          "fields": {
            "no_analyzed": {
              "index": "not_analyzed",
              "type": "string"
            },
            "analyzed": {
              "index": "analyzed",
              "type": "string"
            }
          }
        },
        "agent": {
          "type": "multi_field",
          "fields": {
            "no_analyzed": {
              "index": "not_analyzed",
              "type": "string"
            },
            "analyzed": {
              "index": "analyzed",
              "type": "string"
            }
          }
        },
        "geoip": {
          "type": "object",
          "properties": {
            "location": {
              "geohash": true,
              "geohash_precision": 10,
              "type": "geo_point",
              "lat_lon": true,
              "geohash_prefix": true
            }
          }
        },
        "response": {
          "copy_to": "response_int",
          "type": "string"
        },
        "bytes": {
          "type": "long"
        },
        "response_int": {
          "type": "integer"
        }
      }
    }
  }
}
'

settings設定

デモ用であり、手元で2台のノードを起動するということもあり、number_of_shardsに2を、number_of_replicasに0を指定してあります。

mappings設定

インデックスのタイプ

Mappingsの指定は通常、特定のタイプを指定します。今回のデモでは、1種類しかないのですが、タイプ名を特に意識しないために、_default_を使用しました。この場合、任意のタイプに適用されることとなります。タイプを指定してMappingの設定を行う場合は_default_の部分に特定のタイプ名を記入します。

"mappings": {
  "_default_": {
    ...

ダイナミックテンプレート

次はダイナミックテンプレートです。インデックステンプレートはインデックスの設定をテンプレート化しました。ダイナミックテンプレートはフィールドに対してテンプレートを設定できます。

以下のダイナミックテンプレートでは、stringタイプのフィールドのデフォルト設定を変更しています。通常、stringタイプのフィールドはanalyzedとなりますが、not_analyzedに変更してあります。詳しく検索したいフィールドの方が少ないためです。

...
"dynamic_templates": [
  {
    "string_template": {
      "mapping": {
        "index": "not_analyzed",
        "type": "string"
      },
      "match_mapping_type": "string",
      "match": "*"
    }
  }
],
...

multi_field指定

検索もしたいし、Terms Aggregationでも利用したいフィールドについては、multi_fieldを利用して、 analyzedとnot_analyzedの2種類のフィールドを用意しています。 multi_field設定を用いることで、1つのJSONのデータから、異なる形のフィールドを用意することが可能です。

今回のテンプレートでは、path、referer、agentにmulti_fieldを指定しました。

...
"path": {
  "type": "multi_field",
  "fields": {
    "no_analyzed": {
      "index": "not_analyzed",
      "type": "string"
    },
    "analyzed": {
      "index": "analyzed",
      "type": "string"
    }
  }
},
...

例えば、上記の設定の場合、入力のJSONはpathというデータのみですが、インデックス上にはpath.no_analyzedと path.analyzedというフィールドができあがります。実際に検索する場合は、path.analyzed:検索したい文字列という形で検索をすることで、いわゆる部分一致のような検索が可能です。また、完全一致をしたい場合はpath.no_analyzed:検索したい文字列という指定になります。用途を考えると、requestも指定したほうが良いかもしれません。

geoip

Logstashでgeoipデータを付与していました。このgeoipのデータをKibana4で利用するために、geoデータとして登録する必要があります。

"geoip": {
  "type": "object",
  "properties": {
    "location": {
      "geohash": true,
      "geohash_precision": 10,
      "type": "geo_point",
      "lat_lon": true,
      "geohash_prefix": true
    }
  }
},

上記の設定がgeoデータの指定です。 typeにobjectが指定してありますが、これは、geoipのデータがネストしているためです。 geoipオブジェクトのうち、緯度経度のデータはlocationに入っているため、こちらに緯度経度関係の設定を指定します。

"type": "geo_point"：geo_pointタイプであることを指定
"geohash": true：緯度経度のデータをもとに、geohashの値もインデックス
"geohash_precision": 10：geohashの精度の指定
"lat_lon": true：緯度経度を個別の.lat、.lonというフィールドにもインデックス
"geohash_prefix": true：該当するgeohashのみでなく、その親にあたるgeohashについてもインデックスする

response、response_int、bytes

最後は、response、response_int、bytesです。

responseには、HTTPステータスコードが入ります。文字列としても扱いたいですが、integerとして、Renge Aggregationなどを行いたいので、 response_intというフィールドにも値を入れています。 multi_fieldでも可能ですが、ここでは、copy_toを利用しました。 copy_toを用いることで、異なるフィールドに値をコピーすることができます。

bytesについては、longで扱いたいとういう理由だけです。


"response": {
  "copy_to": "response_int",
  "type": "string"
},
"bytes": {
  "type": "long"
},
"response_int": {
  "type": "integer"
}

まとめ

今回はデモに利用したインデックスてプレートについて説明しました。前回の、Logstashの設定とこのインデックステンプレートを用いることで、Kibanaで解析するデータの準備ができます。実際の操作などについては、また次回の記事で説明しようかと思います。

不明な点、誤植などありましたら、コメント欄へお願いします。

Logstashを利用したApacheアクセスログのインポート

Fri, 21 Nov 2014 17:30:39 +0900

JJUG CCCや第7回Elasticsearch勉強会のKibana4のデモにアクセスログを利用しました。

ただ、セッションでは、どうやってElasticsearchに投入したのかという詳しい話をしていませんでした。本記事では、データ取り込み時に利用したLogstashの設定ファイルについて説明します。

Logstashの設定の説明に入る前に、全体の流れを。「ApacheアクセスログをKibana4により可視化」です。

材料の準備

「ApacheアクセスログをKibana4により可視化」に必要な材料は次の通りです。（今回は起動するところまでいかないので、実際に必要なのは次回以降になります。）

Java 7（u55以上を1つ）
Logstash 1.4.2（1つ）
Elasticsearch 1.4.0（1つ）
Kibana4 Beta2（1つ）
Apacheのアクセスログ（適量）

Apacheのアクセスログ以外は、公式サイトからダウンロードできます。それぞれをダウンロードして、起動できるようにしておきましょう。

※1台のマシン上で行う場合は、アクセスログの量を少なめにするなどの対策をとりましょう。 ※今回は、1台のマシン（Mac）上で、VMなどを利用せず、それぞれ直接起動するものとします。

可視化の手順と流れ

可視化の流れとしては、

Logstashでファイルを読み込み、各種処理（パースしたり、情報を追加したり、切り出したり）
Elasticsearchに保存
Kibanaでグラフを作ったり、検索してみたり

です。

今回は、1のLogstashでファイルを読み込んだりする設定ファイルの説明です。

Logstashの設定

Logstashの基本

まずは、Logstashの設定ですが、簡単にLogstashの説明を。 Logstashは大きく3つのパーツに分かれています。

input：データの入力処理
filter：inputで読み込んだデータに対する操作など
output：データの出力処理

inputでデータを読み込み（複数可）、filterでデータに対して各種処理を行い、outputでデータを指定されたところに出力（複数可）します。

アクセスログの読み込み設定

アクセスログの読み込み処理は大まかに次のようなものとなります。

アクセスログを読み込む（input/file）
読み取ったアクセスログを各フィールド（IPアドレス、ユーザエージェントなど）に分割（filter/grok）
日付のパース（filter/date）
クライアントIPアドレスにgeoipの情報を付加（filter/geoip）
リクエストのパスの第1階層の抽出（filter/grok）
ユーザエージェントのパース（filter/useragent）
Elasticsearchへの出力（output/elasticsearch）

設定ファイルは次のようなものになります。

input {
  file {
    path => "/Users/johtani/demo_access_log/*/*.log"
    start_position => "beginning"
  }
}

filter {
  grok {
    match => { "message" => "%{COMBINEDAPACHELOG}" }
    break_on_match => false
    tag_on_failure => ["_message_parse_failure"]
  }
  date {
    match => ["timestamp", "dd/MMM/YYYY:HH:mm:ss Z"]
    locale => en
  }
  geoip {
    source => ["clientip"]
  }
  grok {
    match => { "request" => "^/%{WORD:first_path}/%{GREEDYDATA}$" }
    tag_on_failure => ["_request_parse_failure"]
  }
  useragent {
    source => "agent"
    target => "useragent"
  }
}

output {
  elasticsearch {
    host => "localhost"
    index => "new_demo_access_log-%{year}"
    cluster => "demo_cluster"
    protocol => "http"
  }
}

1. アクセスログを読み込む（input/file）

inputのfileモジュール(a)を使用してアクセスログのファイルを読み込みます。 pathでアクセスログのファイルのパスを指定します。今回利用したアクセスログはdemo_access_log/2010/access20100201.logといった日毎のファイルに分割されていたため、 *を利用してファイルのパスを指定しました。また、今回は既存のファイルの読み込みだけのため、start_positionにbeginningを指定してあります。デフォルトではendが指定されるため、Logstashを起動後に追記されたログから対象になってしまうためです。その他の設定については、公式ガイドをご覧ください。

input {
  file { # a
    path => "/Users/johtani/demo_access_log/*/*.log" # b
    start_position => "beginning" # c
  }
}

Logstashでは、ファイルをどこまで読み込んだかという情報を保持するために、sincedbを利用しています。設定変更後に同じファイルを最初から読み込みたい場合などは、こちらのファイルを一旦削除するなどの対応が必要です。

ちなみに、読み込んだデータは次のようなJSONになっています。

{
  "message": "読み込んだアクセスログ",
  "@version": "1",
  "@timestamp":"2014-11-21T06:16:21.644Z",
  "host":"jupiter.local",
  "path":"/Users/johtani/demo_access_log/2010/access20100201.log"}
}

特に指定がない場合は、messageに読み込んだデータが入ってきます。 @timestampがLogstashが読み込んだ時刻、hostはLogstashが動作しているホスト名です。 pathはfileモジュールが読み込んだファイルのパスを設定しています。この後の処理で、どこの項目に対して処理を行うかといったことが重要になるので、

2. 読み取ったアクセスログを各フィールド（IPアドレス、ユーザエージェントなど）に分割（filter/grok）

2.〜6.の処理は、inputで読み込んだ1アクセスログに対する処理となります。

ここでは、grokフィルタを使用して Apacheのアクセスログを各フィールドに分割します。 Logastashでは、簡単に使えるようにいくつかのパターンが用意されています。 Apacheのログのために、COMBINEDAPACHELOGというのが用意されています。今回はこちらを使用しています。その他にも日付などパターンが用意されているので、試してみてください。

messageにアクセスログが入っているので、こちらの項目に対してCOMBINEDAPACHELOGのパターンを matchで適用してフィールドに抜き出します。 tag_on_failureは、matchでパースに失敗した場合に、tagというフィールドに指定した文字列を出力する機能になります。デフォルトだと_grokparsefailureが付与されますが、ここでは、どの処理で失敗したがを判別するために文字列を変更しています。

filter {
  grok {
    match => { "message" => "%{COMBINEDAPACHELOG}" }
    break_on_match => false
    tag_on_failure => ["_message_parse_failure"]
  }
  ...

clientip、ident、auth、timestamp、verb、request、httpversion、response、bytes、referrer、agentがgrokフィルタにより抜き出された項目です。

{
  "message":"アクセスログ",
  "@version":"1",
  "@timestamp":"2014-11-21T07:20:54.387Z",
  "host":"jupiter.local",
  "path":"/Users/johtani/demo_access_log/2010/access20100201.log",
  "clientip":"クライアントのIPアドレス",
  "ident":"-",
  "auth":"-",
  "timestamp":"01/Feb/2010:00:00:26 +0900",
  "verb":"GET",
  "request":"/images/favicon.ico",
  "httpversion":"1.1",
  "response":"200",
  "bytes":"318",
  "referrer":"\"-\"",
  "agent":"\"Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)\""
}

3. 日付のパース（filter/date）

Logstashは特に指定がない場合、inputでデータを取り出した日付が@timestampとなります。そして、このフィールドが特に指定がない場合は、Elasticsearchのデータの日付となり、Kibanaで利用する日付となります。

リアルタイムにアクセスログを読み込む場合は、読み込んだ日時でもほぼ問題はありませんが、過去データの場合はそうもいきません。そこで、dateフィルタを使用して、@timestampの値を書き換えます。

date {
  match => ["timestamp", "dd/MMM/YYYY:HH:mm:ss Z"]
  locale => en
}

上記では、timestampという項目に対してdd/MMM/YYYY:HH:mm:ss Zという日付パターンの場合に値を書き換える設定となります。なお、日付の月の部分がFebとなっているため、localeにenを指定しています。Logstashが動作するマシンのlocaleがjaなどの場合にパースに失敗するためです。

4. クライアントIPアドレスにgeoipの情報を付加（filter/geoip）

どの国からのアクセスかなどを判別したいので、IPアドレスを元にgeoipを利用してより詳細な情報を付与します。 Logstashでもこの機能が用意されており、簡単に利用ができます。

geoip {
  source => ["clientip"]
}

これだけです。対象とするIPアドレスのフィールドを指定しているだけです。 geoipというフィールドが追加され、次のような情報が付与されます。国名、緯度経度、タイムゾーンなどです。

{
  ...  
  "geoip": {
    "ip": "IPアドレス",
    "country_code2": "JP",
    "country_code3": "JPN",
    "country_name": "Japan",
    "continent_code": "AS",
    "latitude": 36,
    "longitude": 138,
    "timezone": "Asia/Tokyo",
    "location": [
      138,
      36
    ]
  }
  ...
}

5. リクエストのパスの第1階層の抽出（filter/grok）

リクエストされたURLはrequestフィールドにありますが、個別のURLだと、大まかな集計が大変です。もちろん、クエリで処理することもできますが、Logstashで処理するついでに、第1階層のディレクトリ名を抽出しておくことで、検索や集計を行いやすくしておきます。

grok {
  match => { "request" => "^/%{WORD:first_path}/%{GREEDYDATA}$" }
  tag_on_failure => ["_request_parse_failure"]
}

また、grokフィルタの登場です。今回は、WORD:first_pathという記述方法で、WORDパターンにマッチした文字列をfirst_pathというフィールドに展開する指定をしています。

例えば、サイトのスクリプトなどがscriptsというディレクトリにある場合は、first_pathの値を利用して、後続のフィルタでログデータを出力しないといった処理にも使えます。

6. ユーザエージェントのパース（filter/useragent）

Logstashではユーザエージェントの文字列から、いくつかの情報を付与するフィルタも用意されています。 useragentフィルタです。

useragent {
  source => "agent"
  target => "useragent"
}

agentというフィールドにユーザエージェントの文字列があるので、このフィールドに対してフィルタを適用します。元の文字列も取っておきたいので、useragentという別のフィールドに出力するように指定してあります。

"useragent": {
  "name": "Firefox",
  "os": "Windows XP",
  "os_name": "Windows XP",
  "device": "Other",
  "major": "17",
  "minor": "0"
},

このように、OS名やバージョン名などが抽出できます。

7. Elasticsearchへの出力（output/elasticsearch）

最後は、Elasticsearchへのデータの出力設定です。

indexにて、出力するindex名を指定してあります。また、年毎のインデックス名にするために%{year}を利用しています。 sprintf formatです。

elasticsearch {
  host => "localhost"
  index => "new_demo_access_log-%{year}"
  cluster => "demo_cluster"
  protocol => "http"
}

まとめ

ということで、今回はアクセスログをLogstashにて読み込む時の設定について説明してきました。次回は、実際にLogstashを起動してElasticsearchにデータを登録するところまでを説明します。

JJUG CCCや勉強会のデモに用いたデータは、 Elasticsearchにデータを登録する前にテンプレートも設定してありました。こちらについても、次回説明しようと思います。

不明な点、誤植などありましたら、コメント欄へお願いします。