【cloudpack 大阪 BLOG】MSPのシステム化について GMailとGoogle スプレッドシートとslack連携
本来なら
「MSPのシステム化について Hubotでの状態管理(mysql)とGoogleカレンダーとslack連携 その2」
なのですが、自身のHubot熱が急速に冷めて行っている＆JAWS-UG大阪で廣山さんが
発表した資料
の中に記載されているPagerDutyの導入を比企のほうで進める事になり、
Hubot&MYSQLで対応している部分をPagerDutyに置き換えよう熱が高まったので
その２は延期?させて貰います汗。
※HubotのNode.jsのコールバック地獄がMSPしながらだと
※どうしても手軽に実現できない事情もあります(単純に開発だけしてたら良い時期は
※今考えたら楽でしたねw)
今回はGMailとGoogle スプレッドシートとslack連携について
お題は
①Backlogの担当者が未設定のものをslackに通知する
②監視サーバーからのアラートメールに状況(Google スプレッドシートに記載しているものをマッチング)を送付してslackに通知する
です。
まず①ですが、処理する方法は
Gmailにアクセスする(1/7):初心者のためのGoogle Apps Scriptプログラミング入門
を見て頂ければ処理の仕方はわかるので、上記を参照して頂ければと思いますが
引っかかった部分としてgmailのAPIを個別にCALLにしてしまうと、
メールが少ない場合は問題ないのですが、②も含め、cloudpackはメールの量が多いので
GASの処理可能時間を簡単に消費して24時間経たないと処理が再実行されない状況になります。
var thds = GmailApp.search('検索条件');
var thd = thds[n];
var msgs = thd.getMessages();
var msg = msgs[m];
var from = msg.getFrom();
var to = msg.getTo();
var date = msg.getDate();
var subject = msg.getSubject();
var body = msg.getBody();
などは処理上仕方ないのですが
msg.markRead();
GmailApp.moveMessageToTrash(msg);
などメールの個別のAPIをコールせずに
GmailApp.markThreadsRead(thds);
GmailApp.moveThreadsToTrash(thds);
などのスレッドに対するAPIで処理をまとめて行うようなAPIをコールして処理を行わないと処理が回らなくなりました。
また、処理の実行間隔のタイミングはGASは1分・5分・10分・15分しか設定できないので、
var d1 = new Date();
if((d1.getMinutes()%2) != 0) return;
関数の先頭で、上記コードで2分間隔ぐらいで実施するように修正しました。
※地味だけど本当に処理時間に気をつけないといけないので汗
またこれも処理時間ネタですが②に関してもGoogle スプレッドシートを
スプレッドシート利用の基本(1/5):初心者のためのGoogle Apps Scriptプログラミング入門
のサンプルで実装するととりあえず動くものは簡単に出来るのですが、
これもGoogle スプレッドシートの処理APIを毎回コールすると、処理の量が多いと
すぐにあふれてしまうので、
var data = getMainSheet().getRange(取得開始業,取得開始列,取得終了行,取得終了列).getValues();
でスプレッドシートの値を範囲指定で取得し
data[取得行][取得列]
な配列でアクセスして処理時間を短くする必要があります。
※処理時間は関数単位ではなく、アカウント全体での時間になるので自分が作った関数だけちょっと重いけどまあいいやなんて
※感じでその場限りで対応すると後でトラブった時に詰んでしまいますので処理時間は必ずスクリプトのメニューの表示→実行トランスクリプトの
※処理時間を見ながら計算してください。
そしてslackへの投稿部分ですが
でslack側で出力先のチャンネル名を設定し、登録後のURLをメモしておき
UrlFetchApp.fetchを使って下記コードでslackへ送信します。
function sendToSlack(channel,body) {
var r;
try {
var url = "メモしたslackのURL";
var data = {"channel": channel, "username": "bot名称", "text": body, "icon_emoji": ":smiling_imp:"};
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);
} catch(e){
var error = e;
Logger.log("message:" + error.message + "\nfileName:" + error.fileName + "\nlineNumber:" + error.lineNumber + "\nstack:" + error.stack);
r = null
return false;
}
return true;
}
なお現在ですが
Hubotによる自動化の推進は止めて、PagerDutyの運用を24365の
MSP業務に合わせる為に導入設計・導入を対応していますが、
PagerDutyの導入が一段落したらPagerDutyをベースに既存機能の置き換えや
PagerDutyによるMSP業務の見える化を実施する予定です。
うまく今あるサービスを活用し、足りない部分を実装して運用の負荷を減らして
いきたいと思います。
PagerDutyの解説(運用方法)もニーズがあれば投稿します
