2019年7月10日

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

著者

2019年2月に、ブログ記事とウェビナーでElastic Common Schema（ECS）をご紹介しました。それらを簡単にまとめると、ECSは、フィールドおよびデータ型の共通セットを定義することで、異なる種類のデータソースに対する統一された検索、ビジュアライゼーション、分析を実現するもの、となります。これは、多様なベンダー標準で構成される異種混合環境、つまり類似しているが異なるデータソースを同時に使用する環境において、大きな利点となります。

また、ECSの実装が簡単な作業ではないことについても説明しました。実際、ECS準拠のイベントを生成するためには、データの投入時に、イベントソースから収集される多くのフィールドをコピー、またはそれらの名前の変更を行う必要があります。

そして、前回の説明の最後に述べたのは、すでにElasticsearchのインデックステンプレートを構成し、LogstashやElasticsearchの投入パイプラインでいくつかの変換関数を記述したことがあれば、こちらの作業もイメージできるかもしれないということでした。環境をECSに移行するために必要な作業量は、Elastic Stackのデータ投入パイプラインをどのように設計したかによって変わってきます。移行の一要素としてBeatsおよびBeatsモジュールを使用すれば、ECSへの合理化された移行が可能になります。Beats 7のイベントはすでにECS形式であるため、残りの唯一の作業は、既存の分析コンテンツと新しいECSデータの橋渡しをすることです。また一方では、ユーザーが構築してきたありとあらゆるカスタムパイプラインがあります。

6月には、ECSへの移行方法に関するウェビナーも開催しました。このブログ記事はそのウェビナーでの説明を基にして、Beats環境におけるECSへの移行についてさらに詳述します。カスタムのデータ投入パイプラインをECSに移行することについては、今後のブログ記事で取り上げます。

このブログ記事で取り上げる内容は以下のとおりです。

Elastic Stack 7を使用したECSへの移行
ECSへの移行の概念に関する概要
Beats環境をECSに移行することについての概要
独自の移行戦略の構築
移行例
まとめ
参照資料

Elastic Stack 7を使用したECSへの移行

Beatsで使用する多くのイベントフィールドの名前を変更することは、ユーザーにとって破壊的な変更となります。そこで、最新のメジャーリリースであるElastic Stackバージョン7では、ECSフィールド名を導入しました。

この記事では、Beats環境におけるECSへの移行の概要を、Elastic Stack 6.8から7.2にアップグレードするというコンテキストに基づいて説明することから始めます。その後、1つのBeatsイベントソースの移行例を手順ごとに説明します。

このブログ記事では、バージョン7への移行の一部のみを取り上げることに注意してください。Elasticのスタックアップグレードガイドラインで提案しているとおり、BeatsのアップグレードはElasticsearchおよびKibanaのアップグレードの後に実行する必要があります。したがってこのブログ記事で紹介する移行例では、ElasticsearchとKibanaはすでにバージョン7にアップグレードされていると想定し、Beatsのアップグレードのみを取り上げます。そうすることで、ECSより前のスキーマからECSへとBeatsをアップグレードすることに焦点を絞って説明することができます。

Elastic Stack 7への移行を計画する際には、前述のガイドラインを必ず確認し、Kibanaアップグレードアシスタントを参照してください。もちろん、使用しているスタック各部に関するアップグレードノートや破壊的な変更について、慎重に確認することも必要です。

注：Beatsの採用を検討していて、Beats 6からのデータを持っていない場合は、移行について心配する必要はありません。この場合は単純にBeatsバージョン7.0以降を使い始めることができます。そのままでECS形式のイベントが作成されます。

ECSへの移行の概念に関する概要

ECSへの移行には必ず次の手順が伴います。

データソースをECSに変換する
ECS前のイベント形式とECSのイベントの違いや不一致を解決する
ECSイベントを使用できるように、分析コンテンツ、パイプライン、アプリケーションを調整する
スムーズに移行できるようにするために、ECS前のイベントをECSに準拠するように変換する
すべてのソースをECSに移行したら、フィールドのエイリアスを削除する

このブログ記事では、Beats環境をECSに移行するというコンテキストに基づいて、具体的にこれらの手順を説明します。

まず概要を説明し、続いて1つのFilebeatモジュールを6.8から7.2にアップグレードする例を手順ごとに説明します。本ブログの移行例は、ワークステーションを使用して簡単に移行の各部分を実行し、その中で実験できるように設計されています。

Beats環境をECSに移行することについての概要

上述の移行の各部分には、多くの方法で対応できます。それぞれについて、BeatsイベントをECSに移行するというコンテキストに基づいて見ていきましょう。

データソースをECSに変換する

