• English日本語한국어
  • ログイン今すぐ開始

この機械翻訳は参考用に提供されます。

英語版と翻訳版に矛盾がある場合は、英語版が優先されます。詳細については、こちらのページをご覧ください。

問題を作成する

適切なサービス テレメトリを取得する

あなたのサービスが何をするのか考えてみましょう。おそらく、注文を受け取り、注文の整合性を検証する必要があり、その注文を決済機関サービスに伝え、要求者に中継される確認コードを受け取ります。この例では、サービスの機能を分析し、サービスがどのように機能しているかを決定するための十分なテレメトリとコンテキストがあるかどうかを評価するための明確な道筋を示しています。New Relic のエージェントを使用している場合は、このセクションの冒頭の質問に答えるために必要な情報がすべて揃っている必要があります。ただし、特定の実装では追加の計測が必要になる場合があります。

次の質問リストは、インストルメンテーションを通じてテレメトリまたはメタデータ キャプチャを追加する必要がある場所を見つけるのに役立ちます。以下の改善プロセスのセクションでは、サービスの管理に必要なデータを取得する方法について説明します。

インストルメンテーションに関する考察

ベースとなるテレメトリの要件は満たされていますか?

そうでない場合は、そのギャップを文書化し、カスタム設定や追加の計測技術によって解消できるかどうかを評価します。

テレメトリ内で個別のユーザーストーリーを分離することはできますか?

そうでない場合は、エージェントのトレース機能を使って、適切なコンテキストメタデータを持つ個別のユーザーストーリーの呼び出しをキャプチャします。

ユーザーストーリーを起動するパラメータを把握しているか?

そうでない場合は、エージェントSDKでカスタム属性を使用して、トランザクションとスパンにコンテキストを追加します。

ソフトウェアの主要な機能コンポーネントを測定することができますか?

そうでない場合は、インスツルメンテーションSDKを使用して、コードの特定の機能要素に関するベースライン・メトリクスを作成します。(キャッシュルックアップ、処理ルーチン、ユーティリティー関数など)。

自分のコードから外部システムへのクライアントのインタラクションを測定することはできますか?

そうでない場合は、リクエストとレスポンスがコンポーネント レベルの追跡によってキャプチャされていることを確認してください。クライアントの呼び出しが同期していない場合は、処理を正しく表示するために分散トレース機能を実装することを検討してください。

機器のニーズを把握する

まず、何をする必要があるかを具体的に決定する必要があります。ビジネス ニーズを満たすすべてのサービスには、次の質問に答えるのに十分なツールが必要です。今は、どの領域に注力する必要があるかを知るために、答えられる質問と答えられない質問を整理する良い機会です。

  • どのくらいのリクエストがあるのですか?
  • メッセージやHTTPリクエストの送信数はどのくらいですか?
  • どのくらいのリクエストが成功しているのでしょうか?
  • フルリクエストのレスポンスタイムはどのくらいですか?
  • 依存先への呼び出し時の応答時間はどのくらいですか?
  • どのくらいのリクエスト数で、このプロセスはどのくらいのリソースを必要とするのか?
  • 私の失敗点は一体何でしょうか?

インストルメンテーションを構成する

次に、インストルメンテーションの構成を開始します。各 New Relic エージェントは、さまざまな構成オプションを提供します。通常は、インフラストラクチャ ホスト、アプリケーション ランタイム、およびクラウド サービス プロバイダーへの接続内にエージェントを含める標準的なアプローチを定義します。デフォルトのエージェント構成は、広く適用できるように作成されています。

開発者がデプロイメントの適用性に影響を与えるための最良の方法の 1 つは、サービス インスタンスのデフォルト構成オプションをオーバーライドすることです。考慮すべきデフォルトのインスツルメンテーション オプションは次のとおりです。

デフォルトのエージェント設定を上書きする

ヒント

New Relicエージェントは、ランタイム構成にさまざまなオプションを提供します。ランタイムに固有のオプションについては、 APMエージェントの構成ドキュメントを参照してください。

各 New Relic APM エージェントは、デフォルト設定を変更するためのさまざまなオプションを提供します。これを行う最も一貫した場所は、各エージェントのインストールに付随する構成ファイルです。ただし、コマンド ライン パラメーターをサービス インスタンス ランタイムに直接渡すか、環境変数を使用するか、実行時にエージェントの SDK 内の関数を呼び出すことによって、エージェントを構成することもできます。

.NETエージェントの構成オプションは次のとおりです。

サービス機能の分離

「効果的なサービス名の作成」セクションで示したように、インストルメンテーションの主な目的の 1 つは、同様の実行時制約を 1 つの名前付きユニットとしてグループ化するように New Relic エージェントを構成することです。特定の入力セットについては、期待される範囲の測定可能な結果が得られるはずです。これらを名前付きサービス ランタイム コンポーネントにどの程度快適に含めることができるかは、通常の動作を理解し、問題を切り分けるのに大いに役立ちます。

