Mildensteinさんから日本語(ローマ字)で返信を頂きました。ブログ記事を翻訳してもいいかを尋ねたところ、快くOKを頂いたので、翻訳してみました。(誤訳など見つけたらコメントください。数年前、Elasticsearch、Logstash、Kibana(ELK)を管理し、ここ30日よりも古いインデックスを自動的に削除する方法を必要としていました。APIドキュメントを読み、#logstashや#elasticsearchのIRCチャネルのコミュニティの助けを借りて、簡単なスクリプトとcronを用意するのが簡単であることを知りました。'localhost:9200/logstash-2014.01.01?pretty'もちろん、これも動作しますが、日付を生成するのがめんどくさいのでもっとエレガントな方法が欲しかったです。最初にpythonでスクリプトを書き始めました。特定の日数のインデックスを管理するだけのコマンドラインクリーナーを書いてコミュニティにシェアしました。他の人が、新しい機能を追加してくれました。私は、古いインデックスをoptimizeすることができる他のスクリプトも書きました。これは、シャードごとにnセグメント以上存在しないように各シャードのセグメントをマージすることです。これらのスクリプトで1つになるようにマージしたりエンハンスし、古いインデックスを管理する助けになるツールです。0.5.1がリリースされ、0.90.10に対応しています。Curatorはまた、Elasticsearchの1.0(現在はRC1)へも対応しています。各リリースへの互換性の保証のためのテストも行っています。現時点では、gitリポジトリで配布しています。近い将来、pipによるインストール可能なパッケージにする予定です。利用することを恐れないでください。pythonとpipがあなたのマシンにインストールされていれば、次のようにインストールは簡単です。requirements.txtインストール後の確認は次のコマンドです。0.5.1利用方法とサンプルサンプルを示す前に、オプションを見ておくとよいでしょう。このリストは長いですが(この記事の最後に含まれています)、どのようなことがコントロールできるかを説明しています。デフォルトがどうなっているかに注意してください。デフォルト値で良い場合は、フラグを指定する必要はありません。簡単なサンプルを見ながら、CuratorがELKスタックをどうやって管理するかを見て行きましょう。削除(delete)90日以上のインデックスを保存したくないとしましょう。コマンドは次のようになります。90-dで日数を指定しているだけです。space)これは、指定したギガバイト数を超えたインデックスを場合に(最も古いものから)削除を行う特殊なケースです。10024-Cでspaceによるcurationであること、-gでギガバイト数(10024、10TB)であることを指定しているのがわかります。-gは1.5や0.5という数値を指定できます。その他のCuratorオプションはspaceによる削除と組み合わせて使用できないことに注意してください。APIにより、インデックスをクローズすることができます。APIを利用すると、インデックスをクローズしたり、あとでオープンしたりすることができます。クローズされたインデックスはクラスタのオーバヘッドにほとんどならず(メタデータの管理を除く)、読み書き操作の妨げにもなりません。クローズされたインデックスは、リカバリプロセス時に、オープンされます。インデックスをクローズすることは、存在はするが検索できないという意味です。何が便利なのでしょう?90日のインデックスを保存する義務があるが、検索は過去30日のインデックスを対象にする以外は稀であるような場合を想像してください。このような状況で、価値のあるリソース(ヒープスペースなど)を節約するためにインデックスをクローズすることができます。これは、クラスタに検索やインデキシングのためのメモリを与えることができることを意味します。クローズしたインデックスのデータが必要になったら、APIを呼び出してインデックスをオープンすれば検索できます。このような場合、今オープンしているインデックスが再び、クローズされないように、一時的にCuratorのスケジュール実行をオフにしておくのが懸命です。90先ほど説明した例の実行方法です。これは、30日よりも古いインデックスはクローズし、90日より古いインデックスを削除します。filterの無効化これは、0.90.9以降のバージョンで利用可能な機能です。#4525)心配しないでください。このスクリプトは操作を行う前に、elasticsearchが利用可能なバージョンであるかをチェックします。filterはインデキシング操作を高速化するためにリソースを割り当てられます。時系列データで、インデキシングしている間もこれは有用です。インデックスは2日後には、日付が変わると新しいデータはおそらくインデックスされません。filterはまだ持っています。filterのリソースは少なくとも2日(1にもできます)よりも古いインデックスについては利用せず、30日より古いインデックスはクローズし、90より古いインデックスは削除します。APIのoptimizeを見ることは、生きているインデックスや"cold"インデックス(インデキシングがアクティブではないという意味)に実行する必要があるということを理解するために重要です。実際、optimizeはLuceneではforceMergeと名前が変えられ、インデックスを改善するためにoptimizeを呼び出す必要はなくなりました。Elasticsearchのセグメントをマージすることは利点がありますが、coldインデックス全てに対してoptimizeを開始する前に、コストを理解する必要があります。forceMerge操作はインデックスにある各シャードのセグメントの数を少なくします。各セグメントはオーバヘッドがあるため、セグメントが多いということは、より多くのリソースを使うという意味です。良さそうですね?リソースが少ない?それは、可能ですが、merge操作を実行するには多くのディスクやネットワークI/Oが必要で、ディスクやクラスタの通常の書き込み操作に悪影響を及ぼします。これが必要なら私のアドバイスを良く考えてください。(数%ほど)検索を速くし、リソースの使用量も減らすことができます。管理しているセグメント数が小さくなるということは、クラスタのリカバリを速くすることにもなります。1つのインデックスをoptimizeするためにはおそらく1時間以上の時間がかかります。「使用する前に目立たない場所で試してください」というクリーニングボトル(訳注:洗剤とか漂白剤かな?)の注意書きと同様に、ディスクI/Oが低い時にテストし、もし操作とリソースがあなたのクラスタのユースケースにあっているかを見てください。デフォルトでは、シャードごとに2つのセグメントにマージしますが、--max_num_segmentsフラグで変更可能です。ここまでのサンプルは次のようなコマンドになります。filterは2日より古いインデックスでは向こうにし、2日より古いインデックスは"optimize"し、30日より古いインデックスはクローズし、90日より古いインデックスは削除されます。操作の順序スクリプトは操作が衝突するのを防ぐために次の順序で実行されます。最後の例で、3つの操作を1つのコマンドで実行していますが、それらが連続ですべて実行されるのを望んでいないかもしれません。90これは、次の操作と同様です。3600を追加したり)を指定して実行するのは簡単です。デフォルトのlogstash-とは異なるプレフィックスのインデックスを持っているかもしれません。30最後にCuratorは時系列インデックスの保存ポリシーを管理するのに役立ちます。豊富な設定オプションがインデックスを管理することを簡単にします。クラスタに存在するノードの数に関係なく。