Beats環境におけるElastic Common Schema（ECS）への移行について、その移行例とともに詳細に説明します。

migrating-ecs-fullbleed.jpg

migrating-ecs-thumbnail.jpg

Migrating to Elastic Common Schema in Beats environments

Beats環境におけるElastic Common Schema（ECS）への移行

<p>ECS（Elastic Common Schema）はElasticsearchのデータを一貫した方法で構造化し、カスタマイズにも対応する新しい仕様基準です。ECSの導入で、多様なソースのデータを分析することが可能になります。ECSを使用して、ダッシュボードや機械学習ジョブといった分析コンテンツをより広範に適用したり、検索をより厳密に設定することができ、フィールド名も覚えやすくなります。
</p>
<h2>Common Schemaを使う理由</h2>
<p>インタラクティブな分析（例：検索、ドリルダウン、ピボット、可視化）を行う場合にも、自動化された分析（例：アラート、機械学習による異常検知）を行う場合にも、データは統一された方法で分析する必要があります。しかし同じソースから来るデータでない限り、フォーマットはバラバラになります。具体的には、次のような不統一です。
</p>
<ul>
	<li>異なるデータタイプ（例：ログ、メトリック、APM、フロー、コンテクスチュアルデータ）</li>
	<li>さまざまなベンダーを使う混成環境</li>
	<li>類似しているが異なるデータソース（例：<a href="/jp/beats/auditbeat">Auditbeat</a>、Cylance、Taniumといった複数のエンドポイントデータソース）</li>
</ul>
<p>たとえば「複数のソースから取得されたデータで、特定のユーザーを検索する」という状況を考えてみましょう。たった1つのフィールドを検索するにも、<code>user</code>、<code>username</code>、<code>nginx.access.user_name</code>、<code>login</code>といった複数のフィールド名を考慮する必要が生じます。このデータについてドリルダウンやピボットを実行するとなれば、さらに処理は複雑になります。さらに可視化やアラート、機械学習ジョブといった分析コンテンツを開発するとしたらどうでしょうか？新しいデータソースを取り込むたびに複雑になり、重複も生じてしまいます。
</p>
<h3>Elastic Common Schemaとは？</h3>
<p>ECSはElasticsearchに投入されるデータ用に、一般的なドキュメントフィールドを定義するオープンソースの仕様基準です。ECSはデータモデリングの統一化をサポートし、双方向性と自動化の2つの手法で多様なソースから一元的にデータを分析できるように設計されています。
</p>
<p>ECSの特長として、分類に特化した予測性と、カスタムユースケースに対応する包括的な仕様による汎用性の両方を兼ね備えていることがあります。ECSの分類基準は、フィールドのデータ要素を次の3つのレベルに配置します。
</p>
<table>
<tbody>
<tr>
	<td style="background-color: rgb(223, 223, 223);"><strong>レベル</strong>
	</td>
	<td style="background-color: rgb(223, 223, 223);"><strong>説明</strong>
	</td>
	<td style="background-color: rgb(223, 223, 223);"><strong>おすすめの使い方</strong>
	</td>
</tr>
<tr>
	<td><strong>ECS Core Field</strong>
	</td>
	<td>定義された一連のECSのトップレベルオブジェクトの下にある、完全定義された一連のフィールド名
	</td>
	<td>多くのユースケースに共通するフィールドであり、ここから作業を開始します
	</td>
</tr>
<tr>
	<td><strong>ECS Extended Field</strong>
	</td>
	<td>同じ一連のECSのトップレベルオブジェクトの下にある、部分定義された一連のフィールド名
	</td>
	<td>Extended Fieldはより限定的なユースケースに適用したり、ユースケースに応じて自由に解釈して使用することができます
	</td>
</tr>
<tr>
	<td><strong>Custom Field</strong>
	</td>
	<td>ECSのフィールドやオブジェクトと競合せず、ユーザーが供給する一連の非ECSのトップレベルオブジェクトの下にある、一連の定義されない、かつ無名のフィールド
	</td>
	<td>ECSに一致するフィールドがない場合に追加するフィールドです。データをECSに移行する際などに、元のイベントフィールドのコピーを保持することもできます。
	</td>