Beatsは、精選された多くのイベントソースを扱います。Beats 7.0以降では、それぞれがすでにECS形式に変換されています。イベントにメタデータを追加するBeatsプロセッサーもECSに変換されています（add_host_metadataなど）。

ただし、Beatsは単純にイベントの転送機能となる場合があることを理解しておくことが重要です。その例としては、WinlogbeatおよびJournalbeatで収集されたイベント、そしてカスタムのログおよびイベントで使用するFilebeat入力があります（Filebeatモジュール自体は除きます）。自身で現在収集および解析しているカスタムのイベントソースをすべてECSにマッピングする必要があります。

スキーマの違いや不一致を解決

ECSへの移行には、多くのデータソースに渡ってフィールド名を標準化することが必要になります。つまり、多くのフィールドの名前を変更する必要があります。

フィールドの名前変更とフィールドのエイリアス

移行時において、ECS前のイベントとECSのイベントの形式の違いに対処する方法はいくつかあります。その主要な選択肢となるのは次のとおりです。

新しいインデックスが古いフィールド名を認識できるように、Elasticsearchのフィールドエイリアスを使用する
同じイベントのデータを複製する（古いフィールドとECSフィールドの両方を入力する）
何もしない：古いコンテンツは古いデータでのみ機能し、新しいコンテンツは新しいデータでのみ機能する

最もシンプルでコスト効果の高いアプローチは、Elasticsearchのフィールドエイリアスを使用する方法です。これが、Beatsのアップグレード手順で選択されている移行パスになります。

ただし、フィールドエイリアスにはある程度の制限があるため完璧な解決策ではありません。何が可能でどのような制限があるかについて見ていきましょう。

フィールドエイリエアスは単純に、Elasticsearchでの新しいインデックスのマッピングにおける追加フィールドです。これにより、新しいインデックスは古いフィールド名を使用してクエリに対応できるようになります。例を見てみましょう。分かりやすくするために1つのフィールドのみを表示しています。

新しいインデックスにおけるフィールドエイリアス

もう少し細かく説明すると、フィールドエイリアスは次のことに役立ちます。

エイリアスフィールドのアグリゲーションとビジュアライゼーション
エイリアスフィールドのフィルターと検索
エイリアスフィールドの自動入力

フィールドエイリアスに関する注意事項は次のとおりです。

フィールドエイリアスは純粋にElasticsearchのマッピング機能です（検索インデックス）。そのため、ドキュメントソースやそのフィールド名は変更されません。ドキュメントは古いフィールド名または新しいフィールド名のどちらかで構成されています。フィールドはドキュメント上で直接アクセスされるため、以下のような場合にはエイリアスは役に立ちません。
- 保存された検索に表示されている列
- データ投入パイプラインでの追加処理
- Beatsイベントを使用する任意のアプリケーション（例：Elasticsearch API経由）
フィールドエイリアス自体がフィールドへの入力であるため、同じ名前の新しいECSフィールドがある場合はエイリアスを作成することができません。
フィールドエイリアスはリーフフィールドの場合のみ機能します。objectフィールドなど、他のフィールドがネストされているような複雑なフィールドにエイリアスを設定することはできません。

フィールドエイリアスは、Beats 7のインデックスでデフォルトで作成されることはありません。作成を有効にするには、Beatsのセットアップ手順を実行する前に、各BeatのYAML構成ファイルでmigration.6_to_7.enabled: trueを設定する必要があります。このオプションおよび関連するエイリアスは、Elastic Stack 7.xの間は利用でき、8.0で削除されることになります。

不一致

ECSに移行する際、使用しているソースによってはフィールドの不一致にも遭遇することになります。

注意が必要なのは、実際に使用しているフィールドについてのみ検出される不一致の型があるということです。つまり、使用していないソースでの変更や不一致から影響を受けることはありません。これは、対処する必要が生じるすべての不一致を移行計画時に明らかにするために、テスト環境内において、各データソースからイベントサンプルを両方の形式（Beats 6および7）で投入する必要があることも意味します。

不一致には次の2つの場合があります。

フィールドのデータ型がより適切な型に変更されている
ECSより前に使用していたフィールド名がECSでも定義されており、違う意味を持っている（Elasticでは非互換フィールドと呼んでいます）

このような不一致の各型からもたらされる正確な結果は、状況によって異なります。ただし一般的には、フィールドのデータ型が変更されている、または非互換フィールドのネスト関連が変更されている（たとえば、keywordフィールドがobjectフィールドになっている）場合、ECS前のソースとECSのソースに渡って一度にクエリを実行することはできません。

