GROUPエンジニアブログです。Networkというスマートフォンに特化したクリック課金型アドネットワークを担当しています。我々は今のところシステム監視にXymonという統合監視ツールを使っています。Client連携の他、カスタムスクリプトで定期的にAWSのリソースの状態を監視したり、Fluentdからfluent-plugin-xymon経由でXymonにメトリクスを取り込んだりという手を加えながら、より高いサービスレベルの達成に力を注いでいます。NetworkではXymonが問題を感知したときの通知として、これまでは伝統的なメール発報を行ってきました。利用実績の多さに加え、最近だと携帯にプッシュを受けれたり、ルールに基いてメールを転送したり、フィルタリングしたりと、伝統的とはいえまだまだ使い手のある手段ではあります。21世紀の今日、もっとカジュアルかつ即時性が高く、送られてきた通知を契機に迅速かつスムーズにコミュニケーションが取れる手段を使いたいなあと思っていました。そこで我々は"チーム開発にフォーカスした快適なグループチャット"idobataとXymonを組み合わせることで上記を実現しました。idobataはグループチャットとして動作がスムーズで謳い文句の通り快適に使うことができる他、WebHook機能によってGithub、PivotalTracker、Jenkinsなど日常的に使っているポピュラーな開発支援ツールからの通知をかんたんに取り込むことができます。WebHookに、Xymonサーバからアクセスする方法をとっています。下記2ステップをXymon側に設定するだけでかんたんに実現できるので、Xymonを使っている方は是非速攻でお試しください。他の監視ツールを使っている場合も考え方は同じなのでかんたんに適用できるでしょう。Fluentdにはfluent-plugin-idobataというプラグインがあるので、こちらも利用すると捗るかと思います。■ステップ1alerts.cfgに、条件に合致したらスクリプトをキックするように設定を追加します。いずれかのホストでCOLORがredの場合に/path/to/xymon2idobata.shをキックしてidobataに通知する場合、下記の様に記述します。SETTINGSをご覧ください。ご参照ください■ステップ2idobataに通知するためのxymon2idobata.shを実装します。スクリプトの中では、エラーの状況やメッセージなどが環境変数で渡されるので、それを元にhttpリクエストを作ってidobataにpostします。したハマりどころとしては、alerts.cfgで渡したrecipient情報(ステップ1では$ZGOK_IDOBATA_WEBHOOK_URL)は、コマンドライン引数ではなくRCPT環境変数に格納されます。HookでFAILUREとかSUCCESSを出すを大いに参考にして、エラーレベルごとにわかりやすくidobataに表示するようにしています。BBCOLORLEVELにredだのyellowだの、Xymonのエラーレベルのカラーが渡ってくるので、これでどのようなラベルにするか判断しています。Xymonからのメッセージをpreタグで囲むようにしましたが、これだとメッセージの最後についているURLがidobata上でクリッカブルになりません。URL部分をpre外にも出して、idobataに送り込んでいます。Licenseとしますので、ご自由にお使いください。他にも様々な技術的なアーキテクチャや工夫を行っています。AWSブースで講演した時の資料を公開していますので、こちらも是非ご参照ください。GROUPや広告配信に興味を持ちましたら、是非こちらもご検討ください。API開発こんにちは。MARKETINGでシステムを担当している@axhillです。MARKETINGではポイント交換のPeXの運営の他、様々なサービスを提供しています。今回は、そんなサービスの中の一つ、デジタルギフト・オンデマンド・サービスを開発した時のことを書こうと思います。APIを通してリアルタイムに発券することができるBtoBのサービスです。APIの設計経験に乏しかった私には、どのように作ろう、と考えていた中で一つ思ったことがありました。それは次のような考えです。APIを開発できそうだ。APIについてブレストをしてみることにしました。リクエストの種類ごとにレスポンスの形式が変わるAPIごとにレスポンス形式がXMLでしか受け取れなかったり、またJSONでしか受け取れなかったりとバラバラに指定されているのは嫌ですね。リクエスト時にレスポンス形式を指定できるとサービス利用側の実装が楽になりそうです。稀にレスポンスが得られないことがあるネットワークやサーバの障害が発生しないとは保障しきれません。APIでリクエストを受け取れなかったり、レスポンスがリクエスト元に届かないことも起こりえます。後からリクエスト・レスポンスの内容を確認できる手段があると重宝しそうですね。第三者が自分のアカウントでリクエストできる第三者が正規サービス利用者のアカウントでリクエストを行うと、API利用にかかる請求は当然、正規サービス利用者に乗ってきます。APIとサービス利用側で、お互いに正しいリクエスト・レスポンスであることを検証できると嬉しいですね。そもそも第三者がリクエストを行えないような制御が必要ですし、リクエスト方法やリクエストの検証方法が第三者に漏洩しないよう、気を配らなければなりません。サンドボックスが無い。使いづらいサンドボックスが無い場合、開発する際に自前でスタブを作る必要があるので、サービス利用側の工数が膨らみそうです。APIを設計しておくことでサービス利用側の開発が楽になりそうです。APIは作り方次第で、サービス利用者に大きなストレスを与えます。APIの形が何となく見えていたので、今回はこのようなブレストを実施できました。APIの形が何となく想像できたのは良かったです。APIは嫌」にはならないと思います。サービスを運営されている方は、他社や自社のサービスに対する不満を記録しておくと自社サービスへの改善点として活かせることもあるかもしれませんね!ではー。voyagegroup_tech2013年10月15日16:47カテゴリtoolネタHRForecastでサービスの数値を見える化してディレクターに好評。GROUPの水越(@Akiyah)です。エンジニアをしています。最近、同僚のコテツさんが社内にHRForecastを導入してくれました。HRForecastとは数値を毎日/毎時で登録するとブラウザ上でわかりやすいグラフにしてくれるツールです。blog.nomadscafe.jpディレクターの方が必要としている数値を、われわれエンジニアが出して渡すという運用は今までもいろいろな方法でやっていました。管理画面を作ったり、デイリーバッチで数値の入ったメールをメーリングリストに送ったり、エクセルファイルやCSVファイル、グラフ画像を更新してファイルサーバーに置いておくといったやり方です。HRForecastを使うと数値の更新もデータの表示も楽になるので、できるところから順次HRForecastに移しているところです。データを記録するのはhttpでPOSTするだけなので簡単。データ解析環境「R」ではこんな感じで、APIにしたがってsimplePostToHostを叩くだけです。このスクリプトを1回動かすとすると、グラフに当日と前日の数値がプロットされます。過去のデータは保存してくれるので、最新のデータのみ更新すればよい。過去のデータは保存されるので、過去のデータを計算しなおす必要は無く、毎日最新のデータを更新するだけでよいです。もの過去分を含めて計算しなおしていることが多いので、最新のデータのみ更新すれば良いのはとても助かります。HRForecastを使い始めの時は、上記のスクリプトを必要な過去の日数分繰り返すようなスクリプトを書いて1回だけ過去データをまとめて入れておくと良いでしょう。過去のデータを上書きすることもできるので、未確定のデータを入れておくこともできる。Users:1日にサービスを利用したユーザー数)を1時間おきに更新したい、と言うような場合、上記のスクリプトを1日1回では無く、毎時実行するだけで毎時更新を行うことができます。DAUの場合、ある日のDAUが確定するのは次の日になってからになりますが、そういう場合には前日と当日のDAUを更新するようなスクリプトを書いておきます。すれば当日分は1時間おきに更新され、前日分は日が変わって確定した時に(1時間以内に)確定した数値で更新されます。シンプル上で書いたようにPOSTするAPIはシンプルです。データベースのテーブルもdata(個々の数値)、metrics(グラフ)、complex(複合グラフ)の三つだけで、その中身も一度HRForecastを使った人なら何となくわかるくらいシンプルです。テーブルの構成がシンプルなので、ブラウザ上では面倒なこともSQLで一気に操作することが簡単にできます。うっかりしてグラフをたくさん作ってしまった時などはよくSQLを使って消しています。ちなみに、HRForecastではブラウザ上でグラフを書くのにdygraphsというJavaScriptライブラリが使用されています。HRForecastのviewの部分はdygraphsにCSV形式のデータを渡しているだけなので、viewの部分もシンプルに作られています。CSVファイルとしてダウンロードできる。Excelで加工したい場合も多いので、描画されたグラフではなく元のデータが得られるのはうれしいようです。グラフを拡大、縮小して見たいところに注目することができる。データはたくさん(例えば何年分も)入れておいても、表示するときに最新の1ヶ月分などを簡単に見られるのが好評です。URLさえ知っていれば見ることができる。今までの仕組みだとメーリングリストに入らないと自分にはメールが届かなかったり、権限をもらわないと管理画面を見られなかったりするので、それに比べるととても便利です。(もちろん社内のLANからしか見られないようにはしています)アンパンマンと言うわけで、社内で好評なHRForecastですが、もっと仲良くなるためにアンパンマンを書いてみました。私にとってアンパンマンはHelloWorldなのです。以前作ったアンパンマン方程式を使って、横軸を日付(2013/1/1~2013/12/31)、縦軸を整数(-200~200)でcsvファイルにしました。そのcsvファイルの数値をHRForecastのグラフとして登録します。HRForecastの(複合グラフではないほうの)グラフには1つの線しかかけないので、アンパンマンの顔を6つのパーツに分けて登録しました。顔の輪郭(上)顔の輪郭(下)目はなとほっぺまゆげくちこれらのグラフをHRForecast上で複合グラフにして、アンパンマンの完成です!↑これはHRForecastに貼り付けたもののスクリーンショットですが、HRForecastで実際に見るときはインタラクティブに操作ができるので、その雰囲気を感じられるようにdygraphを使って拡大縮小できる状態にしたグラフを下に貼っておきます。(canvasが使えるブラウザのみ)みなさまもHRForecastとアンパンマンとお友達になれましたでしょうか。18:30)はからずもこの記事を書き終えて公開してからやなせたかしさんの訃報を知りました。アンパンマンは私の息子と娘、そして私にとってのヒーローでした。ご冥福をお祈りいたします。MobileでABテストをしてみたかったこんにちは。(以下GTM)がモバイル・アプリ向けに対応したことが正式に発表されてから久しいですが、きちんと見ていなかったのでせっかくなので調べて使ってみた時の事を書こうと思います。GTMってなんだ?という方もいらっしゃるかもしれないので、簡単に紹介させていただきます。残念だが、それは無理だ。I/Oで予告したように、今日、当社はモバイルアプリ向けのGoogleタグマネージャをローンチします。モバイルアプリ用Googleタグマネージャを一度導入してしまえば、設定変更は可能になり、分析、リマーケティング、コンバージョントラッキングを、対象のアプリをアップグレードせずに追加することが可能になります。おお、なんだかすごく便利そうですね!予めSDKを仕込んでおけば、ある程度GTMからいろいろなところにフック出来そうな感じがします。何はともあれ、とりあえずヘルプを見てみます。タグマネージャを使用すると、変更予定のある設定値や、条件に応じて変える可能性のある設定値を簡単に管理できます。タグマネージャで管理します。例として次のものが挙げられます。ヘルプ・・・、なんだか入れ忘れたイベントを追加したり、コンバージョンを追加したりするのはどうやるのかイマイチわかりません。設定をGTM経由で取得するようにしておけば、設定変更を行えそうだということはわかりました。イベント追加忘れ→そいつは参ったまま急なコンバージョンの追跡→それもひどいまま大事な設定の変更→残念じゃないかもしれない!予め仕込んで置けば無理じゃないかもしれない!といった具合のようです。記事を書き始めた当初はイベント追加し忘れたよ!GTMで新しく追加したよ!みたいな記事を書こうと思ったんですが、完全な見切り発車でした。ここで大きく方向転換をして、近々ABテストが実装できるとの事なので、おそらく現在の機能でも頑張ればABテストできるんじゃないかと思ってABテストのようなものを実装してみることにしてみました。