</tr>
</tbody>
</table>
<h2>Elastic Common Schemaを活用する</h2>
<h3>活用事例1：パース</h3>
<p>次のApacheログでECSを使用してみます。
</p>
<pre class="prettyprint">10.42.42.42 - - [07/Dec/2018:11:05:07 +0100] "GET /blog HTTP/1.1" 200 2571 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36"
</pre>
<p>このメッセージをECSにマッピングすると、ログのフィールドは次のように整理されます。
</p>
<table>
<tbody>
<tr>
	<td width="25%" style="background-color: rgb(223, 223, 223);"><strong>フィールド名</strong>
	</td>
	<td width="38%" style="background-color: rgb(223, 223, 223);"><strong>値</strong>
	</td>
	<td width="37%" style="background-color: rgb(223, 223, 223);"><strong>メモ</strong>
	</td>
</tr>
<tr>
	<td>@timestamp
	</td>
	<td><code>2018-12-07T11:05:07.000Z</code>
	</td>
	<td>
	</td>
</tr>
<tr>
	<td>ecs.version
	</td>
	<td><code>1.0.0</code>
	</td>
	<td>
	</td>
</tr>
<tr>
	<td>event.dataset
	</td>
	<td><code>apache.access</code>
	</td>
	<td>
	</td>
