ソフトウェアの話かもしれないはじめにElasticsearchのIngestNodeでのProcessorについて、現在のバージョン6.xで提供されている各編集機能を一覧にして逆引きしやすいようにしてみました。寄り道の補足1IngestNodeはインフラや非機能要件的にはポイントとなるお話があるとは思いますが、自分のようなヒトにとっては、ひとまずは、logstashの代わり、あるいはreindexの際に型変換などを宣言的やってしまえる仕組みと捉えておけば良いのではないでしょうか。つまるところ、インデックスの更新前に、元のデータソースから取得したドキュメントの元ネタを実際にインデックスに取り込むにあたり、変換したりある種の標準化などをしてしまいましょうというところの仕組みになります。深掘りするなら、下記のリンクをはじめ有識者の方の記事等を参考にしましょう。Elasticlogstashの代わりというところの範疇なので、ひょっとすると用途によっては帯に短し的なところがあるかもしれませんので、今回ビルトインの編集機能を表にしてまとめてみた次第です。scriptも使えたり、ジョブの分岐や制御的なこともできる構文が用意されているので、相当なことができるのも事実かと思います。寄り道の補足2実際のProcessorの説明の前にここまでで少し話が飛躍していそうなので、もう一点補足します。IngestNodeというか、ここではIngestNode自体がどうというよりは、pipelineと呼ばれる変換テンプレートのようなものと、今回説明しようとしているProcessorの関係、およびそれらにより、通常のインデックスへの更新(POST)とは違うカタチで、事前のドキュメント変換ができるのかという絵はこうなります。IngestNode(_ingestエンドポイント)を使ったインデックス更新のテンプレートによるドキュメントの前処理Processorのまとめ(チートシート風)チートシート風というか公式Rはアルファベット順になっているので、用途別に逆引きしやすいように用途別に並び替えてみました。やってみるとlogstashの置き換えにもなるという方向性どおり、ログの変換に便利なものが揃っていますね。ElasticsearchのProcessorProcessorのまとめ(前項のテキスト)上記の表と同じもの。コピペやリンク先に飛べるようにテキストでの表にしたがmarkdownの使い方が悪く、幅の調整がうまくいかないので、皆様のお手元では総崩れしているかもしれません。scriptによる変換。条件に合致したらそのドキュメントを捨てる(インデックスに取り込まない)。別のパイプラインを呼び出す。指定のフィールドを削除する。指定の条件にマッチしたら例外を上げる。元のフィールドを残して新たに型変換後の別名フィールドを定義することもできる。"固定の文字列やあるフィールドの項目の内容の配列の新たなフィールドを作る。snippetsによる)して設定。フィールド名がfoo.barのようなものを、ネストオブジェクトに変換する。JSON文字列をJSONオブジェクトに変換する。フィールド名を変更する。"配列型のフィールドに、他のプロセッサーを一つずつ適用した配列を返す。mapっぽい処理になる。配列を区切り文字で区切った一つの文字列に変換する。