Beats 6および7のインデックスにデータが入力され、Kibanaのインデックスパターンを更新すると、それらの不一致が明らかになります。インデックスパターンを更新した後に不一致のアラートが表示されない場合は、解決すべき不一致はないことになります。アラートが表示された場合は、不一致だけが表示されるようにデータ型セレクターを設定することができます。

データ型セレクターでの不一致の選択

これらの不一致に対処する方法は、過去のデータを再インデックスして新しいスキーマとの互換性をより高めることです。型の変更によって生じる不一致は簡単に解決できます。より適切なデータ型を使用するためにBeats 6のインデックスパターンを上書きして、新しいインデックスに再インデックスし（更新されたマッピングを有効にするため）、その後、古いインデックスを削除することができます。

非互換フィールドがある場合は、それらを削除するか、それらの名前を変更するかを決める必要があります。フィールドの名前を変更する場合は、まずインデックスパターン内でそれを必ず定義しましょう。

ECSイベントを使用するように環境を調整

多くのフィールド名が変更されたため、Beatsで提供されるサンプル分析コンテンツ（ダッシュボードなど）はすべて、新しいECSフィールド名を使用するように変更されました。新しいコンテンツは、Beats 7.0以降で作成されたECSデータでのみ機能します。つまり、Beatsのセットアップでは既存のBeats 6のコンテンツが上書きされることはありません。その代わり、各Kibanaビジュアライゼーションの2つ目のコピーが作成されます。この新しい各Kibanaビジュアライゼーションは以前と同じ名前になりますが、その名前の最後に「ECS」が追加されます。

古いスキーマに基づいたBeats 6のサンプルコンテンツおよびカスタムコンテンツは、フィールドエイリアスを使用すれば、そのほとんどが引き続きBeats 6および7のデータで機能します。ただし、前述したとおり、フィールドエイリアスはECSへの移行に役立つ部分的かつ一時的な解決策です。したがって、新しいフィールド名の使用を開始するためには、移行の際にカスタムダッシュボードのアップデートまたは複製も行う必要があります。

これを次の表にまとめます。

ECS前（Beats 6、カスタムダッシュボード）	ECS （Beats 7）
[Filebeatシステム]Syslogダッシュボード	[Filebeatシステム]SyslogダッシュボードECS
古いフィールドとエイリアスのアグリゲーション古いフィールドとエイリアスのフィルター保存済みの検索：古いフィールドのみ表示	新しいフィールドのみのアグリゲーション新しいフィールドのみのフィルター保存済みの検索：新しいフィールドのみ表示

Kibanaでの分析コンテンツの確認と修正に加えて、イベントパイプラインのすべてのカスタムパートの確認、およびElasticsearch APIを通じてBeatsイベントにアクセスするアプリケーションの確認も必要になります。

ECS前のイベントをECSに準拠するように変換

再インデックスを使用して、データ型の不一致および非互換フィールドに対処することについてはすでに説明しました。この2つの型の変更に再インデックスで対処することはオプションですが、かなり簡単に実装することができるため、ほとんどの場合に実行する価値があると考えられます。シンプルなユースケースとして、不一致を無視するというのも実行可能な解決策です。ただし注意が必要なのは、Beats 7のデータの投入を開始したときからBeats 6が古くなってクラスターから排除されるときまで、フィールドの不一致から影響を受ける可能性があるということです。

再インデックス

状況によっては、フィールドエイリアスによるサポートでは不十分な場合もあります。その場合は、過去のデータを再インデックスして、Beats 6のデータにECSフィールド名をバックフィルすることも可能です。そうすることで、ECSフィールド（新しいBeats 7コンテンツおよび更新されたカスタムコンテンツ）に依存しているすべての新しい分析コンテンツが、Beats 7データに加えて古いデータ全体にクエリを実行できるようになります。

データ投入時にイベントを修正

Beats 7エージェントのロールアウト期間が長期になることが予想される場合、過去のインデックスを単純に再インデックスすること以外にも対処方法があります。データ投入時に、収集されるBeats 6イベントを修正することも可能です。

再インデックスしてドキュメントの操作（コピー、削除、またはフィールド名の変更など）を実行する方法はいくつかあります。最も単純な方法はElasticsearch投入パイプラインを使用することです。次のような利点があります。

_simulate APIを使用して簡単にテストできる
パイプラインを使用して過去のインデックスを再インデックスできる
パイプラインを使用して、引き続き収集されるBeats 6イベントを修正できる

受信時にイベントを修正するためには、ほとんどの場合、パイプラインに送信するようにElasticsearch出力「パイプライン」を設定する必要があるだけです。これはLogstashとBeatsも同様です。