New Relic エージェントは、トランザクションが検出されたときにその名前空間を作成する一連の前提条件を使用して構成されています。これらの前提条件は、エージェント言語ランタイムごとに異なります。Java エージェントがトランザクション名を決定する方法の良い例は、Java エージェントのトランザクション命名ドキュメントにあります。

ただし、エージェント トランザクション命名プロトコルを適用した後でも、ニーズによっては満足のいく結果が得られない場合があります。追加のインストルメンテーションを追加してトランザクションに名前を付け、そのコンテキストを改善することにより、サービスの実行動作の理解を大幅に向上させることができます。

トランザクションの名前付けの目標は、開発者以外にも理解しやすいアプローチでサービス機能を適切にセグメント化する APM トランザクションのビューである必要があります。上のトランザクションの内訳画像は、トランザクションのセグメント化の良い例です。これは、サービスの広範なコードベース内で各トランザクションによって実行される作業量の詳細な追跡を提供するだけでなく、トランザクションの内容を理解できるわかりやすいユーザーフレンドリーな名前を付けたトランザクションも提供します。トランザクションの名前付けと属性の組み込みについて詳しく学ぶときは、技術者以外のデータ観察者でも名前付けのアプローチを利用できるようにしてください。

上の画像のトランザクションの内訳は、トランザクション名のセグメント化の悪い例を示しています。この場合、トランザクション量の約 60% がOperationHandler/handleという名前になります。トランザクション量の割合と名前の一般的な性質の両方から、その名前空間の下にトランザクションの集約が多すぎる可能性があることが示されています。

目的は、以下のような固有の特性が最も少ないトランザクションのグループ化を容易にするトランザクション名を作成することです。

通常の配布イメージは、サービス内でより意図的に名前が付けられたトランザクションを示しています。この場合、Web トランザクションの応答時間はより厳密にグループ化されており、一貫した実行特性が示されています。

カスタムトランザクション名の定義

ヒント

New RelicエージェントのAPIガイドを参照して、ランタイムのトランザクション命名手順を確認してください。

New Relic エージェントのトランザクション ネーミング サービスでは、New Relic エージェント SDK へのSetName(String name)のような API 呼び出しを呼び出す必要があります。各言語ランタイム エージェントには、名前を設定するための独自の構文とオプションがあります。さらに詳しい情報が必要な場合は、以下の例を参照してください。

トランザクション名には最大容量があります。報告されるトランザクション名が多すぎる場合は、それらのトランザクション名をグループ化するルールを作成しようとします。詳細については、メトリック グループ化の問題に関連するエージェントのトラブルシューティング ガイドを参照してください。潜在的なトランザクション名が数千ある場合、トランザクションの命名戦略は、ある程度の特異性を犠牲にする必要があります。

メトリックのグループ化の問題が疑われる場合は、サポート ケースを開いてください。トランザクションの名前付けの問題の原因を特定するために喜んで協力させていただきます。

トランザクションでパラメータを取得

ヒント

エージェント言語のNewRelicエージェントカスタム属性ガイドを参照して、属性カスタマイズのメタデータ拡張オプションを確認してください。

トランザクション名はサービスをセグメント化するための強力な方法であり、その動作をよりよく理解できるようになります。これにより、New Relic UI で機能を直接個別に分離できます。

ただし、トランザクション名を分離することなく、サービスの機能に関する追加のコンテキストを取得したい場合が多くあります。これは、サービスによる属性キャプチャを導入することで実現できます。

name:valueペア属性を追加して、各トランザクションの詳細を装飾できます。属性は、APM トランザクション トレースおよびエラー UI を介して、またはTransactionイベント タイプからのパラメーターの直接クエリを通じて、各トランザクション イベントで使用できます。APM エラー UI で確認できるトランザクション追跡の詳細の例を次に示します。

便利なトランザクション名セグメンテーションを開発した場合は、追加された属性のコンテキストを使用して、予期しない結果につながった入力、コホート、またはセグメントをより深く理解することができます。

APM UI 内でトランザクションのコンテキストを理解できることに加えて、パラメーターを使用すると、トランザクション データを直接クエリしてトランザクションを分析するのに役立ちます。各トランザクションにカスタム属性を追加すると、特定の条件を簡単に分離できます。

パラメータキャプチャアプローチは、SplitやLaunchDarklyなどの機能フラグシステムでも使用できます。この場合、機能フラグの決定ハンドラーを実装するときに、顧客に表示されるバージョンまたは機能を制御するコードのブロックに適用されているフラグコンテキスト(たとえば、 optimized_version = on )をキャプチャすることを検討してください。

たとえば、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 のサービス概要ダッシュボードには、コンポーネント部分 (ガベージ コレクションの実行やデータベース呼び出しなど) ごとに分類されたサービスの複合実行のビューが表示されます。

トランザクション コンポーネント セグメントは、一貫したパフォーマンス動作を示す傾向があります。これを使用して、基本的な動作の変化を検出できます。これは根本的な問題を示している可能性があります。これにより、サービス内で実行されているコードの共通部分を通じて依存関係を見つけることができます。

