はじめに
Neptune.ioというスタートアップのクラウドサービスが、運用エンジニアにとって魅力的な言葉が踊っていて試してみたかった。
Don't wake up your engineers to fix alerts. Use Neptune to fix them automatically
「問題改善のために起こされることはありません。Neptuneが自動的に修復します」
仕事納めの今日、検証する時間があったのでMackerelとの連携を試してみました。
作るもの
オンプレって言いながらVagrantです。すみません。
今回は2台のノードを使って、
- ノード1が疎通NGになったら
- mackerelにNGを検知させてNeptune.ioにWebhookを送信し
- Neptuneのエージェント経由でアクションを行い
- ノード2がノード1の持っているエイリアスアドレス(VIP)を引き継ぐ
という動作をさせてみます。
試験的実装
はじめにお断り：
本当に動作試験しただけなので、この実装を真似ないようにしてくださいね。
以下はいつもの口調で・・・・
Neptune.ioアカウント作成
動作確認なのでFreeアカウントでよいかと。
Neptune.ioエージェントインストール
『Integrations』の『Infrastracture Integration』より、
『ON PREMISE SERVERS』を選択する。
インストール用bashコマンドが表示されるので、対象サーバーにてそのままコピペで打とう。今回は2台のサーバーで実行。
NAGENT_USER="neptuneioagent" NEPTUNEIO_KEY="xxxx" bash -c "$(curl -sS -L https://raw.githubusercontent.com/neptuneio/nagent/prod/src/install_nagent.sh)"
2台のサーバーが登録された。
このneptuneioagentユーザーによって障害対応のアクションが自動実行されるようになる。
アグレッシブすぎるのでおすすめはしないが、対象サーバーにはこんなsudoersを作っておこう。（本当は必要なコマンドだけ解放するのが良い）
Defaults:neptuneioagent !requiretty
neptuneioagent ALL=(ALL) NOPASSWD:ALL
プロセス再起動とかを実施させたければ、ulimitsとかも気をつける必要がある。
Rule設定
それでは、障害発生時のルールを作っていく。
Rules→Webhooksを選択、『Create Rule』画面に遷移する。
Triggerに「Webhook」を選択。
Whitelisted IPを選択してmackerelのソースIPアドレスを設定する。（と言いたいところだが、ネットワーク指定に対応していないのでやむなく無視した）
そして、EXECUTE_SCRIPTアクションを設定する。
『Select hosts』欄にアクションを実行するホストを指定する。今回はノード2を指定した。
Runbook欄に復旧アクションを行うbashスクリプトを記載しよう。
今回はIPアドレスを付けるスクリプトを作ってみた。（あまり一般的な例じゃないなぁｗ）
# Write your script here
/bin/ping -c 3 192.168.200.201
if [ $? -ne 0 ]; then
/sbin/ip address add 192.168.200.201/32 dev eth1
fi
mackerel側設定
先ほどのRule設定が終わると、このようにWebhook用Trigger URLが発行される。
このcurlの中のURLをコピーしよう。
mackerel側にアラート設定を入れる。
Webhook通知によって、Neptune.ioにアラートを通知する。
URLに関してはcurlに書かれているものをコピーすれば良い。
このままだと何のサーバーが落ちてもWebhookが送られてしまうので、mackerel側にてうまくグループを整理する必要がある。そこについては割愛する。
実験
ノード1を落としてみる。
[node1] $ shutdown -h 0
しばらく経つとmackerelによってConnectionErrorが通知される。
その結果、Webhookが突つかれたことが確認できる。
ノード2を見てみよう。実行されていることが確認できる。
戻すときはどうするんだ？
って疑問が湧いてきたけれど、切り戻しなんてのは手作業でもいいか。
感想
Neptune.ioは非常に高機能でモダンで、運用管理者にとってわくわくできるサービスですね。
一方で、現在のmackerelの監視通知設計とは合わない印象が強かったです。
というのも、
- Neptune.ioは「 1アラート : 1 Webhook URL 」を期待している
- mackerelはサービスあるいはOrganization(≒全システム)に 共通で通知先Webhookを設定 する
といった理由で、複雑な通知設計を考える必要があるからです。
また、アラートの内容を変数として取得することが、JSONデータの構造の違い(mackerel, Neptune.io)によって現状ではできません。
※ Neptune.ioでは、MetaDataという構造体で渡す必要がある
そのため、サービス状況による条件分岐を考慮した処理を実装することは出来ません。
これらの問題はmackerelに限った話ではなく、多くのクラウド系サービスに言えることですね。
NagiosやZabbixを自前で用意している環境ではもう少し柔軟にできるでしょう。
試行錯誤してみようと思います。