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

機器のニーズを把握する

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

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

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

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

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

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

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

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

• New Relic .NET SDK APIの使用について
• 環境変数
• 設定ファイルのオプション

サービス機能の分離

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

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

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

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

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

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

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

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

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

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"));

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

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

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

トランザクション名はサービスをセグメント化するための強力な方法であり、その動作をよりよく理解できるようになります。これにより、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 のサービス概要ダッシュボードには、コンポーネント部分 (ガベージ コレクションの実行やデータベース呼び出しなど) ごとに分類されたサービスの複合実行のビューが表示されます。

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

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

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

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

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

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

@Weave
  public 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();
      }

  }

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

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

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

すべてのサービスの依存関係がここに示されていることを検証することが重要です。サービスの依存関係が表示されない場合は、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の外部コールトレースの例。

• Go ExternalSegment
• Java ExternalParameters
• パイソンexternal_trace

エンドポイントのテスト

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

• Defect detection:

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

• Baselining:

  外部監視または機械テストでは、制御の観点からサービス提供の一貫性を評価できる予測可能な一連の条件が提供されます。

  当社の合成モニタリングは、強化された 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 インターフェースで合成スクリプトを直接設定できますが、ソース リポジトリ システム内でエンドポイント テストを維持し、自動化を採用することを強くお勧めします。これにより、エンドポイントのテストには、サービスが実稼働サービスの提供に導入する新しいエンドポイントの依存関係が確実に伴います。