New Relicさんとの馴れ初め
所謂サイトのパフォーマンスが低下する、サイトが停止する、という出来事が頻発して路上で頭を抱えていた時にNew Relicさんが目の前に現れて優しく手を差し伸べて来ました。
悩まされていたシステムの構成
所謂web三層構造のシステムでプラス別システムのDBやファイルサーバーへも参照に行く構成。
パブリッククラウドとオンプレデータセンターのハイブリッド構成。
クラウドとデータセンター間はインターネット回線を足回りにしたVPN接続。
何に悩まされていたか
登場人物が多い。
被疑箇所が多い。
多いとどうして悩まされていたか
登場人物（サーバー）が多いと調査の為のログ収集行為だけでも大変です。
被疑箇所が多いと調査の(ry
登場人物が多いと
ログを突き合わせてみて問題があった時刻に何が起きたのか推測する行為が大変です。
（サーバーの時間がずれていれば時系列が狂ってしまう事も）
被疑箇所が多いと
アプリが悪いの？ネットワークの遅延じゃない？DBのパフォーマンスが劣化した？
アプリケーション開発者とインフラ管理者とDB管理者の「お前のところの責任だろ？」のおしくらまんじゅう状態となります。
皆んなで協力する為にも
その時、どこで、何が起きていたかを一貫して観測できるツールの必要性を欲していました。
New Relicさんと出逢って助かった事
New Relic APMを利用したサイト稼働中のパフォーマンスモニタリングが可能となった事。
（ボトルネックがロジックなのか、ロジック内のSQLなのか、外部システムからの応答なのか）
全ての登場人物、被疑箇所となるポイントを一元管理できるようになった事による運用・観測の効率が上がった事。
New Relicさんとの今後の付き合い
クラウドリフト、クラウドシフト、マルチクラウド、はたまたオンプレに戻ろう、システムのロケーションが多様になった事で、監視サーバーどこに置く？どこで監視する？監視サーバーにデータ送る為に穴あけするの？それともそれぞれのロケーションに監視サーバー置くの？なんて課題が出て来ました。
いやいや、New Relicさんがいるじゃない。という事で、監視サーバーをクラウドシフトならぬNew Relicシフトにしている最中です。
拙い文章にお付き合いくださってありがとうございます。