概要

前回の続きです。
タイトルを変えました。その2ですが、ケース番号は1から始めます。

詳解 NewRelic で監視＆性能改善〜その１
 詳解 NewRelic で監視＆性能改善〜その２

ケース1: アプリケーションが正しく動いているのか知りたい

ようするに生存確認です。正しくやろうとすると、一通りのAPIにリクエストを投げてレスポンスを確かめます。
ただ、実際にはそこまでする必要はなくアプリケーションが動いているかどうかを１つの生存確認用のAPIに投げてレスポンスがただしいかどうか確かめればいいと思います。
その際に、どのようなAPIを作るかが大事です。echoサーバのようにただechoを返すのではなくMySQL, Redisなど繋がっているサービスにも軽いクエリをなげるといいです。
その様にすることによりMySQL, Redisの生存確認も同時にすることができます。

NewRelicでは以下で設定できます。

設定したあとはAvailabilityでその結果を見ることができます。

Alertメールなども設定できるので、設定しておくとシステムダウンの際に素早く気づくことができます。
自分の所属しているチームでは、開発環境が接続できなくなったときなどチャットに通知がとどくので素早く気付き修正することができます。

ケース2: 世界各国からの応答時間を知りたい

世界展開しているアプリは、各国からの応答時間がきになるものです。
NewRelicではSYNTHETICSを設定することによって以下の地域からの応答時間を調べることができます。
一定時間ごとに送ってくれるます。

ケース3: 例外が発生したときにそのプレイヤーIDが知りたい

NewRelicでは発生した例外はErrorsで表示されるのですが、自分で設定しない限りはアプリケーション特有の情報は含んでくれません。
例えば、player_idなどユーザを特定できるものが例外とともに記録されていればアプリケーションの管理画面などからそのユーザを検索し、例外のより詳しい状況がわかることができます。

NewRelicで正しく設定すると以下のように見れます。

ソースコード上では以下のように設定しています。
共通処理なので、decoratorとかviewの前処理などに仕込めばいい感じにしてくれそうです。(Djangoでのお話)

# newrelicにplayer_idを追加する
newrelic.agent.add_custom_parameter('player_id', player.id)

ケース4: あるAPIを改善したので実際に早くなっているのか確認したい

改善したならば計測して実際に早くなっているか確認しないと意味がないですね。
NewRelicでその辺も確認できます。

結び

前回、Key Transactions, X-Rayを紹介するといっておりましたが、他のを紹介していたら時間切れになってしまいましたので次回にします。
次回は最初からKey Transactions, X-Rayを紹介します。