ただし、Filebeatモジュールはすでに投入パイプラインを使用してパースを実行しています。これらも修正することが可能です。Filebeat 6パイプランを上書きして、調整パイプラインにコールアウトを追加するだけです。

フィールドエイリアスを削除

フィールドエイリアスが不要になったら、削除することを検討しましょう。すでに述べましたが、エイリアスのほうがすべてのデータを複製するよりも軽量です。ただし、それでも重要なリソースであるクラスターステータスのメモリーを消費します。また、Kibanaの自動入力にも表示されるため、不要に煩雑になります。

古いフィールドエイリアスを削除するには、Beats構成（filebeat.yml）からmigration.6_to_7.enabled設定を削除（またはfalseに設定）し、「セットアップ」作業を再度実行してテンプレートを上書きするだけです。

注意が必要なのは、エイリアスを含まないようにテンプレートを上書きすると、インデックスのロールオーバーを待つ時間が生じることです。それが完了すると、インデックスマッピングからエイリアスが排除されます。インデックスのロールオーバーが完了した後、エイリアスを含んでいたBeats 7のデータが完全になくなる状態になるには、それらのデータが古くなってクラスターから排除されるのを待つ必要があります。

独自の移行戦略の構築

BeatsデータをECSに移行する際に、Beatsがどのように役立つかについて見てきました。また、移行をよりシームレスにするために実行できる追加の手順についても説明しました。

各データソースに必要な作業を個別に評価する必要があります。重要性が最も低いデータソースについては、より少ない処理で済ませるように選択することが可能です。

各データソースを確認する際に考慮に入れることが可能な基準には、以下のものがあります。

保持期間はどれくらいですか？それは外部から義務付けられているものですか？移行に際して、早期にデータを削除するという選択肢がありますか？
データに継続性が必要ですか？または、切り替えが可能ですか？これは上述のバックフィルの必要性を考えるのに役立ちます。
Beats 7のロールアウトにどれくらいの期間が必要ですか？Beats 6のイベントを、収集時に修正する必要がありますか？

多数のフィールドのバックフィルを計画する場合は、Beatsレポジトリのdev-tools/ecs-migration.ymlを確認してください。このファイルには、Beats 6から7への移行におけるすべてのフィールド変更がリストされています。

移行例

再度お伝えしておきましょう。この記事で説明するのは、Beats 6.8から7.2にアップグレードすることでECSを移行する手順、エイリアスで可能になることと制限、不一致の解決方法、最近の過去のデータを再インデックスして移行に役立てる方法、引き続き収集されるBeats 6のイベントを修正する方法です。本ブログの例では、FilebeatのSyslogモジュールを使用します。

前述したとおり、例ではElastic Stack全体のアップグレードを取り上げることはしません。ElasticsearchとKibanaはすでにバージョン7にアップグレードされていることを前提としてします。そうすることで、データスキーマをECSにアップグレードする作業の説明に焦点を絞ることができます。

このブログの内容に従うためには、Elasticsearch 7およびKibana 7の最新バージョンを使用してください。Elastic Cloudアカウントの無料トライアルを使用するか、またはElasticsearchおよびKibanaのインストール手順に従ってそれらをローカルで実行できます。

Beats 6.8の実行

このデモでは、1つのマシンで同時にFilebeat 6.8と7.2を実行します。そのため、アーカイブインストール（.zipまたは.tar.gzを使用）で両方をインストールすることが重要です。アーカイブインストールはそれぞれのディレクトリに含まれており、プロセスの簡素化に役立ちます。

ElasticsearchおよびKibana 7を実行し、Filebeat 6.8をインストールします。Windowsを使用している場合は、代わりにWinlogbeatをインストールして試すこともできます。

ほとんどのシステムでは、タイムゾーンを指定しない場合、Syslogはタイムスタンプとして現地時間を使用します。add_localeプロセッサーによって各イベントにタイムゾーンが追加されるようにFilebeatを構成し、状況に応じてタイムスタンプを解釈するようにシステムモジュールのパイプラインを構成します。こうすることで、後で、最近受信したイベントを確認してECSへの移行を検証することができるようになります。

filebeat.ymlで「processors」セクションを見つけ、add_localeプロセッサーを追加します。processorsセクションの下に、下記のモジュール構成を追加します。

processors:
  - add_host_metadata: ~
  - add_cloud_metadata: ~
  - add_locale: ~
filebeat.modules:
  - module: system
    syslog:
      var.convert_timezone: true

ElasticsearchとKibanaをローカルで実行している場合は、上記で十分です。Elastic Cloudを使用している場合は、クラウドの認証情報をfilebeat.ymlに追加する必要もあります（両方ともクラスター作成時にElastic Cloud内で見つかります）。