自社のフレームワークを確実に測定する

ヒント

インストルメンテーションにメトリック名を追加する方法については、特定のAPMエージェントのインストルメンテーションおよびSDKガイドを参照してください。

フレームワーク インストルメンテーションの構文は、サービスが記述されている言語に固有ですが、一般的なアプローチはすべての言語で一貫しています。スタック上での各メソッドまたは関数の実行は、追加のインストルメンテーションを追加する機会となります。

サービスまたはトランザクションの機能にロジックの特定のセグメントが必要な場合は、その呼び出しを New Relic エージェントへのコールバックでラップすることを検討してください。そうすることで、エージェントは個別のコード コンポーネントに入ったことを理解し、その中で消費された時間を集計できるようになります。それに応じてコンポーネント。メトリック名をコールバックに渡すことにより、サービスとトランザクションのコンポーネント セグメント メトリックを作成します。

メトリックの命名オプションは、計測器の言語によって異なりますので、各言語のマニュアルを参照してください。

当社のエージェントでは、インストルメンテーションのカスタム メトリック名を指定できます。metricNameを使用して、コンポーネントの集計指標を決定します。次の例は、Java エージェント SDK @Traceアノテーションに渡されるmetricNameパラメータを示しています。

外部サービス呼び出しを追跡する

ヒント

クライアントライブラリのインストルメンテーションの詳細については、関連するAPMエージェントのインストルメンテーションおよびSDKガイドを参照してください。

クライアント インストルメンテーションとは、サービスから外部リソースへの呼び出しを行うことを指します。一般に、New Relic エージェントは、HTTP、gRPC、メッセージング、およびデータベース プロトコルで一般的なクライアントを認識しており、適切なインストルメンテーション パターンを適用して、それらのクライアントへの呼び出しを外部サービスとして集約します。

プロトコル用に独自のクライアント ハンドラーを作成した場合、または非常に新しいものを使用している場合、エージェントはクライアントを認識せず、クライアント呼び出しの動作を記録できない可能性があります。この目的を達成するには、APM 内の外部サービスとデータベースがサービスに予期されるすべての外部性を表していることを確認する必要があります。

すべてのサービスの依存関係がここに示されていることを検証することが重要です。サービスの依存関係が表示されない場合は、APM エージェントが外部呼び出しを追跡できるように、外部呼び出しをインターセプトするための新しいインスツルメンテーションを導入する必要があります。次の例は、エージェントによるキャプチャのために外部呼び出しを Golang でラップする方法を示しています。

他のエージェントAPIの外部コールトレースの例。

エンドポイントのテスト

エンドポイントテストは、サービスインストルメンテーションプログラムに2つの利点を提供します。

  • 欠陥の検出:単純な true/false 結果を生成するエンドポイントのテストをエンコードすることで、操作で個別の障害を分離し、サービス配信の整合性が損なわれているかどうかを判断できます。

  • ベースライン化: 合成テストやマシンテストは、予測可能な一連の条件を提供するもので、コントロールの観点からサービス提供の一貫性を評価することができます。

    当社の合成モニタリングは、強化された Selenium JavaScript SDK を採用することで、さまざまなタイプのテストを作成する機能を提供します。Selenium ベースのテスト スクリプトが定義されたら、スクリプトの実行場所とその頻度を管理します。総合テストでは、それぞれに独自の焦点を当てたさまざまなテスト オプションが提供されます。詳細については、合成モニタリングのドキュメントを参照してください。

    まず、合成チェック用の意思決定マトリックスを作成する必要があります。合成チェックを作成する必要があるかどうかを判断するのは簡単です。依存関係で最初に障害が発生したことを知りたい場合があります。次の質問のいずれかに「はい」と答えた場合は、専用の総合チェックの作成を検討してください。

  • エンドポイントは顧客向けですか?

  • エンドポイントは新しい依存関係を起動しますか?

  • エンドポイントが別のネットワークインフラ上にあるか?

  • エンドポイントは複数のサービスで共有されているか?

  • エンドポイントは、CDNがサポートするコンテンツオリジンですか?

    次に、エンドポイントの可用性と整合性を評価するために、可能な限り単純なテストの実装を検討する必要があります。たとえば、通貨グループの現在の為替レートを提供する新しいサービス エンドポイントを作成したとします。これは、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 インターフェースで合成スクリプトを直接設定できますが、ソース リポジトリ システム内でエンドポイント テストを維持し、自動化を採用することを強くお勧めします。これにより、エンドポイントのテストには、サービスが実稼働サービスの提供に導入する新しいエンドポイントの依存関係が確実に伴います。

価値を実現する

サービスを監視するプロセスと同様に、可観測性プログラムは、努力への投資に対する期待収益を批判的に考える専用のチーム機能を通じて利益を得ることができます。次のセクションでは、可観測性の実践にサービス インストルメンテーションを組み込むことで予想されるコストとメリットを見積もるアプローチの概要を説明します。

投資

利点

Capture the right data

Capture web telemetry

Copyright © 2024 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.