このガイドでは、デジタルプロパティの監視と改善に必要な計測データとテレメトリデータがあるかどうかを判断する方法について説明します。これは、可観測性の成熟度に関するシリーズの一部です。
概要
"自分のサービスを適切に測定するために必要なすべてのテレメトリを持っているか？"
生産監視のためにサービスをオンボーディングするプロセスは、最後から始まり、最初に進む傾向があります。通常、サービスはエージェントベースの監視でインスタンス化され、サービスの提供を担当するチームは、エージェントから送信されるテレメトリを読み取る必要があります（茶葉の読み取りに似たプロセス）。彼らは、観察できるものに基づいてサービスがどのように機能するかを理解するために逆戻りします。
New Relicでは、何万もの可観測性の展開を通じて、より関与する設計者、アーキテクト、および開発者が最適なサービス提供測定の定義に関与していることがわかりました。 IT格言「左シフト」の出現は、開発段階が完了した後に発生するソフトウェアライフサイクルアクティビティに開発者をより直接的に関与させる必要があることを示しています。
サービスの可観測性の場合、開発者が本番テレメトリの定義に有意義に貢献する方法についての具体的なガイダンスはほとんどありません。このガイドは、開発者がテレメトリの状態を評価し、それを改善するためのパスを提案するための実用的な提案を提供することを目的としています。開発者の期待と本番システムの実行時の動作を密接に関連付ける可観測性プログラムは、異常な状態を診断および修正するのにはるかに効果的です。そのより直接的な開発者接続は、より堅牢でパフォーマンスの高いサービスも生み出します。
次のいずれかに該当する場合は、このガイドを使用することをお勧めします。
- お客様の開発チームは、プロダクション・オブザーバビリティ・デザインから切り離されています。
- お客様のプロダクション・モニタリング・プログラムは、新しいサービスや機能の導入と、それらをテレメトリやアラートでカバーすることの間にタイムラグがあります。
- 診断とビジネスKPI測定を改善するには、インストルメンテーションに追加のビジネスコンテキストを提供する必要があります。
- 高度にカスタマイズされた、または独自のソフトウェアフレームワークを採用している。
- あなたのサービスは活発に開発されています。レガシーサービス、および市販のプラットフォームから構築されたサービスは、一般的なインストルメンテーションオプションでより適切に提供される傾向があります。
望ましい結果
このガイドでは、サービスのランタイム操作（コードの実行）から得られるメトリックと、実行の外部測定（合成テストによる）に焦点を当てています。サービスインストルメンテーション計画は、テレメトリを介して単一のサービスランタイムを記述するために使用されるアプローチです。
最新の監視システムは、サービス実装の技術的な詳細を深く理解することができます。分散型トレースやバイトコードインスツルメンテーションの能力により、オペレーションチームは詳細なサービステレメトリーを素早く収集することができます。しかし残念ながら、運用チームは計測器から収集したテレメトリの品質を評価するのに最適な立場にないことが多いのです。この問題は、サービスデリバリチームが本番システムに初めてテレメトリ収集を実装することを求められるという事実によって、さらに悪化します。
インスツルメンテーションが不十分なサービスを、そのインスツルメンテーションを改良する目的で本番ユーザに公開すると、顧客満足度を低下させる期間が発生します。ソフトウェアのデリバリーと観測プログラムの間に強い関連性がないコードベースから新機能が提供されると、このバーンイン期間から逃れることが難しくなります。
開発スタッフがサービスインストルメンテーションの改善に関与することにより、次の方法で可観測性の利点を実現する必要があります。
- より良い情報に基づいた開発の意思決定を行うことができます。
- ボラティリティーや予期せぬ動作の領域を検出し、それに対処する。
- コード内のどの依存関係が冗長性や堅牢性を欠いているかを理解し、サービスをリファクタリングするための対策を講じること。
- エンドユーザーがどのように自社のソフトウェアを使用しているかを把握することができます。どこを改善すれば最大の効果が得られるかをよりよく理解することができます。
- トラブルシューティングの改善
- サービスからのより正確で状況に応じたテレメトリにより、障害のより正確で実用的な検出が可能になります。
- テレメトリのネーミングが改善されたことで、オペレーションスタッフはインシデント時に開発者と共通の言語を使用することができ、インシデントのトリアージや修復にかかる時間を短縮することができます。
主要業績評価指標
ソフトウェア配信および運用プログラムの継続的な改善を評価するのに役立ついくつかの単純なKPIを特定することが重要です。改善された計装に投資する際に考慮すべき2つの主なタイプのKPIを次に示します。
- ビジネスKPIは、プログラム全体の目標に合わせて調整されており、各サービスの継続的なプログラムの改善を実証するために一貫して測定する必要があります。
- 開業医のKPIは、サービスの開発と管理に参加している人の職務の実行における変化を測定するために使用されます。
これらについては、以下で詳しく説明します。
ビジネスKPI
ビジネスKPIには次のものが含まれます。
実務者のKPI
開業医のKPIには次のものが含まれます。
前提条件
開発プロセスにサービスインストルメンテーションプラクティスを導入する前に、 NewRelicUniversityから入手できるNewRelicの基礎を理解してください。
NRU トレーニングに加えて、以下のドキュメンテーション資料を確認し、手元に置いてください。
計装ガイド
現在の状態を確立する
サービスの現在の状態を確立するには、次の2つの手順を実行します。
これらについては、以下で詳しく説明します。
機器のニーズを把握する
インストルメンテーションは、ソフトウェアシステムの実行時の動作とビジネス機能を説明する目的で、ソフトウェアシステムとそれに関連するサービスからテレメトリを取得するプロセスです。監視システムは、ソフトウェアシステムの機能を監視するときにギャップを埋めるために微調整できるテレメトリ取得の一般的な機能を提供する傾向があります。このユースケースは、可観測性プログラムがカスタマーエクスペリエンス-品質基盤ガイドを完了し、サービス用に十分に検討および展開されたテレメトリ収集アーキテクチャを備えていることを前提としています。
アラート定義を除いて、インストルメンテーションは、可観測性に関連する最も自由でカスタマイズ可能なアクティビティを提供します。 New Relicプラットフォームは、インストルメンテーションを高度にカスタマイズするための機能を提供します。このため、サービスのインストルメンテーションに費やす時間と労力を慎重に検討する必要があります。
すべてのサービス計装資産および依存関係と同様に、計装の導入には継続的な監視と保守が必要であるため、プロジェクトで発生する技術的負債の一種です。インストルメンテーションのプロセスを開始するとき、あなたは継続的に自分自身に質問をしたいと思います：
この機器から得られる可視性は、導入やサポートのコストに見合うものなのか？
デシジョン・マトリックス
最初のステップとして、可観測性プラットフォームから取得したデフォルトのインストルメンテーションを評価し、次の質問を自問する必要があります。
遠隔測定は、私のサービスの機能と目的を適切に説明していますか？
あなたのサービスが何をしているか考えてみてください。おそらく、サービスは注文を受け取り、その注文の整合性を検証する必要があり、その注文をクリアリングハウスサービスに伝え、確認コードを受け取って要求者に返信するのではないでしょうか。この例は、サービスの機能を分解し、サービスがどのように機能しているかについて情報に基づいた評価を行うのに十分な遠隔測定とコンテキストがあるかどうかを評価するための明確な道筋を示しています。
HTTPリクエストを受信して処理する概念的なサービス。
この概念図がサービスの実装を表しているのであれば、どんな時でも知っておく必要があります。
- どのくらいのリクエストがあるのですか？
- メッセージやHTTPリクエストの送信数はどのくらいですか？
- どのくらいのリクエストが成功しているのでしょうか？
- フルリクエストのレスポンスタイムはどのくらいですか？
- 依存先への呼び出し時の応答時間はどのくらいですか？
- どのくらいのリクエスト数で、このプロセスはどのくらいのリソースを必要とするのか？
- 私の失敗のポイントは何ですか？
アプリケーションランタイムのほとんどの監視フレームワークは、このようなテレメトリを基本機能として収集します。ただし、サービスの特定の実装によって、監視ソフトウェアによって行われる一般的なインストルメンテーションの仮定に問題が生じる場合があります。この場合、可観測性プラットフォームはニーズに対応し、デフォルトの監視構成を変更する機能を提供する必要があります。
次の表は、インスツルメンテーションによるテレメトリやメタデータの取得を追加することを検討する際の、いくつかの追加状況を示しています。次の「実践編」では、オブザーバビリティ・プラットフォームがサービスの管理に必要な遠隔測定を確実に行うために、これらのギャップを解消する方法を説明します。
インストルメンテーションに関する考察
| ベースとなるテレメトリの要件は満たされていますか？ | そうでない場合は、そのギャップを文書化し、カスタム設定や追加の計測技術によって解消できるかどうかを評価します。 |
| テレメトリ内で個別のユーザーストーリーを分離することはできますか？ | そうでない場合は、エージェントのトレース機能を使って、適切なコンテキストメタデータを持つ個別のユーザーストーリーの呼び出しをキャプチャします。 |
| ユーザーストーリーを起動するパラメータを把握しているか？ | そうでない場合は、エージェントSDKでカスタム属性を使用して、トランザクションとスパンにコンテキストを追加します。 |
| ソフトウェアの主要な機能コンポーネントを測定することができますか？ | そうでない場合は、インスツルメンテーションSDKを使用して、コードの特定の機能要素に関するベースライン・メトリクスを作成します。(キャッシュルックアップ、処理ルーチン、ユーティリティー関数など）。 |
| 自分のコードから外部システムへのクライアントのインタラクションを測定することはできますか？ | もしそうでなければ、リクエストとレスポンスがコンポーネントレベルのトラッキングによってカプセル化されていることを確認してください。クライアントの呼び出しが非同期の場合は、連続した処理を見るために分散トレース機能の実装を検討してください。 |
エンドポイントテストの理解
エンドポイント・テストは、シンプルで実用的なアプローチで、システム障害の根本原因を特定する方法を大幅に短縮します。これにより、運用チームやサポートチームは、実際に問題が発生していることを迅速に把握し、その問題を特定のサービスに切り分けることができます。
現代のソフトウェアシステムは、そのタスクを完了するために多くのサービスに依存しています。これまでは、サービスのエンドポイントを監視するプロセスは単純でした。アーキテクチャチームは、運用チームのために依存関係を文書化したマップを作成します。運用チームは、項目別のエンドポイントのチェックを忠実に行います。
現在、継続的デリバリープロセスと小さなバッチ変更により、運用チームが合成チェックを予測して事前に定義することを困難にする速度で、新しいエンドポイントと依存関係を作成および展開できます。サービス開発者に、開発フェーズ中に本番サービステストを定義するためのより広い範囲の制御を提供することにより、可観測性プログラムのエンドポイントテストの対象範囲を大幅に拡大します。
デシジョン・マトリックス
合成チェックを作成するかどうかを決定するのは簡単です。依存関係の障害が最初に発生したことを知りたいと思うでしょう。次の質問のいずれかに「はい」と答えた場合は、専用の合成チェックを作成することを検討してください。
- エンドポイントは顧客向けですか？
- エンドポイントは新しい依存関係を起動しますか？
- エンドポイントが別のネットワークインフラ上にあるか？
- エンドポイントは複数のサービスで共有されているか？
- エンドポイントは、CDNがサポートするコンテンツオリジンですか？
改善プロセス
多くの場合、改善プロセスには次の主要なステップが含まれます。
これらについては、これから詳しく説明します。
インストルメンテーションを構成する
各NewRelicエージェントは、さまざまな構成オプションを提供します。通常、インフラストラクチャホスト内のエージェント、アプリケーションランタイム、およびクラウドサービスプロバイダーへの接続を含めるための標準的なアプローチを定義します。デフォルトのエージェント構成は一般的であり、広く適用できます。
開発者がデプロイメントの適用性に影響を与える最善の方法の1つは、サービスインスタンスのデフォルト構成オプションをオーバーライドすることです。考慮すべきデフォルトのインスツルメンテーション・オプションを以下に示します。
効果的なサービス名の作成
ヒント
New Relicエージェントは、サービスランタイム名を定義するためのさまざまなメカニズムを提供します。ランタイム環境の実装の詳細については、アプリケーションの命名ガイドを参照してください。
サービスにつける名前は、 名前空間 (エージェントデータを見つける場所)を提供します。New Relic がお客様のサービスの動作を理解するために使用する最も重要な戦略のひとつは、同じようなものをまとめて集約し、集約から得られる共通点を利用して分散を分離することです。
最新のサービスは、容量処理または特定の機能セグメンテーションを確実にするために、複数のコンテキストに展開されることがよくあります。集約の利点を活用するには、サービスランタイムが同一の操作特性を持つインスタンスをグループ化することが非常に重要です。したがって、サービスをデプロイするときは、デプロイされたサービスに名前を付けるのに役立つ次の3つの基準に細心の注意を払ってください。
- 私のサービスは、特定のユーザーを対象としていますか？
- 私のサービスは別のコードベースで動いているのでしょうか？
- 私のコードベースは、異なるランタイム構成を使用していますか？
これらの質問に「はい」と答えた方は、サービスにユニークな名前をつけることを検討してください。
聴衆の基準
オーディエンスとは、エンドユーザーまたはサービス機能のグループと考えてください。サービスが北米と欧州のデプロイメントに分かれている場合、それらのデプロイメントのランタイムをそれに応じてグループ化する必要があります。例えば、以下のようになります。
newrelic.appname = PORTAL_AMERおよび
newrelic.appname = PORTAL_EMEAこれにより、そのオーディエンスによって作成された遠隔測定がグループ化され、特定のユーザーオーディエンスに関連するサービス問題の文脈上の類似性をよりよく理解することができます。
例えば、管理機能を持つポータル・アプリケーションのように、アプリケーションの展開方法によって、サービスの運用状況が分断されることがあります。管理機能はポータルの一般的なコードベースに組み込まれていますが、クラスタ内の1つのインスタンスだけがポータルの管理リクエストを処理している場合があります。このような場合、機能的なオーディエンスのセグメンテーションの機会があるので、適切な名前をつけるようにする必要があります。例えば
newrelic.appname = PORTAL_MAINおよび
newrelic.appname = PORTAL_ADMINコードベースの基準
1つのサービスを装って異なるコードバージョンを実行している場合は、それらのランタイムインスタンスをセグメント化し、ネーミングスキームの一部としてバージョンネーミングを組み込むことを検討してください。異なるサービスバージョンを実行している1つのサービス名としてコードをグループ化すると、生成するメトリックのノイズ対信号比が向上します。
コードのバージョンが違えば、使用する計算機資源の量やデータの処理方法も違ってきます。メトリクスから得られるシグナルが異なる機能の実装に起因する場合、サービスが正常に動作しているかどうかを判断することは非常に困難になります。
複数のバージョンを同時に実行している場合は、サービス名に数値IDを追加することを検討してください。例えば：
newrelic.appname = PORTAL_MAIN_V112および
newrelic.appname = PORTAL_MAIN_V115LaunchDarklyやSplitなどの機能フラグフレームワークフレームワークを採用している場合、単一のコードベース内に複数のバージョンのアプリケーションまたはサービスが存在する可能性があります。これらの条件に対処するには、サービス機能の分離に関するセクションを参照してください。
ランタイム基準
サービスのインスタンスが、異なるランタイム制約を持つシステムにデプロイされる場合、そのインスタンスは独自の遠隔測定ネームスペースにカプセル化されるべきです。これには、共有リソースへのネットワーク接続性に優れた別のデータセンターへのデプロイや、メモリやスレッドの構成が異なる別のコンピュート層でのサービスの実行などが考えられます。
コードの実行時の動作に影響を与えるこれらの特性は、異なる操作の動作につながる異なる動作を引き起こします。例えば、以下のようなものです。
newrelic.appname = PORTAL_NYC_DCおよび
newrelic.appname = PORTAL_REALLY_BIG_FOOTPRINTデフォルトのエージェント設定を上書きする
ヒント
New Relicエージェントは、ランタイム構成にさまざまなオプションを提供します。ランタイムに固有のオプションについては、 APMエージェントの構成ドキュメントを参照してください。
各 New Relic APM エージェントには、デフォルトの設定を変更するための様々なオプションが用意されています。最も包括的で一貫性のある場所は、各エージェントのインストール時に添付される設定ファイルです。しかし、New Relic エージェントは、コマンドラインパラメーターをサービスインスタンスのランタイムに直接渡したり、環境変数を使用したり、エージェントの SDK 内の関数をランタイムに呼び出したりして設定することもできます。
.NETエージェントの構成オプションは次のとおりです。
サービス機能の分離
「効果的なサービス名の作成」セクションに示されているように、インストルメンテーションの主な目的の1つは、同様のランタイム制約を単一の名前付きユニットとしてグループ化するようにNewRelicエージェントを構成することです。ソフトウェアシステムは決定論的な方法で動作する必要があるため、これをお勧めします。
特定の入力セットに対して、期待される範囲の測定可能な結果が得られるはずです。これらの制約条件を、名前付きサービスのランタイムコンポーネントにどれだけ快適に含めることができるかによって、正常な動作を理解し、異常な動作を切り分けることができるようになります。
効果的なサービス命名戦略を決定したら、次のステップは、サービス用に収集されたテレメトリ内を調べて、サービスの機能が適切に分離されているかどうかを判断することです。私たちが最も頻繁に遭遇する実装パターンは、Webリクエストによって呼び出される一連の関数です。サービスランタイムへのWebリクエストの最初の受信と処理により、処理リソースが割り当てられます。 New Relicは、このリソース割り当てとコード実行をトランザクションとして定義しています。
New Relicエージェントは、トランザクションが検出されたときに名前空間を作成する一連の前提条件で構成されています。これらの仮定は、エージェント言語のランタイム間で異なります。たとえば、New Relic Javaエージェントがトランザクション名を決定する方法の良い例は、 Javaエージェントのトランザクション命名ドキュメントにあります。
ただし、エージェントトランザクションの命名プロトコルを適用した後でも、満足のいく結果が得られない場合があります。トランザクションに名前を付けてコンテキストを改善するためのインストルメンテーションを追加することで、サービスの実行動作の理解を大幅に向上させることができます。
トランザクションの命名の目標は、開発者以外の人にとって理解しやすいアプローチでサービス機能の適切なセグメンテーションを提供するAPMトランザクションのビューである必要があります。
NewRelicサービスのトランザクション内訳ビュー。
トランザクションの内訳画像は、トランザクションのセグメンテーションの良い例です。この画像では、サービスの広範なコードベース内で各トランザクションが行っている作業量を詳細に追跡することができます。また、トランザクションをわかりやすい名前で表示し、そのビジネスコンテキスト（トランザクションが何をするか）を示唆しています。トランザクションの名前や属性の付け方を学ぶ際には、技術者でなくてもデータを見ることができるような名前の付け方を心がけてください。
トランザクションの内訳：このサービスのトランザクションは、かなり一般的な名前を持つ1つのトランザクション名に非常に重み付けされているようです。このような内訳は、「これは私のサービスが行う仕事の良い表現ですか？」という疑問を投げかけます。
鈍いトランザクションの内訳画像は、トランザクション名のセグメンテーションの悪い例を示しています。この場合、トランザクションボリュームの約60％がOperationHandler/handleという名前になっています。トランザクション量のパーセンテージ属性と名前の一般的な性質の両方が、そのトランザクション名前空間の下にトランザクションの過度に熱心な集約がある可能性があることを示しています。
トランザクション・ネーミング・アプローチを検証する良い方法は、サービスウェブ・トランザクション・ヒストグラム・ダッシュボードで、かなりの期間にわたるトランザクションの応答時間の分布を確認することです。
サービストランザクションのヒストグラムビューには、各応答時間バケットに分類されるトランザクションの数が表示されます。優れた命名戦略は、正規分布を表示する傾向があります。
サービストランザクションの画像は、トランザクションの応答速度の幅が広いことを示しています。トランザクションの大部分は0～200ミリ秒の範囲に収まっていますが、200～1000ミリ秒の範囲の値を示しています。1つのトランザクションに対する応答の範囲が非常に分散している場合、自問する必要があります。
トランザクションの実行中に、このトランザクションの名前を付けるのに役立つ情報は？
多くの場合、非正規分布は、リクエストに渡されるパラメータや、トランザクションに求められている作業の直接的な結果です。サービスクエリのトランザクションがデータ範囲をパラメータとして受け取ることを考えるのはとても簡単です。日付の範囲が小さいと、検索時間が短くなる可能性があります。したがって、予想されるパラメータの制約（> 1日、1～5日、>5日）から導き出される意味スキームを提供することで、より意味のあるセグメンテーションが可能になるかもしれません。
目的は、固有の特徴が最も少ないトランザクションをグループ化するためのトランザクション名を作成することです。
個々のトランザクションがより少ない例外でより一貫した応答時間の達成を報告する、トランザクションセグメンテーションのより正規分布。
正規分布画像は、サービス内のトランザクションをより意図的に命名したものです。この場合、ウェブトランザクションのレスポンスタイムはより密接にグループ化されており、一貫した実行特性を示しています。
トランザクションの命名戦略が、実行している操作のタイプごとにサービスの機能をグループ化する一貫したメカニズムを提供することを保証することにより、異常な動作をすばやく分離したり、変動の根本原因をよりよく理解したりできます。これにより、アプリケーションをリファクタリングし、サービスの機能の全体的な予測可能性を高めることができます。
カスタムトランザクション名の定義
ヒント
New RelicエージェントのAPIガイドを参照して、ランタイムのトランザクション命名手順を確認してください。
New Relicエージェントトランザクションネーミングサービスでは、NewRelicエージェントSDKへのSetName(String name)のようなAPI呼び出しを呼び出す必要があります。各言語ランタイムエージェントには、名前を設定するための独自の構文とオプションがあります。
たとえば、HTTPリクエストパラメータの値を取得し、それを使用してNew Relic Javaエージェントのトランザクションに名前を付けるには、次のようなコードを使用できます。
com.newrelic.agent.Agent.LOG.finer("[my query handler] Renaming transaction based on an important query parameter");
com.newrelic.api.agent.NewRelic.setTransactionName("Query Handler_" + (javax.servlet.http.HttpServletRequest)_servletrequest_0).getParameter("important_query_parm"));注意：NewRelicトランザクション名には最大容量があります。潜在的なトランザクション名が数千ある場合、トランザクション命名戦略はある程度の特異性をトレードオフする必要があります。
報告されているトランザクション名が多すぎる場合、NewRelicはそれらのトランザクション名をグループ化するためのルールを作成しようとします。詳細については、メトリックグループ化の問題に関連するエージェントトラブルシューティングガイドを参照してください。
メトリックのグループ化の問題が疑われる場合は、New Relicでサポートケースを開いてください。喜んで協力して、トランザクションの名前付けの問題の原因を特定します。
トランザクションでパラメータを取得
ヒント
エージェント言語のNewRelicエージェントカスタム属性ガイドを参照して、属性カスタマイズのメタデータ拡張オプションを確認してください。
トランザクション名は、サービスの機能をセグメント化して、その動作をよりよく理解できるようにするための強力な方法です。これにより、NewRelicUIで直接機能を個別に分離できます。
ただし、トランザクション名を分離することなく、サービスの機能に関する追加のコンテキストを取得したい場合が多くあります。これは、サービスによる属性キャプチャを導入することで実現できます。
name:valueペアの属性を追加して、各トランザクションの詳細を装飾できます。属性は、APMトランザクショントレースおよびエラーUIを介して、またはTransactionイベントタイプからのパラメーターの直接クエリを介して、各トランザクションイベントで使用できます。
トランザクショントレースを選択すると、サービスのトランザクションに設定したカスタム属性を表示できます。
APMエラーUIに表示されるトランザクショントレースの詳細の例を次に示します。
APMエラーUIに表示されるカスタム属性。
有用なトランザクション名のセグメンテーションを開発した場合は、属性の追加のコンテキストを使用して、予期しない結果につながる入力、コホート、またはセグメントをよりよく理解できます。
パラメータの導入は、APMのUI内でトランザクションのコンテキストを把握できることに加え、トランザクションデータを直接照会してトランザクションを集約・分析するための非常に便利なツールです。各トランザクションにカスタム属性が追加され、特定の条件での分離やファセットが容易になります。
カスタム属性を使用してデータベース呼び出し期間をファセット化するNRQLクエリ式。
パラメータキャプチャアプローチは、SplitやLaunchDarklyなどの機能フラグシステムでも使用できます。この場合、機能フラグの決定ハンドラーを実装するときに、顧客に表示されるバージョンまたは機能を制御するコードのブロックに適用されているフラグコンテキスト（たとえば、 optimized_version = on ）をキャプチャすることを検討してください。
機能フラグの状態がトランザクションカスタム属性によってキャプチャされたときの結果を示すNRQLクエリ。機能フラグの状態属性を使用すると、コード実行パスがパフォーマンス、スループット、および依存関係の使用率に与える影響を理解できます。
たとえば、HTTPリクエストパラメータの値を取得し、それをNew Relic Javaエージェントでカスタム属性として保存するには、次のようなコードを使用できます。
com.newrelic.agent.Agent.LOG.finer("[my query handler] Adding an Attribute to transaction based on an important query parameter");
com.newrelic.api.agent.NewRelic.addCustomParameter("ImportantParm", (javax.servlet.http.HttpServletRequest)_servletrequest_0).getParameter("important_query_parm"));サービスコンポーネントの測定
サービスのコンテキスト内での特定のトランザクションの動作は、機能を分離し、ソフトウェアシステムが効果的に動作していることを確認するための強力な方法です。しかし、ソフトウェアシステムの動作を見るもう一つの方法は、その実装の詳細なコンポーネント実行モデルを確認することです。アプリケーションフレームワークのコードコンポーネントはサービス全体で共有されており、コンポーネントのパフォーマンスを継続的に評価することで、サービス全体の健全性を把握することができます。
New Relicでは、コンポーネントの実行の詳細を確認できる場所が2つあります。 APMのサービスサマリーダッシュボードは、サービスの複合実行をそのコンポーネントパーツ（ガベージコレクションの実行やデータベース呼び出しなど）ごとに分類して表示します。
この要約ダッシュボードは、アプリケーション内の主要なコンポーネントタイプの内訳を提供します。 Memcached、External Web Invocations、MySQL、Diracはすべて、サービスの集合トランザクションがビジネスロジックを実行するために使用している共有コードフレームワークの例です。
同様の内訳は、トランザクションごとに提供されます。
この単一トランザクションの要約ビューは、コンポーネントごとに寄与している実行時間を分類します。これは、トランザクション内のコンポーネントの総合的なパフォーマンスを確認するのに役立ちます。
トランザクションコンポーネントのセグメントは、一貫したパフォーマンスを示す傾向があります。これは、根本的な問題の良い兆候となります。リソースの制約は、個々のトランザクションの詳細よりも、コンポーネントのフレームワーク内でより明確に現れる傾向があります。これにより、サービス内で実行されているすべてのコードが経験している共通の制約を通して、依存関係の特性を推測することができます。
自社のフレームワークを確実に測定する
ヒント
インストルメンテーションにメトリック名を追加する方法については、特定のAPMエージェントのインストルメンテーションおよびSDKガイドを参照してください。
フレームワークインスツルメンテーションの構文は、サービスが書かれている言語によって異なりますが、一般的なアプローチはすべてに一貫しています。サービス内の実行スレッドを、New Relic の遠隔測定におけるトランザクションになぞらえて考えてみてください。スタック上でメソッドや関数が実行されるたびに、インスツルメンテーションを追加する機会となります。このようにして、New Relic はトランザクションの時間的に注釈された呼び出しスタックを維持し、それらのメソッド/関数の開始/停止のタイミングを使用して、一連のコンポーネントメトリクスに集約します。
MongoDBを呼び出す単純なNode.jsアプリケーション。アプリケーションの2つの主要なコンポーネントは、MongoDBへのリクエストの受信とget/put操作です。
ロジックの特定のセグメントがサービスまたはトランザクションの機能にとって重要である場合は、その呼び出しをNew Relicエージェントへのコールバックでラップして、エージェントが個別のコードコンポーネントに入ったことを理解し、その中で消費された時間を集計できるようにすることを検討してください。それに応じてコンポーネント。メトリック名をコールバックに渡すことにより、サービスとトランザクションのコンポーネントセグメントメトリックを作成します。
メトリックの命名オプションは、計測器の言語によって異なりますので、各言語のマニュアルを参照してください。
New Relicエージェントを使用すると、インストルメンテーションのカスタムメトリック名を指定できます。 metricNameは、コンポーネントの集計メトリックを決定するために使用されます。次の例は、 metricNameパラメータがJavaエージェントSDK @Traceアノテーションに渡されることを示しています。
@Weavepublic abstract class MQOutboundMessageContext implements OutboundTransportMessageContext {
@Trace(dispatcher = true, metricName="MQTransport") public void send(final TransportSendListener listener) throws TransportException { try { NewRelic.getAgent().getTracedMethod().setMetricName("Message", "MQ", "Produce"); MQHelper.processSendMessage(this, NewRelic.getAgent().getTracedMethod()); } catch (Exception e) { NewRelic.getAgent().getLogger().log(Level.FINE, e, "Unable to set metadata on outgoing MQ message"); }
Weaver.callOriginal(); }
}すべての外部サービスコールを追跡
ヒント
クライアントライブラリのインストルメンテーションの詳細については、関連するAPMエージェントのインストルメンテーションおよびSDKガイドを参照してください。
クライアントインスツルメンテーションとは、お客様のサービスから外部リソースへの呼び出しをカプセル化することです。一般的に、New Relic のエージェントは、HTTP、gRPC、メッセージング、データベースなどのプロトコルでよく使われるクライアントを認識しており、適切なインスツルメンテーションパターンを適用して、それらのクライアントへのコールを外部サービスとして集約します。
NewRelicAPM内の外部サービスダッシュボードの詳細。
あるプロトコルのために独自のクライアントハンドラーを書いていたり、非常に新しいものやややニッチなものを使用していたりすると、New Relicエージェントがクライアントを認識できず、クライアントコールの動作を記録できないことがあります。このため、APM内の外部サービスやデータベースが、サービスに期待されるすべての外部性を表していることを確認する必要があります。
NewRelicAPM内のデータベースプロトコルダッシュボードの詳細。
すべてのサービスの依存関係がここに表示されていることを検証することが重要です。サービスの依存関係が表示されない場合は、APMエージェントがそれに応じて追跡できるように、外部呼び出しをインターセプトするための新しいインストルメンテーションを導入する必要があります。次の例は、エージェントによるキャプチャのためにGolangで外部呼び出しをラップする方法を示しています。
package main
import ( "net/http"
"github.com/newrelic/go-agent/v3/newrelic")
func currentTransaction() *newrelic.Transaction { return nil}
func main() { txn := currentTransaction() client := &http.Client{} request, _ := http.NewRequest("GET", "http://www.example.com", nil) segment := newrelic.StartExternalSegment(txn, request) response, _ := client.Do(request) segment.Response = response segment.End()}他のエージェントAPIの外部コールトレースの例。
エンドポイントのテスト
エンドポイントテストは、サービスインストルメンテーションプログラムに2つの利点を提供します。
- 不具合検出： 単純な真/偽の結果を出すエンドポイントのテストをエンコードすることで、運用チームは個別の不具合を分離し、サービス提供の完全性が損なわれたかどうかを判断することができます。
- ベースライン化： 合成テストやマシンテストは、予測可能な一連の条件を提供するもので、コントロールの観点からサービス提供の一貫性を評価することができます。
New Relicの合成モニタリングは、拡張されたSelenium JavaScript SDKを使用することにより、さまざまなテストタイプを作成する機能を提供します。 Seleniumベースのテストスクリプトが定義されると、NewRelicはスクリプトの実行場所とその頻度を管理します。
NewRelicシンセティックスがダッシュボードを起動します。
シンセティック・テストでは、さまざまなテスト・オプションが用意されており、それぞれが独自の焦点を持っています。詳細については、 シンセティック・モニタリング・ドキュメント をご覧ください。
サービス開発者の観点から、最も頻繁に使用されるモニターの種類はエンドポイントの可用性です。このモニタータイプは、HTTP要求条件をスクリプト化する機能を提供します。これらは、アクセス可能なAPIへのPOSTまたはGETのように単純な場合もあれば、Selenium監視スクリプトが要求を連続して評価してマルチステッププロセスの機能の整合性を確認する複数のステップを含む場合もあります。
実際には、開発者はエンドポイントの可用性と完全性を評価するために、可能な限りシンプルなテストを実装することを検討する必要があります。たとえば、ある通貨グループの現在の為替レートを提供する新しいサービス エンドポイントを作成したとします。これは、JSON オブジェクトの配列を返すエンドポイントでの単純な GET です。
- リクエストの例：
http://example-ip:3000/exchange - 対応例。
[ { "status": [ "quote" ], "_id": "5b9bf97f61c22f4fb5beb5c9", "name": "cdn", "Created_date": "2021-07-12T18:10:07.488Z", "__v": 1 }, { "status": [ "quote" ], "_id": "5b9bfb2a61c22f4fb5beb5ca", "name": "usd", "Created_date": "2021-07-12T18:17:14.224Z", "__v": 0.80 }, { "status": [ "quote" ], "_id": "5b9bfb3261c22f4fb5beb5cb", "name": "eur", "Created_date": "2021-07-12T18:17:22.476Z", "__v": 0.68 }, { "status": [ "quote" ], "_id": "5b9bfb3761c22f4fb5beb5cc", "name": "mex", "Created_date": "2021-07-12T18:17:27.009Z", "__v": 15.97 }]このサービスが運用可能であると見なされるためには、要求に応答するだけでなく、4つの通貨応答も提供する必要があります。現時点ではコンテンツについて心配していません。CDN、USD、EUR、MEXの各通貨について、配列に4つの要素が1つ戻っているという事実だけです。
New Relic のシンセティックモニタリングを使用すると、API テストスクリプトは以下のようになります。
/*** This script checks to see if we get the currency data from the endpoint.*/var assert = require('assert');var myQueryKey = 'secret_key';var options = { uri: 'http://example_ip:3000/exchange', headers: { 'X-Query-Key': myQueryKey, 'Accept': 'application/json' }};
function callback (err, response, body){ var data = JSON.parse(body); var info = body; if (Array.isArray(data)) { if (data.length !== 4) { assert.fail('Unexpected results in API Call, result was ' + JSON.stringify(data)); } }}
$http.get(options, callback);合成スクリプトはNew Relicのインターフェイスで直接設定することができますが、エンドポイントテストをソースリポジトリシステムで管理し、自動化を採用することを強くお勧めします。これにより、お客様のサービスが本番のサービス提供に導入する新しいエンドポイントの依存関係に合わせて、エンドポイントのテストを行うことができます。
価値の実現
サービスインストルメンテーションの影響は、プロセスの監視に投資する意思のある注意のレベルに直接関係します。サービスを監視するプロセスと同様に、可観測性プログラムは、努力への投資に対する見返りの期待について批判的に考える専用のチーム機能を通じて利益を得るでしょう。ここに、組織の投資コストと利益の期待について考えるためのガイダンスがあります。
次のセクションでは、可観測性の実践にサービス計装を組み込むことで期待できる投資と収益を見積もるためのアプローチの概要を説明します。