cloud.id: 'my-cluster-name:a-very-long-string....'
cloud.auth: 'username:password'

では、Filebeat 6.8がシステムログをキャプチャできるようにしましょう。

./filebeat setup -e
./filebeat -e

[Filebeatシステム]Syslogダッシュボードと呼ばれるダッシュボードを見て、データが受信されていることを確認しましょう。Filebeatがインストールされているシステムで最近のSyslogイベントが生成されていることが分かるはずです。

ビジュアライゼーションと保存済みの検索が含まれているため、興味深いダッシュボードとなっています。どのフィールドエイリアスが役に立ち、また役に立たないかを見るのに便利です。

Beats 7（ECS）の実行

実際には、すべての環境でBeatsバージョンの即時切替が可能なわけではありません。一定期間、イベントはFilebeat 6および7から同時に来ることになります。この例もそれとまったく同じようにしましょう。

Filebeat 7.2と6.8を1つのシステムで同時に稼働させるだけです。Filebeat 7.2を別のディレクトリに抽出し、6.8に適用したのと同じ構成変更を適用します。

ただし、まだセットアップを実行しないでください。Beats 7では、移行設定も有効にする必要があります。これによってフィールドエイリアスが作成されるようになります。filebeat.ymlの最後にあるこの行のコメントアウトを解除します。

migration.6_to_7.enabled: true

これで7.2の構成ファイルには、この追加の移行属性、add_localeプロセッサー、システムモジュール用の構成、そして必要な場合はクラウドの認証情報が含まれているはずです。

別の端末からFilebeat 7.2を開始します。

./filebeat setup -e
./filebeat -e

不一致

ダッシュボードを見る前に、Kibanaインデックス管理に進み、新しいインデックスが作成されたこと、およびデータを受信していることを確認します。次のように表示されているはずです。

新しいインデックスが作成されたことの確認

また、インデックスパターンに進み、filebeat-*インデックスパターンを更新します。 6.8と7.2のデータについてインデックスパターンを更新すると、いくつかの不一致があるはずです。右側にあるデータ型セレクターを［All field types］から［conflict］に変更して、不一致に焦点を絞ることができます。

データ型セレクターを［conflict］に変更

上記のうち2つの不一致に注目し、どのように対処するか考えてみましょう。

まず、Syslog固有の不一致、system.syslog.pidを見てみます。インデックス管理ページに進み、6.8のマッピングを見ると、フィールドがkeywordとしてインデックスされていることが分かります。7.2のインデックスマッピングを見ると、system.syslog.pidのエイリアスがprocess.pidであることが分かります。これは問題ではなく、不一致の原因ではありません。そこで、そのエイリアスprocess.pidのデータ型を見ると、longになっています。keywordからlongに変わったことが、データ型の不一致の原因となっているのです。

次に、非互換フィールドによって生じた不一致を見てみましょう。sourceフィールドです。これはFilebeatの移行のすべてに共通します。Filebeat 6では、sourceはkeywordフィールドであり、通常、ファイルパスが含まれています（またはSyslogソースアドレスの場合があります）。ECSでは（つまりFilebeat 7のフィールドマッピングでは）、sourceはネストされたフィールドのあるオブジェクトになっています。これらのフィールドは、ネットワークイベントのソースを説明するために使用されます（source.ip、source.portなど）。sourceという名前のフィールドはBeats 7にも存在しているため、7でエイリアスフィールドを作成することはできません。

そこで、移行手順の一部として対応できる2つのフィールドを特定しました。これらについては後で説明します。

エイリアス

Beats 6 [Filebeatシステム]Syslogダッシュボードを開いたままにしておきます。filebeat-*インデックスパターンは、このダッシュボードを初めてロードしたときからは変更されているため、Command-RまたはF5を押してページ全体をリロードします。

新しいタブから、新しいダッシュボード[Filebeatシステム]SyslogダッシュボードECSを開きます。

6.8ダッシュボードの最下部にある保存済みの検索を見ると、データに齟齬があるのが分かります。system.syslog.programおよびsystem.syslog.messageの値があるイベントとないイベントがあります。空の値のものを開くと、7.2で取得されたのと同じSyslogイベントであり、フィールド名が異なっていることが分かります。ECSダッシュボードのタブで同じ期間を見てみると、同じ現象がECSダッシュボードからも見られることが分かります。ECSフィールドのprocess.nameとmessageには、6.8のイベントではなく、7.2のイベントが入力されています。

Syslogのログの表示

