【cloudpack 大阪 BLOG】Datadog始めました(DatadogでAWSのインスタンスを監視してみる)
cloudpackにもDatadogの波が訪れようとしているようで
BLOGを書いたシンジさんからDatadogすげーんで今からデモ見せるんで
試してみてくださいとデモをしてもらったのですが、
これはスゲーを連発したこのDatadogは、
よくよく考えてみたら2年ぐらい前のAWS re:Inventの時？に確か
ブースでデモを見ていて、
その時もスゲーを連発していたらなんかグッズを貰ってきたのですが、
記憶が封印されてました・・・汗
その時はMSPをするなんて全く認識していなかったので、
インフラの監視がどんだけ大変か？を知る由も
無かったのですがMSPをやるようになり、
自分で監視設定もやったりするようになってから再度シンジさんの
デモを見るとこれは本当にヤバいって感じになりました。
監視対象のインフラの過去から現在の状況をDatadogで収集、
そして現在発生したインシデントをpagerdutyで管理・・・という
バラ色？の未来の為にとりあえず自分のアカウントで試してみます。
ちなみにAWSコンソール上のEC2はこんな感じ(ELBも登録していますが記載しません)
とりあえずはDatadogで使うIAMの作成。
AWSコンソールに入ってIAMを作成します。
IAMで必要なJSONは下記に記載していますので
Datadog Docs - Datadog-AWS Cloudwatch Integration
ここのをぺたっと貼付けます。
そしてDatadogにログインし(5インスタンス以下なら無料ですので
無料アカウントで試してみる事をお勧めします)ログイン後に
integrationsを選択し、
沢山並んでいるDATADOGで使えるサービスの中から
のAvailableをクリックし有効化を行います。有効化したら
となっているので、フォーカスをあてると
とUIが変わりますので、Configureを選択すると
が出てくるので、Access Key IDとSecret Access Keyを入力し
で監視対象を選択し、Update Configurationをクリックすると反映され、少し時間を置くと、
とDatadog上にインスタンスのリストが表示され、
な情報が取得できるようになりました。
本当に運用にのせるには、上記の設定だけではすまないですし、
Datadogの本当の良さにはたどり着きませんが、
とりあえずDatadogを試すのは本当に簡単なので、
一度試してみてはいかがでしょうか？
【cloudpack 大阪 BLOG】pagerduty始めました・・・[イレギュラーな事態が発生した時の対応方法その②]
ちょっと期間が空きましたが、その②です。
今日もメンバーから問い合わせがきて自分で対応したのですが、
そろそろMSPメンバーにpagerdutyの運用の移管も
しなければいけないなーと思っていたので、問い合わせ内容も
BLOGに書いて、cloudpackのWIKIからリンクするようにしておきますw
今回のケースは急なシフトの交代をどうpagerdutyで対応するかを記載します。
ちなみに落とし穴もあるのでそれも書いておきます。
メニューからSchedulesを選択し
変更したいスケジュールを確認。
今回は7/30のシフトを比企からMSP大阪のエース廣山さんに変更なので
7/30の比企のシフトをクリック。
上書き画面が出ます。Personの変更を行います(Time Zoneや開始と終了は変更しないでください(範囲内だとOKですが範囲を超えると・・・BLOGの最後に書きます汗))。
Personを廣山さんに変更しCreate Overrideをクリック
無事に廣山さんに変更できました。以上です。スゴく簡単にできます。
ちなみに想像と違う挙動をしてしまうケースです(操作の結果的にはあっていると思いますが、勘違いしやすいところなので記載します。)
8/1から8/12日の19時までを廣山さんに変更したい時ですが、下記のようにまとめて
行うと・・・
下記のようになります汗。必ず一つ一つ選択してください汗
pagerdutyの時間や期間設定はちょっと大雑把な部分があるので、
うまく操作してくださいw。
【cloudpack 大阪 BLOG】pagerduty始めました・・・[イレギュラーな事態が発生した時の対応方法その①]
pagerdutyによりアラートに対する見える化(発生・対応中・クローズ・分析)が
出来るようになるわけですが、
pagerdutyに関係なくサービスとしてイレギュラーな事は日々現場で発生します。
pagerdutyに関連する事象だと管理対象であるサービスの急なメンテナンスへの対応やアラート対応の担当者の急な予定変更etc
今回はそんなイレギュラーな対応をpagerdutyでどうオペレーションするのか記載します。
サービスの急なメンテナンス
pagerdutyはアラートをインシデントとして管理する為に、サービスのメンテナンス時などで監視サーバー(nagiosやsensu etc)でアラート通知をOFFできない場合に、
pagerduty側で通知受付を止める事が出来ます。
通知を放置していると担当者によるクローズの操作も必要になりますし、後で分析したい場合のノイズになるので、メンテナンスをちゃんと認識して対応しておく必要があります。
Maintenanceに対する方法は3種類あり、いずれも簡単な操作で対応は可能です。
まず対象のサービスを選択して詳細画面を表示します(編集画面への遷移は不要です)
画面右側のUIに
•Schedule new maintenance
•Disable this service
•Immdeiate Maintenance
があり、そのどれか何れかを選択する事により、Maintenance状況にサービスを変更できます。
Schedule new maintenance
Maintenanceを時間で設定する事が可能です。
※Schedule new maintenanceを複数回操作する事により、Maintenance期間を複数期間設定する事も可能です。
Immdeiate Maintenance
5 min•15 min•30 min•60 minから1clickで選んだ時間内でMaintenance状態に出来ます。
なおSchedule new maintenance/Disable this serviceで時間指定をしてMaintenanceに
解除する場合は、
Maintenance中に上記UIが右側に表示されますので
editを選択して、Edit Maintenance Windowを開き
の
End this maintenance window now
を押下する事により、Maintenanceを解除できます。
※上記UIからMaintenance時間の変更も可能です。
Disable this service
Maintenance期間設定無しにいきなり止めます。
Enable this serviceですぐに再開できるので、Maintenance期間が未定な場合に使います。
このようにpagerdutyは簡単にMaintenance状態に設定する事が可能です。
もう一つのイレギュラー対応は次回のブログで。
【cloudpack 大阪 BLOG】pagerduty始めました・・・[いきなりの制約回避編 スケジュールとエスカレーションポリシーのハマりどころ]
いきなりですが、先に制約による課題と解決策を記載しておきます。
※この課題の数字で導入を諦めるかたもいるので、まず書かさせて頂きます。
前回の記事で、エスカレーションポリシーの階層で設定できるスケジュールは
10個ですってのを記載してます。
通知される担当が最大10人までの場合だと、1スケジュール=1名で設定して、
10スケジュール作成してエスカレーションポリシーにセットする事で対応は可能です・・・が、24時間・365日でかつ数多くのシステムを預かっているcloudpackのような
規模だと、そのスケジュール作成のルールでは簡単にオーバーフローしてしまいます汗。
逃げの手としてエスカレーションポリシーの階層で制御する事も可能ですが普通は
①階層目
監視メンバーA・監視メンバーB・監視メンバーC
②階層目
監視メンバーA・監視メンバーB・監視メンバーC＋リーダー層
③階層目
監視メンバーA・監視メンバーB・監視メンバーC＋リーダー層＋責任者
とエスカレーションのランクが上がる毎に通知されるメンバーが増えていきます。
またメンバーも1週間に二日間の休みがあるので、スケジュールには二日間の休みを
設定する必要もあり、エスカレーションポリシーの制約からスケジュールを複数のメンバーで使い回す必要がありますが、pagerdutyは何とUIの設定からだと１週間のうち、
二日間は休みと言う当たり前の設定を”簡単”に設定する方法がありません・・・汗。
例えば7月7日のスケジュールAに担当のX1さんを設定すると、スケジュールAには
X1さんを週間か毎日の設定は出来ますが、その日付から未来総てX1さんは休みなしで
設定されてしまいます汗。
①7月7日〜7月10日がX1さん
②7月11日〜7月12日がX2さん
③7月13日〜7月15日がX1さん
という設定をする為には、①を入力した後に7月11日開始で②の設定をして
7月13日開始で③の入力を個別にする必要があります。
ちなみに間違って②を再度入力するともれなく未来日付が②で上書きされて③の日程が
消えてしまいます・・・
UI的には、スケジュールで設定されている担当の方をクリックする
とスケジュールを別の担当者に設定するOverride機能
があるのですが、スケジュールがドラスティックに変わったり、そもそも沢山のメンバーをいちいち入力するのって運用として破綻しているので、比企はgoogle spred seetに
スケジュールを記載したものをgoogle apps scriptでpagerdutyのAPIをコールするように
落とし込むスクリプトを作成し対応しました・・・
※上記には記載していませんが、スケジュールの使い回しのパターンとして、
違う時間帯のメンバーを一つのスケジュールに登録する事も出来ますが、
通常のUIでそれをやるのはさらに難易度が高いのでAPI呼び出しにより自動化を進めたほうが、後の運用コストを考えても絶対に楽です。
なお、いつもならここでコードもはっつけるところなのですが、cloudpackの運用は
複雑なので、汎用性もありませんし、汎用性のあるコードも書けますが、それは現状本筋ではないので、導入される方は自前でお願いしますw
APIのリファレンスは下記
cloudpackでは表でスケジュールを管理しており、それをpagerdutyのスケジュールだけの運用に置き換えようと思いましたが、スケジュールを作成する人にpagerdutyのUIで
作ってと言うと間違いなく発狂するぐらい、スケジュール機能は最低限の事しか
現状は出来ないので、運用を考えた場合に是非API呼び出しでの自動化の実装の工数は考えてください。
他にも同業他社で必要な実際の課題に対する運用のノウハウもあったりしますが、
さすがにそこはピンポイントすぎるので開示せずに、汎用的なノウハウとかを
書いて行きたいと思います。
【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の世界へ
