Amazon Elasticsearch Service でデータが保存されなくなった話 [cloudpack OSAKA blog]

ナスです。

またまた Elasticsearch の話です。今回は Amazon Elasticsearch Service にデータが保存されなくなった話です。Amazon 特有の話なのかそうでないのかわかりませんが、実際に起こったので書いておきます。

気がついたら何も保存されていなかった

初期構築を終えて数日運用した後に Elasticsearch Service の様子を見てみたら、Indices タブにあるべきインデックス名が全く出ていませんでした。クラスタ数は 1 で設定してあるので、ステータスは常に Yellow だったので、これが原因とは思えない。かといってストレージの空きはわりとある。って状況で、最初はなかなか原因がわかりませんでした。

Monitoring タブで見れるグラフがなんかおかしい

Elasticsearch Service のグラフを見ていると、なんか気になる形を発見。Write IOPS が 0 だ…

この状況を基にいろいろ調べたら、このドキュメントが出てきました。
AWS サービスエラー処理 - Amazon Elasticsearch Service

なんかメモリくさいな…　と思って、CloudWatch で Write IOPS と JVMMemoryPressure のメトリクスを見るとこうなってました。

JVMMemoryPressure が92,93% あたりを超えると Write IOPS が 0 になり、JVMMemoryPressure が下がると同時に Write IOPS も増えていました。

原因は？

ドキュメントには、

t2 インスタンスでは、[JVMMemoryPressure] メトリクスが 92% を超えた場合、クラスターが赤の状態になるのを防ぐため、Amazon ES はすべての書き込みオペレーションをブロックすることによる保護メカニズムをトリガーします。

と書いてありますが、この環境ではデフォルトの m4.large を使っていますので、どうやら t2 だけに限らないっぽいです。もしかしたらデフォルトのインスタンスサイズ＆ t2 がこれに引っかかるという可能性もあります。（他のインスタンスタイプでは試せてないのでわかりません

どう対処したのか？

今回は、データが多すぎてメモリも多く使われたのだと仮定して、先日書いた↓の対応を行いました。
nasrinjp1.hatenablog.com

不要なデータを消した直後から、JVMMemoryPressure も下がり、無事に Write IOPS もガンガン上がり始め、ようやくデータが保存されていきました。

他には、クラスタ数を増やす、インスタンスのサイズをあげる、等の選択肢もありますが、不要なデータがたまりすぎている状況なら素直に不要データを削除するのがいいと思います。後は、JVM 関連のパラメータ調整くらいですかね。

Elasticsearch Service はマネージドサービスですが、ちゃんと使い方や特性を理解した上で運用しないと痛い目にあうなと思いました。マネージドサービス＝何も気にしなくても運用できる、ではないことを再認識させられました。

Nagios で Ubuntu を監視しようとしたらハマった [cloudpack OSAKA blog]

ナスです。

Nagios を使って Ubuntu Server を何台か監視しようとしたんですが、その時にツラい目に遭ったのでみなさんに共有します。

やりたかったこと

Nagios サーバから、Ubuntu Server に入れた NRPE に対して引数をつけてメトリクスを収集したい。ただそれだけ。

NRPE の設定

他にもいっぱいコマンド定義しましたが、とりあえず簡単に説明できる tcp ポートのチェックを例に。
設定ファイル：/etc/nagios/nrpe.cfg

allowed_hosts=127.0.0.1,<ip_address>
dont_blame_nrpe=1
command[check_tcp]=/usr/lib/nagios/plugins/check_tcp -p $ARG1$

Nagios サーバから確認してみると

# /usr/lib64/nagios/plugins/check_nrpe -H <ip_address>
NRPE v2.15

よし、通るな。

# /usr/lib64/nagios/plugins/check_nrpe -H <ip_address> -c check_tcp -a 80
CHECK_NRPE: Received 0 bytes from daemon.  Check the remote server logs for error messages.

え、え？　なんで？？

Google で検索しまくった結果

なんかバグレポートが見つかりました。
#756479 - nagios-nrpe-server: Ignores dont_blame_nrpe=1 - Debian Bug report logs

NRPE が引数つきの問い合わせに対応できなくなったようです。 詳細な経緯までは追ってませんが、-enable-command-args オプションを外してパッケージングするようになったみたいで、今後も復活することはないようです。

対処内容

引数を使わずに、NRPE 側で固定値を書きました…

allowed_hosts=127.0.0.1,<ip_address>
dont_blame_nrpe=1
command[check_tcp]=/usr/lib/nagios/plugins/check_tcp -p 80

たまたま Ubuntu Server は数台だけだったのでよかったですが、これがたくさんあったらもう最悪でした。 -enable-command-args オプションをつけてパッケージを作ればいいのですが、できればそんなことはしたくなかったので、今回はこれで落ち着きました。

普段 Amazon Linux とか CentOS しか触らないのでレアケースなんですが、もしかしたら Ubuntu 使うケースが増えてくるかもしれないので、誰かのお役に立てれば嬉しいです。

Zabbix とかならこんなことにはならなかったのかなぁ…