これが、フィールドエイリアスが役に立たない具体的な一例です。保存済みの検索は、インデックスマッピングではなく、ドキュメントのコンテンツに依存します。概要ですでに述べているとおり、継続性が必要な場合は、再インデックスしてバックフィルを行うこと（および受信時にイベントを変更すること）によって対処することになります。これについてはのちほど説明します。

ここで、フィールドエイリアスが役に立つ場合を見ておきましょう。6.8ダッシュボードでのドーナツ型のビジュアライゼーションを見てみましょう。外側のリングにカーソルを合わせると、system.syslog.programの値が表示されます。

Syslogホスト名およびプロセスグラフ

リングのセクションをクリックして、1つのプログラムで生成されたメッセージをフィルターします。プログラム名の1つのフィルターのみを選択してみましょう。

適用するフィルターの選択

7.2ではすでに存在していないフィールドのフィルターsystem.syslog.programを先ほど追加しました。保存済みの検索で、引き続き両方のメッセージセットを見ることができます。

保存済みの検索内に両方のメッセージセットが表示

7.2の要素を調査すると、それらに対してフィルターが正常に適用されていることが分かります。つまり、system.syslog.programのフィルターは、system.syslog.programエイリアスのおかげで7.2のデータに対して正常に機能することが分かります。

Elasticsearchのアグリゲーションがサポートするビジュアライゼーションでも、移行されたsystem.syslog.programフィールドに関して、6.8と7.2の両方で正しい結果が表示されることが分かります。

7.2のダッシュボードに戻ると、フィルターを適用していない状態で、6.8と7.2のデータの両方を見ることができます。しかし、6.8に適用したのと同じフィルターを適用すると、異なる挙動となります。process.name:iTunesでフィルターすると、7.2のイベントのみが返されます。6.8のインデックスにはprocess.nameという名前のフィールドはなく、その名前のエイリアスもないからです。

6.8と7.2の両方のデータが表示

スムーズな移行のための再インデックス

移行の3つの側面に対処するために、再インデックスがどのように役立つかについて見てきました。その3つとは、データ型の不一致の解決、非互換フィールドの解決、および継続性の維持を目的としたECSフィールドのバックフィルです。それぞれについて1つずつ例を見ていきましょう。

Beats 6のデータを修正する方法は次のとおりです。

データ型の不一致：system.syslog.pidのデータ型をkeywordからlongに変更する
非互換フィールド：Filebeatのsourceフィールドを、その内容をlog.file.pathにコピーした後に削除する。これにより、ECSのソースフィールドセットとの不一致を排除できます。実際には、Beats 6.6以降ではすでに同じ値がlog.file.pathにも含まれています。ただし、6.6より前のBeats 6バージョンではそのようになっていないため、必要な場合はコピーする必要があることにご注意ください。
ECSフィールドprocess.nameにsystem.syslog.processの値をバックフィルする。

これらの変更の実施方法は次のとおりです。

新しいデータ型を使用するようにFilebeat 6.8インデックステンプレートを修正して、フィールド定義を追加および削除する
フィールドの削除またはコピーによって6.8イベントを修正する新しい投入パイプラインを作成する
_simulate APIでパイプラインをテストする
パイプラインを使用して過去のデータを再インデックスする
また、受信するイベントを修正するために、Filebeat 6.8投入パイプラインの最後にこの新しいパイプラインに関する行を追加する

インデックステンプレートの変更

データ型の改善はインデックステンプレートで実行する必要があります。インデックスがロールオーバーされると有効になります。このロールオーバーは、デフォルトでは次の日に完了します。6.8でインデックスライフサイクル管理（ILM）を使用している場合は、ロールオーバーAPIで強制的にロールオーバーさせることができます。

Kibana開発ツールから現在のインデックステンプレートを表示します。

GET _template/filebeat-6.8.1

インデックステンプレートは修正できません。完全に上書きする必要があります（ドキュメント）。インデックステンプレート全体に関するPUT APIコールを準備し、その中のいくつかを変更します。

sourceの定義を削除（下記の-で始まるすべての行）
program.nameのフィールド定義を追加
フィールドのタイプをsystem.syslog.pidからlongに変更

