コネヒト開発者ブログ

コネヒト開発者ブログ

「サービス落ちたら電話で通知」を10分で実現・本番に投入する(Pingdom + Pagerduty)

こんにちは、徐々に涼しくなってきた金城@o0h_です。
最近は セブン-イレブンのアボカドとツナのチョップドサラダを食べる時にちょっと幸せを感じています。タンパク質が豊富なアボカドが美味しく摂れるのも素敵です。

さて、突然ですが皆様に於かれましては「提供しているサービスの監視」どうしていますか？
監視対象や項目・方法は色々あれど、運営として最低限防がなければいけないのは「サービスが止まっていた、利用できなくなっていた」という状況でしょうか。うっ！落ちている！！ 怖いですね。
死活監視。定期的に「対象の外部からアクセスして」「レスポンスを返せる」というチェックによって、アプリケーションやらデータベースやらネットワークやら・・・というあらゆるレイヤーを一気通貫で「無事そうか」を確認する。
これが通れば「最低限動いている」、もしだめなら・・・いち早く通知を受け取りたい！

コネヒトでは、お盆休みを迎えるのを機に、監視方法を刷新し新システムの導入をしました。
実際の監視から、Slackや電話でプッシュするアラートの発報まで、とてもスムーズに稼働までもっていくことができたのでした。今回はそんな便利サービス紹介させてください。

死活監視を行うPingdom と通知・エスカレーションを行うPagerDuty です。 f:id:o0h:20131109145130j:plain

クリティカルなものだから、なるべく大きなものに巻かれたい

先にちらっと述べましたように、死活監視はサービス運営者にとって、いってみれば 最後の砦 となるわけです。
行う内容としては非常に単純ですが・・・例えば定期的にpingを打つだけでも良いですし、もう少し手の込んだ事をするとしてもせいぜい「正規表現でコンテンツの正否をチェックする」とか。極端な話、Google Apps Script等の非常にお手軽なツールで雑に書いても監視機能は満たせる気がします。
ただし、ちょちょっと書いたお手軽ツールだと(主観といえば主観ですが)ちょっと背中を預けるには心もとない感じがします。
他方で、Nagios等を使って手の届くところでしっかりやる！という選択肢もあると思います。が、自前のシステムに置くことにより「監視の監視をどうしよう・・・」という不安が生じてきます。
また、今回は「電話など、強めのアラートを打ちたい！」というのをマスト項目に挙げていました。これも色々なサービスをつなぎあわせてAPIキックして・・・とやれば色々な選択肢がありますが、「自分でアプリケーション書きたくない・・」のです。

これらの わがまま 要件を満たす手段を、「しっかりやっていそうで」「最低限の設定や運用等がべらぼうにシンプルそう」という条件で調査を行いました。

駆け足でPingdom × PagerDuty設定を行ってみる 〜電話がなるところまで〜

Pingdomとは

まずは死活監視を行うSaasである「Pingdom」です。 特化型のツールということもあり、導入コストが非常に低い(基礎的な設定がすぐに完了する、専任でなくても理解できるシンプルな操作画面)点が評価ポイントでした。
世界中に監視サーバーを持っていて、ダウンが記録された際の記録やSMS通知までをワンストップで担ってくれます。

登録

https://www.pingdom.com/signup/からユーザー登録を行います

  1. ユーザー登録(1,2分)
  2. 監視対象とするホストを設定(1分)

くらいで最低限のセットアップは完了です。
・・・もはや、あまり説明する内容もないですね。。
(これだけですとアラート等の設定が行われていませんが、それはPagerDutyの設定を完了してから改めて行います。)

この時点で、「Pingdomの管理するサーバー群から、定期的に稼働状況を監視。Up/Downといった状況について記録する」という状態がもう実現されています (！)
SMSやメールでの通知であればこれでOKです。あるいは、Slackに繋ぎこむのもほとんど手間なく実現できます。もし通知手段はそれだけで十分だ〜ということであれば、期待通りに動いてくれることでしょう。

本エントリーにおいては少々蛇足ですが、「Basic Checks > Uptime」に並んでいる監視対象のサイト名をクリックすると詳細な設定も可能です。

f:id:o0h:20160920181726p:plain

  • チェックする間隔
    • デフォルトだと1分毎
  • チェック対象のURL
  • アクセス元地域
    • デフォルトだと北米/欧州になっているので、日本付近のサーバーを監視するのであれば Asia Pacific の選択がオススメです
  • アラート先
    • モニタリングが転けた場合に通知する連絡先(Pingdomアカウント)
  • アラートするタイミング、リマインドするタイミング
    • 転けてから◯分後にアラート→その後、状況が◯分変わらなかったら再アラート！といった
  • 詳細な監視条件
    • アクセスしたURLに特定の文字列が含まれているか？などを、判定の条件として設定可能
    • BASIC認証の設定
    • アクセス時のUserAgent設定、など

PagerDuty

Pingdomと組み合わせて利用することにしたのが、PagerDutyです。
エスカレーションを管理してくれるサービスで、その一貫での通知機能の豊富さ・柔軟さや多彩なサービスとのインテグレーションが容易である点が決め手でした。
https://www.pagerduty.com/integrations/をご覧いただくと、実に多彩なサービスへの対応を謳っていることが見て取れるかと思います。*1
今回我々が欲していた電話での通知を始め、メールやSlackはもちろん専用モバイルアプリでのPUSH通知や状態確認・アップデートにも対応しています！

