【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の世界へ
Innovation EGG 第４回 『各クラウドの現状とこれから』開催しました
を先週の7月4日に開催しました。
Twitterまとめ
エントリーはキャンセル分含め200名近い登録があったのですが
当日は雨だったののあると思いますが50名近い方がドタキャン涙。
それでも沢山の方に参加して戴き、会場のイノベーションハブは
ちょっとクーラーの効きが弱い状況になりました汗。
今回は各クラウドベンダーの方や企業様からグッズの提供をして頂きました。
※ハンズラボ様・サイボウズ様・さくらインターネット様・KDDIウェブコミュニケーションズ様・google様・構造計画研究所様・セールスフォース様ありがとうございました(順番は提供が決まった順に記載しています)。
今回はクラウドユーザーグループのみ講師の方のみ登壇可能(
これは次のクロスエッグの布石でもあります)で、
沢山のクラウドの話をいっぺんに聴ける＆ユーザーグループからの登壇ですので
利用者側としての本音なども聴けて、よかったのではないかなと思います。
今回は6割以上の方が新規の方のようでイノベーションエッグ的には
各コミュニティの案内役として目的は果たせているのかなとほっと一安心な感じではありました。
オープニングと司会は主催者として比企のほうで今回させて頂きましたが
司会に関しては慣れている人にしてもらったほうが良いなと素直に思いました汗
そんな反省もしながらも本編がスタート
JAWS-UG 大阪からは森さんが登壇。今回はモバイル系のサービスをメインに話をされていました。
ロックオンの三原さんは株式上場した時のサイトのCloud Frontの話をして頂けました。
ものすごく生生しい話だったのか、資料が公開されていませんw
かなり質問も多く非常に参加者の皆様Cloud Frontに興味があるようでした。
Innovation EGG - Innovation EGG 第四回の講師＆内容発表 第５弾は 三原... | Facebook
ウメキタフォースからは山田商店の鈴木さん鈴木商店の山田さんと株式会社TAMの男前の白石さんが登壇。緩い話からのセールスフォースでしたが面白かったです。
JAZ-UGからは亀渕さんが登壇。マイクロソフトの全体の話からMicrosoft Azureの話で
時間が足りないぐらいのボリュームでした。Azureというかこのごろのマイクロソフトは
非常に動きが軽快でエンジニアの心をわしづかみにするものが多いので、比企的には
非常に楽しみです。
kintone Caféからは圧力団体宣言をしている金春さんが登壇。
R3に6月にJOINした池上さんを引き連れていつもの軽快なトークで語って頂けました。
9月に第一回が開催されるTwilioJP-UG 大阪からは新原さんが登壇。
男前・喋り上手・そしてデモで会場の参加者の巻き込むと全く付け入る隙？が
ない登壇でした。
Twilioはデモのインパクトが強く、自分としてはIoTの中で現実的なサービスとして
最もクローズアップされるべきサービスかなと思っています。
日本SoftLayerユーザー会からは常田さんが参戦。
運用面含み非常になまなましいトークでしたが、それを面白く伝えてくれて会場の評判は非常によかったでした。
GCPUGからは吉積さんが参戦。GAE話からGCAの話・Big Queryの話などをして頂けました。GAEは比企的にも個人的な思い入れが強いサービスなので、色々とおもいかえすものがありました。
とりを勤めるのはSky株式会社のエンジニアとして昼間働き翻訳も副業でやっている
玉川竜司さん。
非常に忙しいところを、Big Queryの話と、これからのクラウドはこうなるよね？って話をして頂きました。
Google Big Query from 玉川 竜司
そして熱気さめやらぬまま、懇親会のスタート。
50名を超える方が参加して頂きました。
司会の池上さんはコスプレで参戦w
LTは今年の6月に電撃でハンズラボに入社したJAWS-UGの女帝 青木さんからのスタート
懇親会LTは飛び入り野方も含め12人の方が登壇。
そしてTwilioからエバンジェリストの宋さんがトリで、Twilioによる電話を使った抽選会。
そして景品はTwilioだけではなくSendGridのノートやフリスビーを中井さんが提供してくれました。
こういうクラウド同士でのコラボもイノベーションエッグならではな感じですね。
そして懇親会は集合写真をとって無事に終了しました。
今回は懇親会でお酒が余ったのと思いのほか食べ物が早くなくなった(結構買っていたのですが汗)以外は予定外の事もおこらず、運営メンバーの方がかなりがんばって頂けたからこその結果なのかなと思いました。
今年中にもう一回イノベーションエッグ(IoTメインのやつ)を開催して、
来年にクロスエッグも実施する予定です。
イノベーションエッグは関西のコミュニティが盛り上がってほしいとの想いで
運営していますので、今までイノベーションエッグで登壇されてないコミュニティの方も
是非今後、ご登壇して頂ければと思います。
※比企まで是非連絡ください。
それでは次回のイノベーションエッグでお会いしましょう。
【cloudpack 大阪 BLOG】Google Apps ScriptからAmazon API Gateway経由でLambdaをコールしてSlackに投稿する
本当のタイトルは
「PagerDutyのWeb HookからAmazon API Gateway経由でLambdaをコールしてSlackに投稿する」
だったんですが、
なぜかPagerDutyのWeb Hookからcallしてくれないので
とりあえず現状動いているものをBlogに書きます。
LambdaがAmazon API Gatewayという新しい相棒を携えて、
ついにWEB APIとして使えるようになりました。
http://aws.typepad.com/aws_japan/2015/07/amazon-api-gateway-build-and-run-scalable-application-backends.html
Amazon API GatewayはLambdaのおまけ?かというと全然そうではなく、Amazon API Gateway自体が非常に可能性のあるものとなっていますが
今回はMSPのIT見える化に使う為に、Amazon API Gatewayの詳細はおいておきます。
まず下準備としてLamdaで実行するnode.jsのプロジェクトを用意します(macでやっています。node.jsのインストールは別でお願いします(簡単です))。
macのコンソールで下記を実施
$ mkdir lambdatest
$ cd lambdatest
$ npm install request
$ vi index.js
index.jsのコードは下記
exports.handler = function(event, context) {
var options = {
url: 'https://hooks.slack.com/services/ここはslackのAPIから払い出されたURLを参照',
headers: {"Accept":"application/json", "Content-Type":"application/json","Authorization":"Basic _authcode_"},body: JSON.stringify({"channel": "#投稿するチャンネル名", "username": "botの名前です", "text": "tessです", "icon_emoji": "好きな絵文字を"} )
};
request.post(options, function(error, response, body){
if (!error && response.statusCode == 200) {
console.log(body);
} else {
console.log('error: '+ response.statusCode);
}
});
};
で上記を保存し、
$ zip -r myfunc.zip index.js node_modules
で、UP用のプロジェクトをzipで固めます。
次はAWS側ですがとりあえず動かす事をメインにしますので、詳細なパラメータは放置しますw
Amazon API GatewayからでもLambdaのどちらからでも作成できますが、今回はAmazon API Gatewayから作成します。
対応しているリージョンを選択しAmazon API Gatewayを選びます
Get Startedを選択し
API nameをつけて
Create Methodを選択し
今回はpostを選択(他のメソッドも選べれます)
Lumbda Functionを選択し
microservice-http-endpointを選択し
Function Nameを入力し
Upload a .ZIP fileで先ほどUPしたファイルをアップします
でLambdaのIAM Roleを選択し
今回はLambdaはAWSの機能を使わないので上記のような感じでロールを作成し
前の画面のnextを選択し
さらにnextを選択
Create Functionを選択し、作成。
作成後に上記の画面が出てくるのでTESTを選択すると下記のような投稿がslackに投稿されれば、Lambda側はとりあえずOKです(ちなみにこのFunctionは実行時にエラー出ますが、とりあえずslackへの投稿が出来ているのでこのままで行きます(また直します))。
ここからは外部公開する為の操作となります。Deploy APIを選択し
Deployします。
上記までで公開できましたので、curlなどで一度確認してみてください。
でGoogle Apps Scriptから
function sendToLambda() {
var r;
try {
var url = "https://Invoke URL:で表示されていたURLをここに";
var data = {"operation": "echo","somekey1": "somevalue1","somekey2": "somevalue2"};//ここは不要ですが元々のdynamoのサンプルを動かしたいとき用に記載しておきます
var payload = JSON.stringify(data);
var headers = {"Accept":"application/json",
"Content-Type":"application/json"
};
var options = { "method" : "POST",
"contentType" : "application/json",
"headers" : headers,
"payload" : payload
};
var response = UrlFetchApp.fetch(url, options);
} catch(e){
var error = e;
r = null
return false;
}
return true;}
で呼び出すと間違っていなければ
が無事表示されます。
ここまででAPIを公開する事ができるようになりました。
LambdaとAmazon API Gatewayにより、インスタンス数などを気にせずに
スケーラブルなAPIを外部に公開する事が可能になります。
今回は紹介できてませんが、Amazon API Gatewayでは
他のAPIサーバーのラッパー(要求や結果を変換する機能？)になる事も出来るようで、
モバイルからの利用や過去のAPIサーバーの再活用など色々と可能性がありそうです。
GAEやAzureが先行して従量課金型のPaaSを出していましたが
早すぎた投入によりインパクトはあまり出なかったですが、
AWSがcloudの普及状況を見ての今回の投入、
利用者のマインドの変化により、これから色々と大きな変化がありそうですね。
【cloudpack 大阪 BLOG】MSPのシステム化について chatworkからslackへのメッセージ転送
hatworkからslackへのメッセージ転送・・・普通やりませんよね汗
ただどっちも使ってるけどslackの方がメインなのでって狭いニーズもあるのでやってみました。
ちなみにこのブログを書いている時点でまだ社内でもこのプログラムの存在は出していません。
とりあえず説明(コードはgoogle apps scriptです)。
下部に記載されているコードを下記のようなサンプルコードで
chatworkでAPIが前回呼び出したチャットのメッセージの差分をslackに通知します。
sendFunction("①slackでgetしたwebhookurl","②chatwork apiで取得したキー","チャットワークのルームID","slackのチャンネル");
<①slackでgetしたwebhookurl>の情報の取得に関しては
https://my.slack.com/services/new/incoming-webhook
でチャンネルを選択し
”Add Incoming WebHooks Integration”ボタンを押下すると
下記のような感じのWebhook URL
https://hooks.slack.com/services/hogehoge/hogehoge/hogehoge
が作成されます。
<②chatwork apiで取得したキー>の情報の取得に関しては
ChatWorkの動作設定の「API発行」タブから取得します。
ちなみにchatworkのAPIのドキュメントは
にありますので、他の実装する時の参考にしてください。
あとは下記のような感じで(エラー処理等は自身で記載願います)
//転送用関数
function sendFunction(slackkey,chartworkapikey,room,slackchannel){
var result = getMessageToRoom(chartworkapikey,room);
if(result.getContentText().length > 0){
var eventSearchResult = JSON.parse(result.getContentText());
for each(var obj in eventSearchResult){
sendToSlack(slackkey,slackchannel,obj.account.name+"さんのchatwokからの通知",obj.body);
}
}
}
//chatworkのルームからメッセージを取得
function getMessageToRoom(token, roomId) {
var params = {
headers : {
"X-ChatWorkToken" : token
},
method : "get"
};
var url = "https://api.chatwork.com/v1/rooms/" + roomId + "/messages?force=0";
return UrlFetchApp.fetch(url, params);
}
//slackへ通知
function sendToSlack(url,channel,username,body) {
var data = {"channel": channel, "username": username, "text": body, "icon_emoji": ":ghost:"};
var payload = JSON.stringify(data);
var headers = {"Accept":"application/json",
"Content-Type":"application/json",
"Authorization":"Basic _authcode_"
};
var options = { "method" : "POST",
"contentType" : "application/json",
"headers" : headers,
"payload" : payload
};
var response = UrlFetchApp.fetch(url, options);}
なお実際に使うのはメッセージの加工なども少し行いますので
単に転送だけではないですが最低限必要な部分を抜き出しました。
あとPagerDutyでメッセージをある程度の単位で管理したい(ニーズがあれば)。
#誰が見てそのメッセージの内容を対応するのか？24365で複数人が
チャットを見て対応するので、作業着手やchatworkへのメッセージの返信が
かぶらないように。
こういうのをやりすぎると酸素欠乏症になったアムロの親父みたいな扱いに
なりかねないので、きちんとニーズがあるかを確認して
色々とやっていきたいと思います(現状からのニーズと最適化は別ものなので
声を聞いているだけでも駄目なんですが汗)。