PUT _template/filebeat-6.8.1
{
  "order" :1,
  "index_patterns" : [
    "filebeat-6.8.1-*"
  ]
  ...
  "mappings": {
    "properties" : {
-     "source" : {
-       "ignore_above" :1024,
-       "type" : "keyword"
-     },
      "program" : {
        "properties" : {
          "name": {
            "type": "keyword",
            "ignore_above":1024
          }
        }
      },
      "system" : {
        "properties" : {
          "syslog": {
            "properties" : {
              "pid" : {
                "type" : "long"
              }
      ...     
}

APIコールの本文の準備ができたら、実行してインデックステンプレートを上書きします。多数のECSフィールドのバックフィルを計画する場合は、ECS gitレポジトリにあるサンプルのECS Elasticsearchテンプレートを確認してください。

再インデックス

次の手順は、Beats 6.8のイベントを修正するために新しい投入パイプラインを記述することです。例として、system.syslog.programをprocess.nameにコピーし、sourceをlog.file.pathにコピーします（すでに入力されていない場合）。そしてsourceフィールドを削除します。

PUT _ingest/pipeline/filebeat-system-6-to-7
{ "description":"Pipeline to modify Filebeat 6 system module documents to better match ECS",
  "processors": [
    { "set": {
        "field": "process.name",
        "value": "{{system.syslog.program}}",
        "if": "ctx.system?.syslog?.program != null"
    }},
    { "set": {
        "field": "log.file.path",
        "value": "{{source}}",
        "if": "ctx.containsKey('source') && ctx.log?.file?.path == null"
    }},
    { "remove": {
        "field": "source"
    }}
  ],
  "on_failure": [
    { "set": {
        "field": "error.message",
        "value": "{{ _ingest.on_failure_message }}"
    }}
  ]
}

投入パイプラインおよびPainless言語（if節で使用）の詳細について確認してください。

完全な状態となっている入力イベントを使用してこのパイプラインを_simulate APIでテストできますが、ブログ記事に収めるのにちょうど良い最小限のテストが下記になります。log.file.pathがすでに入力されているイベントが1つあること（Beats 6.6以降）および入力されていないイベントが1つあること（6.5以前）に気付くはずです。

POST _ingest/pipeline/filebeat-system-6-to-7/_simulate
{ "docs":
  [ { "_source": {
      "log": { "file": { "path": "/var/log/system.log" } },
      "source": "/var/log/system.log",
      "system": {
        "syslog": {
          "program": "syslogd"
    }}}},
    { "_source": {
      "source": "/var/log/system.log",
      "system": {
        "syslog": {
          "program": "syslogd"
    }}}}
  ]
}

このAPIコールへの応答には、修正された2つのイベントが含まれています。sourceフィールドがなくなっており、両方のイベントの値がlog.file.pathに保存されているため、パイプラインが機能していることが確認できます。

これで、この投入パイプラインを使用して、移行するFilebeatインデックスのすべてについて、書き込み（昨日以前のインデックスなど）を受信しなくなったインデックスで再インデックスを実行できるようになりました。バックグラウンドでの再インデックスの方法、再インデックスオペレーションの調整などについては、_reindex docsをお読みください。以下は、ここでのいくつかのイベントに役立つ簡単なインデックス再作成です。

POST _reindex
{ "source": { "index": "filebeat-6.8.1-2019.07.04" },
  "dest": {
    "index": "filebeat-6.8.1-2019.07.04-migrated",
    "pipeline": "filebeat-system-6-to-7"
}}

ここまでの手順に従っており、今日のインデックスのみを持っている場合は、APIコールを自由に試し、移行されたインデックスのマッピングを調べてみてください。ただし、後から今日のインデックスを削除しないようにしてください。Filebeat 6.8からはまだデータが送信されているため、それらは再度作成されるだけです。

使用されていないインデックスを再インデックスしたら、新しいインデックスが予想どおりに修正されたことを確認し、古いインデックスを削除します。

受信するイベントを修正

ほとんどのBeatsは、Elasticsearch出力の投入パイプラインに直接送信するように構成できます（LogstashのElasticsearch出力についても同様です）。このデモでは、すでに投入パイプラインを使用しているFilebeatモジュールを使用しているため、ここではそのモジュールのパイプラインを修正する必要があります。

Filebeat 6.8のセットアップによってインストールされる、処理用の投入パイプラインは、filebeat-6.8.1-system-syslog-pipelineと呼ばれます。ここで必要なのは、Filebeat Syslogパイプラインの最後に、独自のパイプラインに関するコールアウトを追加することだけです。

修正しようとしているパイプラインを表示します。

GET _ingest/pipeline/filebeat-6.8.1-system-syslog-pipeline

次に、パイプラインを上書きするAPIコールを準備します。パイプライン全体をPUT APIコールの下に貼り付け、“pipeline”プロセッサーを最後に追加することで新しいパイプラインを呼び出します。

PUT _ingest/pipeline/filebeat-6.8.1-system-syslog-pipeline
{ "description" :"Pipeline for parsing Syslog messages.",
  "processors" :
  [
    { "grok" : { ... }
    ...
    { "pipeline": { "name": "filebeat-system-6-to-7" } }
  ],
  "on_failure" : [
    { ... }
  ]
}

このAPIコールを実行した後、受信するすべてのイベントはインデックスされる前に、よりECSに一致するように修正されます。

最後に、_update_by_queryを使用して、パイプラインを変更する直前からのライブインデックスでドキュメントを変更できます。まだsourceフィールドがあるかどうかを確認することで、アップデートが必要なドキュメントを確認できます。

GET filebeat-6.8.1-*/_search
{ "query": { "exists": { "field": "source" }}}

該当分だけを再インデックスします。

POST filebeat-6.8.1-*/_update_by_query?pipeline=filebeat-system-6-to-7
{ "query": { "exists": { "field": "source" }}}

不一致を検証

不一致のあるすべてのインデックスを削除すると、再インデックスされたものだけが残ります。インデックスパターンを更新して不一致がなくなったことを確認できます。Filebeat 7のダッシュボードに戻り、その中の6.8データがprocess.nameフィールドのバックフィルのおかげでより使えるものになったことを確認できます。

process.nameフィールドのバックフィル後のダッシュボード

本ブログの例では1つのフィールドのみをバックフィルしましたが、もちろん必要なだけいくつでもフィールドを自由にバックフィルすることができます。

移行後のクリーンアップ

移行には、カスタムダッシュボードの修正と、API経由でBeatsイベントを使用して新しいECSフィールド名を使用するアプリケーションの修正が伴います。

完全にBeats 7に移行してフィールドエイリアスを使わなくなったら、それらのエイリアスを削除することで、すでに説明したようにメモリーの消費を削減するという利点が得られます。エイリアスを削除するには、filebeat.ymlからmigration.6_to_7.enabled属性を削除し、以下を使用してFilebeat 7.2テンプレートを上書きします。

./filebeat setup --template -e -E 'setup.template.overwrite=true'

以前のFilebeat 6.8テンプレートへの変更と同様、エイリアスのない新しいテンプレートはFilebeat 7.2インデックスの次回のロールオーバーで有効になります。

まとめ

この記事では、Beats環境でデータをECSに移行するために必要な手順について説明しました。アップグレードを実行することによる利点と、その制限について見てきました。それらの制限には、過去のデータを再インデックスすること、さらに、現在受信しているBeats 6のデータを投入プロセス時に修正することで対処できます。

移行について概要レベルで説明した後、例としてFilebeatのシステムモジュールを6.8から7.2にアップグレードする各手順を実行しました。そして、Filebeat 6.8および7.2からのイベントの違いを確認し、過去のデータを再インデックスするためにユーザーが実行できるすべての手順、および継続的に受信しているデータの修正について説明しました。

スキーマの導入は必然的に既存のインストールに大きな影響を及ぼしますが、この移行には価値があるとElasticは強く信じています。その理由については、Elastic Common Schemaについておよび監視性に最適なElastic Common Schemaでご確認いただけます。

ご自身の環境でBeats以外のデータ投入パイプラインを使用している場合は、今後の情報をご確認ください。カスタムの投入パイプラインをECSに移行する方法を説明する別のブログ投稿を予定しています。

ECSについてご質問がある場合、またはBeatsのアップグレードについて支援が必要な場合は、Discussフォーラムにアクセスして、ご質問にelastic-common-schemaをタグ付けしてください。ECSの詳細については、Elasticのドキュメントでご確認ください。GitHubでECSに貢献していただくことも可能です。

参照資料

ドキュメント

ブログとビデオ

一般

DiscussフォーラムでECSについて質問（質問に「elastic-common-schema」とタグ付け）
オフィシャルECSドキュメント
ECS Githubレポジトリ

Elasticsearch Platform

ELK Stack

オブザーバビリティ

セキュリティ

Search

業界別

ソリューション別

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

Elastic Stack 7を使用したECSへの移行

ECSへの移行の概念に関する概要

Beats環境をECSに移行することについての概要

データソースをECSに変換する

スキーマの違いや不一致を解決

フィールドの名前変更とフィールドのエイリアス

不一致

ECSイベントを使用するように環境を調整

ECS前のイベントをECSに準拠するように変換

再インデックス

データ投入時にイベントを修正

フィールドエイリアスを削除

独自の移行戦略の構築

移行例

Beats 6.8の実行

Beats 7（ECS）の実行

不一致

エイリアス

スムーズな移行のための再インデックス

インデックステンプレートの変更

再インデックス

受信するイベントを修正

不一致を検証

移行後のクリーンアップ

まとめ

参照資料

SNSリンク

会社概要

参加する

パートナー

信頼とセキュリティ

投資家向け情報

Excellence Awards