Application monitoring tips you need to know
APMの使い方を知ることも大事ですが、New Relicのアプリケーションパフォーマンス監視ソフトウェアの正確な使い方を知ることも大事です。ここでは、 のプロになり、チームにとって重要なメンバーとなるために役立ついくつかのベストプラクティスをご紹介します。
パフォーマンスの問題を解決するステップバイステップのチュートリアルをお探しですか？ 「私のアプリが遅い」のチュートリアルをご覧ください。
ヒント
すべてのアプリケーションおよびサービスに関する大まかな概要を得るには、エンティティエクスプローラーを利用してください。
ヒント
APMおよびその他のNew Relic機能を使用して、よくあるパフォーマンスの問題を見つける方法については、信頼性エンジニアリング診断のガイドを参照してください。
1. アプリケーション名を標準化する
New Relicの設定ファイルでアプリケーション名を指定しなかった場合、ほとんどのNew Relicエージェントは「My Application」や「PHP Application」などの、デフォルトのアプリケーション名を使用します。20個のアプリケーションが同じ名前になるような状態を避けるために、アプリケーションをディプロイしたらすぐに、必ず分かりやすい識別子を選択してください。
一貫性と操作性を保つため、New Relicではアプリケーション命名の標準化を推奨しています（例：ステージングのすべてのアプリケーションの名前の末尾に、「Staging」または同様の名前を追加します）。新しいJavaアプリケーションを命名する際には、打ち間違いや命名の誤りの可能性を減らすため、自動的に命名できることが理想的です。
設定方法
Javaアプリケーションの場合、自動的にアプリケーションを命名するには、次のソースが利用できます。
- リクエスト属性
- サーブレットの初期化パラメーター
- フィルターの初期化パラメーター
- ウェブアプリケーションのコンテキストパラメーター
- ウェブアプリケーションのコンテキスト名（表示名）
- ウェブアプリケーションのコンテキストパス
ニーズに最も適した方法を選択して、これらの手順に従ってください。
Java以外のアプリケーションの場合は自動的に命名する方法がないため、APMエージェントのドキュメントを参照してください。
2. アプリケーションにタグを追加する
複数の異なるアプリケーションが同じアカウントを使用し、各アプリケーションが複数の環境にまたがっている場合（例：開発、テスト、試作、生産）、概要ダッシュボードで特定のアプリケーションを見つけることが難しい場合があります。そのため、アプリケーションにタグを追加して、論理グループに分けることが推奨されます。
APMを使い慣れた顧客が使用する最も一般的な2つのタグは、アプリケーション名と環境です。例えば、「テスト」の請求アプリケーションを表示する場合は、「請求アプリケーション」（名前タグ）と「テスト」（環境タグ）ですぐに絞り込むことができます。
注意
APMエージェント構成設定ファイルで、labelsフィールドを使用してデータにタグを追加します。例えば、Pythonラベル設定のこの説明を参照してください。
APMは、アプリが数に制限なく重要なタグカテゴリに「ロールアップ」できるよう設計されています。
設定方法
3. アラートポリシーを作成・評価する
主なパフォーマンス指標の急上昇または急降下が発生した場合、組織内の個人やチームに通知を行う必要があります。New Relicのアラートは、エンドユーザーに影響がでる前に問題を検出する動的な異常などの一連のツールを提供します。
アラートポリシーは、主に次の2通りの方法で設定できます。
Static threshold alerts
アプリケーションの性質がすでによく理解されていて、通常の動作がすぐに変更される可能性が低い場合に適しています。Apdex （Application Performance Index）スコア、レスポンスタイム、エラー率、スループットなどは静的な閾値で、これらに対してアラートポリシーを作成できます。
Dynamic anomaly alerts
変化する周期的パターンや成長傾向（通常の動作を定義する閾値を設定することを困難にする）に対して、アプリケーションアラートの動的な閾値を判断・設定することが容易になります。これらの
は、アプリケーションの過去のメトリクスデータからモデル化された異常を使用します。
各アラートポリシーには必要なだけ条件を含めることができます。それぞれのアラート条件には次の3つのコンポーネントが含まれます。
条件のタイプ（メトリクス、外部サービスなど）
エンティティ（APMアプリケーション、
アプリケーション、ホストなど）
深刻さが増した際にアラート状態に進行する閾値
アラートを設定したら、実行可能なすべての通知チャネルを利用していることを確認します。結局のところ、誰にも知られていないアラートには意味がありません。
アラートの管理は、特定のユーザーグループを作成し、Slack、PagerDuty、Webhook、メールなど、New Relicの統合アラートチャネルを利用して行うことができます。アラートポリシーを定期的に評価して、常に有効であることを確認してください。
設定方法
以下の詳細なドキュメンテーションを参照してください。
- 動的な異常アラートを設定し、アプリケーションを選択するには、標準的な手順に従ってください。メトリクスのプレビューが予測異常とともに表示されます。アプリケーションのメトリクスを選択して、該当する異常を確認できます。それから、閾値スライダーを使用して、閾値を異常予測にどれだけ近づけるかを設定できます。
- Apdex設定に静的な閾値アラートを設定するには、標準的な手順に従ってください。
- アラート通知チャネルを設定するには、標準的な手順に従ってください。
4. キートランザクションを特定・設定する
お使いのアプリケーションの性質によっては、他のトランザクションよりも重要なトランザクションがあります。New Relicのキートランザクション機能は、エンドユーザーやアプリケーションのレスポンスタイム、コール数、エラー率など、アプリケーションで最も重要と考えられるトランザクションを厳密に監視するよう設計されています。キートランザクションのパフォーマンスが悪い場合は、通知のアラート閾値レベルを設定することもできます。
設定方法
one.newrelic.com > All capabilities > Key transactions
に移動してから、
Add more
を選択します。 次にアプリケーションとウェブトランザクションを選択するか、選択したトランザクションから
Track as key transaction
を選択します。
キートランザクションの名前を入力し、
Track key transaction
を選択します。
オプション：選択したアプリケーションのエージェントがカスタムアラートに対応している場合は、New Relicが自動的に入力するデフォルト値を使用するか、またはEdit key alert transaction policyを選択してApdexおよびアラート閾値を設定します。
キートランザクションダッシュボードの詳細を表示するには、
View new key transaction
を選択します。
5. デプロイメント履歴を追跡する
開発チームが頻繁に新しいコードを投入する中、それぞれのデプロイメントがパフォーマンスに及ぼす影響を測定することは容易ではありません。これらの変更がアプリケーションに及ぼす影響を正確に把握する方法の1つに、デプロイメントレポートがあります。
これらのレポートには、直近のデプロイメントとエンドユーザーやアプリケーションサーバーのApdexスコアへの影響、さらにレスポンスタイム、スループット、エラーが一覧表示されます。また直近のデプロイメントに関するエラーを見つけるために、詳細をドリルダウンして表示することも可能で、チケットを発行したり、チームと詳細を共有したりもできます。
設定方法
New Relicメニューバーから
APM & services > (select an app) > Events > Deployments
を選択します。
デプロイメント後のパフォーマンスを表示するには、選択したアプリケーションの
Recent events
セクションにあるOverviewダッシュボードに移動します。
チャート内の青色の縦線は、デプロイメントを示しています。デプロイメントに関する要約情報を表示するには、青色の縦線を指し示します。
6. APMレポートを確認する
APMはSLA、デプロイメント、容量からスケーラビリティ、ホスト使用状況レポートなどに至るまで、過去の傾向を浮き彫りにするさまざまなダウンロード可能なレポートツールを提供します。これらはすべて役員や顧客への報告に最適な方法です。レポートの完全なリストを参照し、役立ててください。
設定方法
APMメニューバーから
Applications > (select an app) > Reports
を選択します。
表示するレポートを選択します。
共有するレポートを保存またはエクスポートする場合は、
Download this report as .csv
を選択すると、コンマで区切られた値でレポートが作成されます。
7. サービスマップで環境を確認する
アーキテクチャ内のアプリケーションとサービスがどのように接続・通信するかを理解するには、New Relic APMに含まれるサービスマップ機能を使用します。サービスマップは、アプリケーションアーキテクチャを可視化したカスタマイズ可能な描写です。マップには、データベースや外部サービスなど、お使いのアプリケーションの接続先や依存関係が自動的に表示されます。稼働状態インジケータやパフォーマンスメトリクスには、アーキテクチャのあらゆる構成要素についての現在の稼働状態ステータスが表示されます。
How to do it
one.newrelic.com > All capabilities > More > Service maps
に移動します。
開始するには、サービスマップの概要を参照してください。
8. 最新の状態に保つ
New RelicのSaaSプラットフォームでは、新機能の追加はエージェントの更新と同じくらい簡単です。大抵の組織では、アプリケーションのアップグレードを環境にディプロイするために、一連のスクリプトが用意されています。同じように、New Relicエージェントのデプロイメントを自動化して、システムを最新の状態に保つこともできます。Ansible、ChefおよびPuppetは、共にデプロイメントフレームワークのよい例で、デプロイメントプロセスや管理プロセス全体の自動化を可能にすることで作業を軽減します。
設定方法
アップデートが必要なときに備えて、使用しているエージェントのバージョンを定期的に確認します。最新のエージェントリリースに、必要な修正または機能が追加されている場合は、ダウンロードします。
自動でのエージェントのデプロイ(preferred as a method to avoid errors)：
デプロイメントを処理するための変更が可能な場合、既存のデプロイメントスクリプトを使用します。
または
New Relicエージェントのディプロイ・設定に特化したスクリプトを作成・管理します。理想的に、スクリプトは（ロールバックができるよう）ファイルがバージョン管理されているリポジトリからエージェントファイルを取得します。
スクリプトが作成されたら、アプリケーションをシャットダウンします（スクリプトがシャットダウンを処理しない場合）。
デプロイメントスクリプトを実行します。
アプリケーションを起動します（スクリプトが起動を処理しない場合）。
問題が発生した場合は、スクリプトを実行して以前のバージョンに戻します。
手動によるエージェントのディプロイ：
現在のエージェントディレクトリをバックアップします。
更新されたエージェントを、既存のエージェントディレクトリにディプロイします。
新しい設定ファイルと既存の設定ファイルを比較して、ファイルを変更します。具体的には、
やカスタム拡張機能などが、新しい設定にコピーされるようにします。
アプリケーションを再起動します。
問題が発生した場合は、バックアップを使用して古いエージェントを復元し、再起動します。
9. ユーザーアクセスを管理する
ユーザーを管理する方法は、ユーザーがどのユーザーモデルを使用しているかによって異なります。