【cloudpack 大阪 BLOG】pagerduty始めました・・・[説明編]
cloudpack大阪は開発を行えるメンバーがインフラエンジニアやっているので
ちょこちょこMSPのIT化を進めています。
そいいう活動が徐々に認知されるようになり、
cloudpack 大阪 BLOGでもたまにキーワードが出てきますが
pagerdutyをcloudpackで導入するのを比企のほうで担当しました(
こんなに大規模で沢山のトラフィックでpagerdutyで導入するのは
事例としてはあまりないような気がします)。
何回にわたるかわかりませんが汗、pagerdutyの説明から導入・運用・課題などを記載出来ればと思います。
pagerdutyとは監視サーバーからくるアラートをインシデントとして
pagerdutyで受け付けて、スケジューリングされた監視しているメンバーに
インシデントを配信し、
•Acknowledged(認め、操作した監視メンバーにアサインする)
•Resolved(解決済み。Resolvedを選択するとインシデントはすでに解決した扱いとなる)
する事により、インシデント(アラート)を管理出来るシステムです。
これにより、監視メンバーが複数人でいても
同じインシデントを対応するような状況がなくなり、
スケジュールとエスカレーションポリシーで設定された担当にしか
通知が飛ばずに、他のメンバーが別の内容に集中する事が可能となります。
特に強力な機能がスケジュールとエスカレーションポリシーです。
スケジュールは担当者の日程と時間を設定する事により、
通知する日付や時間を制限する事が出来ます。
なので、スケジュールで○日の10時〜19時と設定しておくと
それ以外の日や時間には通知されなくなります。
一つのスケジュールで複数レイヤー(人数)設定できますが、
一つのスケジュールで通知されるのは一人で、
複数人が同じ時間帯にレイヤーで設定されている場合は、
優先順位の一番高いメンバーにしか通知されません。
エスカレーションポリシーは監視するサービス毎に設定し、
階層と通知したいスケジュールを設定しておくと、
まず第一階層のスケジュールの方に通知がとび、
そのメンバーが設定された時間でAcknowledgedやResolvedできないと、
次の階層に自動でエスカレーションします。
なおエスカレーションポリシーの通知先は1階層で最大10です。
もっと通知先を増やしたいとかになってくると色々と考える必要がありますが
そもそもそんなに沢山の相手に通知してどうなるの？って感じで、通知先の運用設計もきちんとした方が良いと思います汗
ちなみに、担当者へのインシデントの通知は、WEB画面・アプリ(ios/Android)・
メール通知がデフォルトですが、pagerdutyでは電話にも通知させる事が出来ますが、
cloudpackでは電話機能が使っていません(監視する対象が多いので、インシデントが
発生したぶんだけ電話とか鳴らすとエラい事になります。ちなみに外人の声でアラートの詳細を読み上げてくれますが、早すぎて正直聞き取れないです汗)。
監視する対象のグループはサービスとしてPagerDutyに登録が可能です。
なお、サービスは各監視システムのplugin
Integration Guides - PagerDuty
や、サービス作成時に"Use our API directly"を選択しweb hookさせる方法、
メールアドレスをPD側で用意して用意されたアドレスにアラートメールを配信して
pagerdutyでインシデントとして受け付ける事が可能です。
※上記はnagiosを選択した場合。
また外部からAPIをコールする事によりプログラマブルな制御が可能
や、各サービスでインシデントが発生した場合に、web hook機能で自前で立てた
サーバーのURLを設定しておく事により、外部のURLを叩いて機能連携させる事も可能です。
インシデントを分析したい場合は、Analyticsを選択すると、各サービスや期間毎で
統計を見る事が出来て、安定しているサービスや、売り上げはいいけど実際は手間が
かかっていて、運用コスト的に悪いサービスなどを出して改善する方向を考える指標になります。
小規模な管理で運用メンバーも少なく、スケジュールなどが複雑でなければ
すぐにでも導入すると効果は高いと思いますが、中規模以上になると色々と設計しないと、破綻してしまいますので、破綻しないようなノウハウも出来れば記載できればと思っています。
複数の監視システムを使って監視しているところは、情報を一つにまとめる事が出来ますので、pagerdutyを巧く活用して頂ければと思います。
日本のサーバー管理者の方は是非pagerdutyの世界へ