</tr>
<tr>
	<td>event.original
	</td>
	<td><code>10.42.42.42 - - [07/Dec ...</code>
	</td>
	<td>監査目的の完全で、無修正のログ&nbsp;
	</td>
</tr>
<tr>
	<td>http.request.method
	</td>
	<td><code>get</code>
	</td>
	<td>
	</td>
</tr>
<tr>
	<td>http.response.body.bytes
	</td>
	<td><code>2571</code>
	</td>
	<td>
	</td>
</tr>
<tr>
	<td>http.response.status_code
	</td>
	<td><code>200</code>
	</td>
	<td>
	</td>
</tr>
<tr>
	<td>http.version
	</td>
	<td><code>1.1</code>
	</td>
	<td>
	</td>
</tr>
<tr>
	<td>host.hostname
	</td>
	<td><code>webserver-blog-prod</code>
	</td>
	<td>
	</td>
</tr>
<tr>
	<td>message
	</td>
	<td><code>"GET /blog HTTP/1.1" 200 2571</code>
	</td>
	<td>ログビューアーに簡潔に表示させる、イベント重要情報のテキスト表現
	</td>
</tr>
<tr>
	<td>service.name
	</td>
	<td><code>Company blog</code>
	</td>
	<td>ユーザーがこのサービスにつけるカスタム名
	</td>
</tr>
<tr>
	<td>service.type
	</td>
	<td><code>apache</code>
	</td>
	<td>
	</td>
</tr>
<tr>
	<td>source.geo.*
	</td>
	<td>
	</td>
	<td>緯度経度情報のためのフィールド
	</td>
</tr>
<tr>
	<td>source.ip
	</td>
	<td><code>10.42.42.42</code>
	</td>
	<td>
	</td>
</tr>
<tr>
	<td>url.original
	</td>
	<td><code>/blog</code>
	</td>
	<td>
	</td>
</tr>
<tr>
	<td>user.name
	</td>
	<td><code>-</code>
	</td>
	<td>
	</td>
</tr>
<tr>
	<td>user_agent.*
	</td>
	<td>
	</td>
	<td>ユーザーエージェントを記述するフィールド
	</td>
</tr>
</tbody>
</table>
<p>上に示されているように、生のログはECSの<code>event.original</code>フィールドに保存されて、監査ユースケースをサポートしています。説明をシンプルにするため、この事例では監視エージェント（ <code>agent.*</code>の下にあります）に関する詳細と、ホスト（<code>host.*</code>の下にあります）、その他いくつかのフィールドの情報の一部を省略しています。より完全な再現については、こちらの<a href="https://gist.github.com/webmat/fc4902a61abf1cacbd5b717f1a3a6935">JSONイベント事例</a>をご覧ください。
</p>
<h3>活用事例2：検索</h3>
<p>特定のIPのアクティビティを、ある完全なWebスタック全体で調査してみます。このWebスタックの構成は、Palo Alto Networks Firewall、HAProxy（Logstashで処理）、Apache（Beatsモジュールを使用）、Elastic APM、さらにSuricata IDS（カスタム、独自のEVE JSONフォーマットを使用）です。
</p>
<p>ECSを使用する前にこのIPを検索すると、次のように表示されるかもしれません。
</p>
<pre class="prettyprint">src:10.42.42.42 OR client_ip:10.42.42.42 OR apache2.access.remote_ip:10.42.42.42 OR context.user.ip:10.42.42.42 OR src_ip:10.42.42.42
</pre>
<p>すべてのソースをECSにマッピングした後のクエリは、ずっとシンプルになります。
</p>
<pre class="prettyprint">source.ip:10.42.42.42
</pre>
<h3>活用事例3：可視化</h3>
<p>ECSの実力は、複数の異なるデータソースからデータを統一された方法で正規化する場面で特に発揮されます。Webスタックの脅威を監視するとき、たいていの場合はネットワークデータの複数のソースを使用します。ここでは境界上のPalo Alto Next-Gen FirewallとSuricata IDSのイベントとアラートを使用しています。Kibanaで一元的に可視化でき、ベンダーを問わずドリルダウンとピボットを実行できるようなやり方で<code>source.ip</code>と<code>network.direction</code>フィールドから各メッセージを抽出するには、どうすればよいでしょうか？もちろん答えはECSです。ECSを使わない場合に比べて、一元化された監視を大幅に簡単に実現できます。
</p>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt71256f06dc672546/5c98d595975fd58f4d12646d/ecs-intro-dashboard-1360.jpg" data-sys-asset-uid="blt71256f06dc672546" alt="Elastic Common Schemaを使ったKibanaでのIPアドレス検索" "="">
</p><figcaption>IP 10.42.42.42を検索している</figcaption>
<h2>Elastic Common Schemaのメリット</h2>
<p>ECSの導入により、検索、ドリルダウン、ピボット、データ可視化、機械学習ベースの異常検知、アラートを含む、Elastic Stackの分析全体の様式を統一することができます。完全に組み込めば、非構造化と構造化の両方のクエリパラメーター能力を活用して検索することが可能になります。またECSは、1つのベンダーを異なるデバイスで使用している、あるいはデータソースの種類が全く異なるといった条件にかかわらず、異なるデータソースのデータを自動的に関連付ける機能をスムーズに実現します。
</p>
<p>さらにECSは、分析コンテンツの開発時間も短縮します。組織に新しいデータソースが加わるたびに検索やダッシュボードを新規に作成する必要がなくなり、既存の検索やダッシュボードを使用し続けることができます。ECSを使えば、Elasticやパートナー、オープンソースプロジェクトなど、ECSを使用する他のパーティーから環境に直接分析コンテンツを導入することも簡単になります。
</p>
<p>インタラクティブな分析も手軽になります。ECSでは、データソースごとに異なる設定ではなく、1つの設定だけを使用するため、一般的に使用されるフィールド名を覚えておくことも簡単です。ECSでは（いくつかの例外はありますが）、シンプルで標準的な名付け方法に従った仕様基準なので、フィールド名を忘れる可能性も減少します。
</p>
<p>ECSを導入したくない場合は？問題ありません。必要なときはいつでも使うことができ、必要なければ使わなくても大丈夫です！
</p>
<h2>Elastic Common Schemaを使いはじめる</h2>
<p>ECSは<a href="https://github.com/elastic/ecs">GitHub repo</a>に公開されており、レビュー可能です。現在はBeta2で、まもなく一般公開への移行を予定しています。Apache 2.0オープンソースライセンス下で公開されており、Elasticの広範なコミュニティで幅広く導入できるようになっています。
</p>
<p><strong></strong>
</p>
<p>魔法みたいな機能なの？あらゆるスキーマと同様、ECSの実装も手軽ではありません。もしすでにElasticsearchのインデックステンプレートを設定して、LogstashやElasticsearchのIngestノードでいくつかの機能変換を記述したことがあれば、こちらの作業もイメージできるかもしれません。Elastic Beatsモジュールの今後のバージョンはデフォルトでECSフォーマットのイベントを提供するようになる予定です。これにより、移行もスムーズになります。第一弾として、こちらの新しい<a href="/jp/blog/introducing-auditbeat-system-module">Auditbeat向けのシステムモジュール</a>は新仕様となっています。
</p>
<p>ECSについては、<a href="/jp/webinars/introducing-the-elastic-common-schema">Elastic Common Schema（ECS）ウェビナー</a>でも詳しくご紹介しています。ぜひご覧ください。今後のブログ記事では、データをECS（スキーマに定義されていないフィールドを含む）にマッピングする方法や、ECSの統合戦略についてお伝えする予定です。
</p>
<h2>さらに詳しく</h2>
<ul>
	<li><a href="/jp/blog/migrating-to-elastic-common-schema-in-beats-environments">Beats環境におけるElastic Common Schema（ECS）への移行</a></li>
</ul>

Articles by Mathieu Martin

Beats環境におけるElastic Common Schema（ECS）への移行

Elastic Common Schemaについて

プロダクト

Elasticについて

情報