mackerel-agent の action オプションの活用例を考えてみた
Posted on
先日のアップデートで mackerel-agent に action オプションが追加されました。
テキストログ監視をおこなう
check-log
や、プロセス監視をおこなうcheck-procs
など、さまざまな観点での監視がおこなえる Mackerel のチェック監視ですが、今週のアップデートにより、チェック監視の実行後、その結果をもとに任意のコマンドを実行できるようになりました。
たとえばプロセス監視を行う check-procs
プラグインと組み合わせれば、監視対象のプロセスが落ちたら自動的に再起動するということができます。 freee でも非同期ワーカーのプロセス監視に活用しています。
これまでは「アラート通知 → 検知 → 対応」という流れでしたが、軽微なアラートならこのオペレーションを自動化できます。
action オプションの活用例
せっかくの便利機能なので action オプションのさらなる活用例を考えて(妄想して?)みました。
- スワップアウトが発生したら ELB から安全に切り離す
- OOM Killer に殺される前に ELB から切り離して障害が広がるのを防ぐ
- ストレージの空きが少なくなってきたら EBS ボリュームを自ら増やす
- Amazon Aurora のようにストレージの空きを気にする必要がなくなる
- CPU 負荷が低いときは Auto Scaling Group から自ら抜けて shutdown する
- CloudWatch よりも細かい粒度でスケールインできそう
- ログに怪しい文字列が出現したサーバを ELB から切り離す
- JVM の Full GC が頻発していることを検知したら ELB から切り離して全体のパフォーマンス劣化を防ぐ
- CPU 負荷が低いときはこっそりビットコインをマイニングする
- 冗談です
実現するには自分でチェックプラグインを書く必要がありますが、チェックプラグインの仕様は 0, 1, 2 のいずれかの終了ステータスを返すだけなので、言語も問わず簡単に書けます。
たとえば、スワップアウトを検知するチェックプラグインはシェルスクリプトでも書けます。
#!/bin/bash
swap_used=$(free -m | grep Swap: | awk '{ print $3 }')
critical_threshold=500
warning_threshold=250
if [ ${swap_used} -ge ${critical_threshold} ]; then
exit 2 # CRITICAL
elif [ ${swap_used} -ge ${warning_threshold} ]; then
exit 1 # WARNING
else
exit 0 # OK
fi
スワップメモリが 250 MB 以上で Warning、500 MB 以上で Critical です。
AWS の操作には AWS CLI が使えるので、action オプションも柔軟に書けると思います。
まとめ
活用例で示したアイデアは自力でやろうと思えばできたことですが、mackerel-agent の仕組みに乗っかっておくとスマートに実現できますね。アイデア次第でいろいろと運用を楽にできそうです。