AWS
Elasticsearch
lambda

elasticsearchを利用するときは容量を管理しようという話

More than 1 year has passed since last update.

awsのelasticsearch serviceをサービスのログ可視化に使う為にテスト運用を行っていた時に起こった事件をtipsとしてまとめました。

ある日kibanaを見たらログが全然入ってなかった

5分置きにs3に上がるelbログをlambdaでelasticsearchに流しているのに、last 15 minutesのログが表示されなかった。
Todayで見ると、なぜか日本時間AM9時からログが入ってなかった(AM10時実行時)。

lambdaの実行ログを見るとエラーが

403エラー?えっ認証エラー・・?

{
   "error": "ClusterBlockException[blocked by: [FORBIDDEN/8/index write (api)];]",
   "status": 403
}

エラー内容をgoogle先生に聞いても英語の記事ばっか・・

英語が出来なくてごめんなさい。

getは出来るんだけどね・・

getでは今まで通りレスポンスが返ってくる。
サーバーはちゃんと動いているみたい。

そんなときはelasticsearchのFreeStrageSpaceを確認しよう

awsコンソールのelasticsearchの該当ドメイン、またはcloudwatchの該当ドメインから見ることが出来ます。
この値が0になっていないですか?
0になっていたら(エラーメッセージは不自然ですが)getができてpostが出来ないのは理由がつきました。

解決方法

用件によってアプローチ方法は異なりますね。とりあえず列挙します。

elasticsearchの容量を上げる

インスタンスタイプを上げる方法と、EBSを追加する方法があります。これは排他ではないので、両方行う事が出来ます。

容量を節約する

elasticsearchにはデータの保存期間を設定することができます。
データの利用用途から、一週間で破棄するとか、一日で破棄するとか適切に設定出来ると良いですね。

FreeStrageSpaceにアラートを仕込む

cloudwatchで簡単に仕込めるはずです。
対応できる時間を考慮してアラートのしきい値を決めましょう。

適切にデータを送れるようになったね!

私の場合はEBSを追加して、なおかつTTLを一週間に設定しました。
無事に・・・

{
  "_index":"logs",
  "_type":"elb",
  "_id":"xxxxxxxx",
  "_version":1,
  "created":true
}

再度、ログがインポートされるようになりました!やったね!