PagerDutyへのサインアップとPingdomの連携

PagerDutyへのサインアップ

https://signup.pagerduty.com/accounts/newからサインアップを行います。

  1. PagerDutyにサインアップすると、早速「連携するサービスの選択」画面に進みます。
  2. ここで「Pingdom email」を選択して下さい f:id:o0h:20160920204923p:plain
  3. 通知の確認をしたあと、「エスカレーションポリシー」の設定に移ります。
    「問題*2発生を検知してから、何分以内に対応しますか / それを満たさなかった場合に1つ高いレベルのアラートを打つことにします」の設定です。 *3
    ひとまずSecondary〜の設定は今は必要ありません。 f:id:o0h:20160920205156p:plain

Pingdomとの連携

アカウントの初期登録が終わったので、ここから「Pingdomとの連携」に入ります。

  1. ダッシュボード上部の「Services」より、(先程登録だけした)Pingdom Emailの「Integration」列のリンクをクリックします f:id:o0h:20160920205603p:plain
    そこに表示されている「Integration Email」をコピーして下さい。
  2. このアドレスに送信されたメールを「問題発生通知」として受理し、PagerDutyが捌く流れになります。
  3. そこで、Pindom側の「Down検知時の通知先」として、このアドレスを登録してしまおうという寸法です
  4. Pingdomを開き、Settings -> Users -> Add New Userへと進みます。ここに、「Email」として先程取得したアドレスを入力してください。「Create Contact」したら設定完了です！ f:id:o0h:20160920210148p:plain

問題発生時に電話での通知を受け取る

さて、最終段階です。 通知に関する設定を行いましょう。
PagerDutyの場合、「どのタイミングで」「どのチャネルに」通知するかはユーザーごとの設定に依存します。 例えば、「問題が発生したら即時にアプリに通知してね*4」→「5分経ったらメールしてね」→「10分経っても音沙汰無かったら電話！*5」といった具合です。

画面右上のユーザーアイコンをクリック→「My Profile」をクリック → 「Notification Rules」へと進みます。 f:id:o0h:20160920210731p:plain ここで、「Add Notification Rule」してください。

これだけで、「サービスがダウンしたら担当者に自動的に電話が来る」仕組みが出来上がりました！

最後に(雑多なこと)

実際に導入してみて

「使えるものは使う」「本当にやるべき事にリソースを割く」というのは小さいチームでは特に重要なことかと思いますが、外部サービスで便利なものを扱えるのは嬉しいな！と改めて感じました。料金こそかかるものの、これほどの重要な対応を非常にストレス少なくカバーできることを考えれば十分な価値があると結論しています。

電話での通知について

「がいこくのでんわばんごうから、えいごででんわがきて、とってもかっこいいなとおもいました」という感想なのですが、導入以後に特に大きなトラブルにも見舞われておらず・・実際にはテスト的にアラート飛ばさせた以外は、体験しておりません。善事哉。
ただし、そのテスト作動をさせた時には相当なインパクトを感じました。

料金体系など

どちらのサービスも料金プランに応じて「利用する人数」に対する制限があります。 * Pingdomの場合、「管理画面に入れるアカウント」「通知を受け取るのみのアカウント」というように権限が分かれています。 * PagerDutyの場合、「人数×利用プラン」での課金となります。ので、「通知をマストで受け取らなければならない人」を登録した上で、サブメンバーはSlack上から対応・・というような運用もあるかもしれません。

もちろん、人数だけでなく利用可能な機能等もプランごとに差がありますのでご確認下さいませ。

導入にあたって参考にしたリンク

今回のエントリーは「最短攻略！」的な手順の説明に留めたので、実際の活用方法や設定項目については触れませんでした。
特にPagerDutyは高機能なインシデント管理サービスであり、しっかり使おうと思うと細かくいじりこむ事が可能です。それに際して、分かりにくい概念や聞きなれない単語も出てくるかも知れません。

実際に導入に際して調査していく中で、私自身が参考にさせていただいた文献を紹介することで諸々の説明の代わりとさせてください。
エンジニアの皆様が安心して眠れる夜の実現に、少しでも助けになれば。
※一部、公開されてから日数の経過しているものもありますので・・・ご注意下さい。

個人的にももっと使い込む余地があるように感じているので、継続的に研究・試行錯誤していきたいところです。

それでは、よい週末を！(´,,･ω･,,`)

*1:実際に、コネヒトではPingdomだけでなくAWS CloudWatchも繋ぎこんでいます

*2:インシデントと呼ばれます

*3:PagerDutyの中では、インシデントの状態にはいくつかの段階が設けられています。「未対応(triggered)」「認識している(acknowledged)」「解決済み(resolved)」です。これらの状態は、「triggerdのまま、同じアラートが◯分間続いたら自動的に解決済みにする」「解決済みにならず、◯分間続いたらアサインを戻す」といったエスカレーションも設定可能です

*4:スマホアプリがあるので、入手してアカウントのヒモ付を行ってください。その時点で、選択肢にアプリが現れます。

*5:日本国内の場合、1番下のプランですと電話での通知には対応していませんのでご注意を！