インジェストデータを最適化する

APMエージェントが生成するデータ量は、いくつかの要因によって決定される。

• アプリケーションによって生成される有機トラフィックの量（たとえば、1日に100万回呼び出されるアプリケーションと等しいすべてのものは、1日に1000回呼び出されるアプリケーションよりも多くのデータを生成します）

• 基礎となるトランザクションデータ自体のいくつかの特徴（URLの長さと複雑さ）

• アプリケーションがデータベースクエリーを報告しているかどうか

• アプリケーションに多くの（または任意の）カスタム属性を持つトランザクションがあるかどうか

• アプリケーションのエラー量

• アプリケーションエージェントが分散トレース用に設定されているかどうか

  容量の管理

  アプリケーションへの呼び出しはすべて必要であると想定できますが、アーキテクチャ全体をより効率的にすることは可能です。クライアントによって 10 秒ごとに呼び出されるユーザー プロファイル マイクロサービスがある場合があります。これは、一部のユーザー情報が他のクライアントによって更新された場合の待ち時間を短縮するのに役立ちます。ただし、このサービスへの呼び出し頻度をたとえば 1 分ごとに減らすオプションもあります。

  カスタムアトリビュート

  APM API addCustomParameter への呼び出しを使用して追加され た カスタム属性 は、トランザクション ペイロードに追加の属性を追加します。これらは多くの場合便利ですが、状況が変化すると、データの価値が低下したり、古くなったりする可能性があります。

  Java エージェントは、デフォルトで次のrequest.headersをキャプチャします。

• request.headers.referer

• request.headers.accept

• request.headers.contentLength

• request.headers.host

• request.headers.userAgent

  開発者は addCustomParameter を使用して、より詳細なヘッダーを使用してより多くの情報を取得することもできます。

  APM に関連して使用できる豊富な構成の例については、 Java エージェントのドキュメントを参照してください。

  エラーイベント

  APM がエラーを処理する方法を見つけることで、データの量を減らすことができます。たとえば、現時点では削除できない、無害だが大量のエラーが存在する可能性があります。

  これを行うには、エラーに対して collect 、 ignore 、または mark as expected を使用できます。詳細については、 「APM エラーの管理」を参照してください。

  データベースクエリ

  APM インスタンスの非常に変動しやすい側面の 1 つは、データベース呼び出しと設定構成の数です。 これを支援するために、 データベースクエリ 監視 の詳細度を制御できます。 これらのクエリはTransaction tracesページに表示されます。

  一般的なデータベースクエリの設定変更は以下の通りです。

• クエリ収集を難読化または無効にする代わりに、生のクエリ データを収集します。

• スタック トレースのしきい値を変更します。

• クエリ説明プランの収集をオンにします。

  詳細については、「 トランザクション追跡データベース クエリ ページ」を参照してください。

  イベント制限の設定

  APM およびモバイル エージェントには、収集サイクルごとに報告できるイベントの数に制限があります。制限がない場合、送信されるイベントの数が十分に多いと、アプリケーションまたは New Relic のパフォーマンスに影響を与える可能性があります。制限に達すると、エージェントはイベントのサンプリングを開始し、収集サイクル全体にわたるイベントの表現を提供します。エージェントごとに制限も異なります。

  制限があり、サンプリングの対象となるイベントには次のものが含まれます。

• エージェントAPIを介して報告されたカスタムイベント（たとえば、.NETエージェントのRecordCustomEvent ）

• Mobile

• MobileCrash

• MobileHandledException

• MobileRequest

• Span （分散トレースサンプリングを参照）

• Transaction

• TransactionError

  ほとんどのエージェントには、サンプリングされたトランザクションのイベント制限を変更するための構成オプションがあります。たとえば、Java エージェントは max_samples_storedを使用します。max_samples_stored のデフォルト値は 2000 で、最大値は 10000です。この値は、エージェント インスタンスから 60 秒ごとにレポートできるサンプリング イベントの数を制御します。イベント サンプリング制限の詳細については、 「イベント制限」を参照してください。

  NRQL EXTRAPOLATE演算子を使用して、サンプリングされたイベントを補正できます。

  サンプリングの実行方法を変更する前に、次の点に留意してください。

• レポートするイベントが多いほど、エージェントが使用するメモリも多くなります。

• 通常、エージェントのイベントレポートの制限を上げることなく、必要なデータを取得できます。

• ペイロード サイズの制限は 1MB (10^6 バイト) (圧縮) であるため、イベントの数は依然としてその制限の影響を受ける可能性があります。イベントが削除されているかどうかを確認するには、エージェント ログで 413 HTTP ステータス メッセージを確認してください。

  ログサンプリングレート

  New Relic APM 言語エージェントの新しいバージョンは、ログを New Relic に直接転送できます。場合によっては、各 APM エージェント インスタンスからのロギング スパイクの最大値を制限する必要がある場合があります。

  APMエージェントのログサンプリングの詳細については、ログフォワーダーを参照してください。

  トランザクショントレース

  成長ドライバー

  • 接続サービス数
  • 接続サービスごとの監視対象メソッドコール数

  APMでは、トランザクショントレースによって、アプリケーションのトランザクションやデータベースコールについての、綿密な詳細を記録します。トランザクショントレースのデフォルト設定を編集することができます。

  これは、 トランザクション追跡構成によって高度に構成することもできます。構成可能性のレベルとモードは言語によって異なります。

  サーバーサイドの設定を使用して利用できるトランザクショントレースの設定は、使用するNew Relicエージェントによって異なります。UI には、それぞれの説明が記載されています。UI での設定には、以下のものが含まれる場合があります。

• トランザクショントレーシングと閾値

• 記録レベルと入力フィールドなどの、SQLを記録する

• SQLとスタックトレースの閾値をログする

• SQLクエリプランと閾値

• HTTPコードとエラークラスなどの、エラーの収集

• 遅いクエリのトレース

• スレッドプロファイラー

  ディストリビューティッド（分散）トレーシング

  分散トレース構成には、言語固有の違いがいくつかあります。必要に応じて分散トレースを無効にすることができます。これは Java エージェント newrelic.ymlの例です。

  distributed_tracing:
      enabled: false

  コピー

  これはnode.jsの例です newrelic.js

  distributed_tracing: {
    enabled: false
  }

  コピー

  データ量は、 Infinite Tracing を使用しているかどうかによっても異なります。APM エージェントの標準分散トレース (上記) はトレースの最大 10% をキャプチャしますが、すべてのデータを分析して最も関連性の高いトレースを見つけたい場合は、Infinite Tracing を設定できます。標準の分散トレースに代わるこの機能は、すべての APM 言語エージェントで利用できます。毎月の取り込み量がわずかに増加する可能性がある主なパラメータは次のとおりです。

• トレースオブザーバーの監視を構成する

• スパン属性トレースフィルタを設定する

• ランダムトレースフィルターを構成する

ブラウザエージェントバージョン1211以降の場合、ページによって行われたすべてのネットワーク要求はAjaxRequestイベントとして記録されます。アプリケーション設定UIページの拒否リスト構成オプションを使用して、レコードイベントを記録する要求をフィルタリングできます。このフィルターに関係なく、すべてのネットワークリクエストはメトリックとしてキャプチャされ、AJAXページで利用できます。

拒否リストの使用

リクエストをブロックするには、次の 3 つの方法があります。

• すべてのAjaxRequestイベントの記録をブロックするには、アスタリスク*をワイルドカードとして追加します。

• ドメインへのAjaxRequestイベントの記録をブロックするには、ドメイン名のみを入力します。例： example.com

• 特定のドメインとパスへのAjaxRequestイベントの記録をブロックするには、ドメインとパスを入力します。例： example.com/path

• 拒否リストでは、URLのプロトコル、ポート、サーチ、ハッシュは無視されます。

  追加したフィルターが期待どおりに機能するかどうかを検証するには、フィルターに一致するAjaxRequestイベントに対して NRQL クエリを実行します。

  拒否リストにアクセスする

  アプリケーションがイベントの作成からフィルタリングするURLの拒否リストを更新するには、アプリ設定のUIページに移動します。

1. one.newrelic.com

   に移動し、

   Browser

   をクリックします。

2. アプリを選択します。

3. 左側のナビゲーションで、

   App settings

   をクリックします。

4. Ajax request deny list

   の下に、適用するフィルターを追加します。

5. エージェント設定を更新するには、

   Save application settings

   選択します。

6. 関連する APM エージェントを再起動するか、コピー/ペーストしたブラウザーのインストールを更新して、ブラウザー エージェントを再デプロイします。

   バリデーション

   FROM AjaxRequest SELECT * WHERE requestUrl LIKE `%example.com%`

   コピー

Android

エージェントを呼び出すための呼び出しを含むすべての設定は、 MainActivityクラスのonCreateメソッドで呼び出されます。設定を変更するには、次の2つの方法のいずれかで設定を呼び出します（設定でサポートされている場合）。

NewRelic.disableFeature(FeatureFlag.DefaultInteractions);
NewRelic.enableFeature(FeatureFlag.CrashReporting);
NewRelic.withApplicationToken(NEW_RELIC_TOKEN).start(this.getApplication());

分析設定により、イベント データの収集を有効または無効にできます。 これらのイベントはCrash analysisページに報告され、使用されます。

エージェントのログを多かれ少なかれ冗長になるように構成することもできます。

iOS

Androidと同様に、New RelicのiOS構成では、 機能フラグを有効または無効にできます。

次の機能フラグを設定できます。

クラッシュとエラーの報告

• NRFeatureFlag_CrashReporting
• NRFeatureFlag_HandleExceptionEvents
• NRFeatureFlag_CrashReporting

ディストリビューティッド（分散）トレーシング

• NRFeatureFlag_DistributedTracing

相互作用

• NRFeatureFlag_DefaultInteractions
• NRFeatureFlag_InteractionTracing
• NRFeatureFlag_SwiftInteractionTracing

ネットワーク機能フラグ

• NRFeatureFlag_ExperimentalNetworkInstrumentation
• NRFeatureFlag_NSURLSessionInstrumentation
• NRFeatureFlag_NetworkRequestEvents
• NRFeatureFlag_RequestErrorEvents
• NRFeatureFlag_HttpResponseBodyCapture

詳細については、 機能フラグを参照してください。

インフラストラクチャ エージェント構成ファイルには、 取り込み量を制御する 2 つの方法が含まれています。最も重要な取り込み制御は、サンプリング レートの構成です。調整できる個別のサンプリング レート構成がいくつかあります。正規表現を作成して、 ProcessSample や NetworkSampleなどの特定のコレクターから収集されるものを制御することもできます。

設定可能なサンプリングレート

インフラストラクチャで構成できるサンプリング レートは多数ありますが、これらが最も一般的に使用されます。

プロセスサンプル

プロセス サンプルは、ホスト上で実行中のプロセスに関する情報を送信するため、多くの場合、インフラストラクチャ エージェントからの単一の最も大量のデータ ソースになります。これらはデフォルトでは無効になっていますが、次のように有効にすることができます。

enable_process_metrics: true

これは、 metrics_process_sample_rate を -1に設定するのと同じ効果があります。デフォルトでは、メモリ使用量が少ないプロセスはサンプリングから除外されます。詳細については、 disable-zero-mem-process-filterを参照してください。

include_matching_metricsを構成することで送信するデータの量を制御できます。これにより、メトリック 属性の値に基づいてメトリック データの送信を制限できます。メトリックの属性のいずれかに対してリテラル値または部分値を定義することによって、メトリック データを含めます。たとえば、 process.name が正規表現 ^java に一致するすべてのプロセスの host.process.cpuPercent を送信するように選択できます。

この例では、実行ファイルと名前を使ってプロセスメトリクスを含めています。

include_matching_metrics:             # You can combine attributes from different metrics
    process.name:
      - regex "^java"                   # Include all processes starting with "java"
    process.executable:
      - "/usr/bin/python2"              # Include the Python 2.x executable
      - regex "\\System32\\svchost"     # Include all svchost executables

また、このフィルターはKubernetesの統合にも使用できます。

env:
    - name: NRIA_INCLUDE_MATCHING_METRICS
      value: |
        process.name:
          - regex "^java"
        process.executable:
          - "/usr/bin/python2"
          - regex "\\System32\\svchost"

ネットワークインターフェースフィルタ

この設定では、シンプルなパターンマッチングメカニズムを使用しており、いずれかのパターンに続く特定の文字または数字のシーケンスで始まるインターフェースを探すことができます。

• {name}[other characters]
• [number]{name}[other characters]、ここでindex-1オプションを使用して名前を指定します

network_interface_filters:
  prefix:
    - dummy
    - lo
  index-1:
    - tun

Linuxのデフォルトのネットワークインターフェイスフィルタ。

• dummy 、 lo 、 vmnet 、 sit 、 tun 、 tap 、または veth
• tunまたはを含むネットワークインターフェース tap

Windowsのデフォルトのネットワークインターフェイスフィルタ。

• Loop 、 isatap 、またはで始まるネットワークインターフェイス Local

デフォルトを上書きするには、設定ファイルに独自のフィルタを記述します。

network_interface_filters:
  prefix:
    - dummy
    - lo
  index-1:
    - tun

カスタムアトリビュート

カスタム属性は、 インフラストラクチャ エージェントからのデータに注釈を付けるために使用される他のツールのタグに似たキーと値のペアです。このメタデータを使用して、フィルター セットを構築し、結果をグループ化し、データに注釈を付けることができます。たとえば、マシンの環境 (ステージングまたは運用)、マシンがホストするサービス (ログイン サービスなど)、またはそのマシンを担当するチームを指定できます。

からのカスタム属性の例 newrelic.yml

custom_attributes:
  environment: production
  service: billing
  team: alpha-team

Kubernetes のような複雑な分散システムは、短時間で大量のテレメトリを生成する可能性があります。Kubernetes でのデータ取り込みを管理するには、いくつかの優れたアプローチがあります。K8s デプロイメントでコードとして可観測性を使用している場合、これらは非常に簡単になります。

取り込みの削減について決定を下す前に、この Kubernetes データ取り込み分析ダッシュボードをインストールすることを強くお勧めします。このダッシュボードを取得するには、 「インフラストラクチャ統合クイックスタート」を参照してください。

スクレイプ間隔

可観測性の目標に応じて、デフォルトの時間は 15 秒であるスクレイピング間隔を調整することを検討してください。Kubernetes クラスター エクスプローラーは 45 秒ごとにのみ更新されます。Kubernetes データの主な用途が KCE 視覚化のサポートである場合は、スクレイピング間隔を 20 秒に変更することを検討してください。15 代から 20 代への変化は大きな影響を与える可能性があります。

これの管理の詳細については、 Helm 統合のスクレイピング間隔に関するドキュメント を参照してください。

名前空間のフィルタリング

Kubernetes 統合バージョン 3 以降では、ラベルを付けることでスクレイピングされる名前空間をフィルタリングできます。デフォルトでは、すべての名前空間がスクレイピングされます。

Kubernetes と同じ方法で namespaceSelector を使用します。ラベルに一致する名前空間のみを含めるには、 newrelic-infrastructure セクションの values-newrelic.yamlに次の内容を追加して、 namespaceSelector を変更します。

common:
  config:
    namespaceSelector:
      matchLabels:
        key1 : "value1"

この例では、ラベルnewrelic.com/scrapeがtrueに設定されている名前空間のみがスクレイプされます。

global:
  licenseKey: _YOUR_NEW_RELIC_LICENSE_KEY_
  cluster: _K8S_CLUSTER_NAME_

# ... Other settings as shown above

# Configuration for newrelic-infrastructure
newrelic-infrastructure:
  # ... Other settings as shown above
  common:
    config:
      namespaceSelector:
        matchLabels:
          newrelic.com/scrape: "true"

Kubernetes 一致式を使用して、名前空間を含めたり除外したりすることもできます。有効な演算子は次のとおりです。

• の
• ありませんで
• 存在する
• 存在しない

matchExpressionsセクションの一般的な構造は、次の行の 1 つまたは複数です。

{key: VALUE, operator: OPERATOR, values: LIST_OF_VALUES}

完全な例を次に示します。

common:
  config:
    namespaceSelector:
      matchExpressions:
      - {key: newrelic.com/scrape, operator: NotIn, values: ["false"]}

この例では、ラベルnewrelic.com/scrapeがfalseに設定された名前空間が除外されます。

global:
  licenseKey: _YOUR_NEW_RELIC_LICENSE_KEY_
  cluster: _K8S_CLUSTER_NAME_

# ... Other settings as shown above

# Configuration for newrelic-infrastructure
newrelic-infrastructure:
  # ... Other settings as shown above
  common:
    config:
      namespaceSelector:
        matchExpressions:
        - {key: newrelic.com/scrape, operator: NotIn, values: ["false"]}

チャートの README ファイルで可能な設定の完全なリストを参照してください。

どの名前空間が除外されているかを知るにはどうすればよいですか？ [#excluded-namespaces]

K8sNamespaceサンプルのおかげで、クラスター内のすべての名前空間が一覧表示されます。nrFiltered属性は、名前空間に関連するデータをスクレイプするかどうかを決定します。

このクエリを使用して、監視されているネームスペースを確認します。

FROM K8sNamespaceSample SELECT displayName, nrFiltered
WHERE clusterName = INSERT_NAME_OF_CLUSTER SINCE
2 MINUTES AGO

除外された名前空間からどのデータが破棄されていますか？ [#namespaces-discarded-data]

次のサンプルは、除外された名前空間では使用できません。

• K8sContainerSample
• K8sDaemonsetSample
• K8sDeploymentSample
• K8sEndpointSample
• K8sHpaSample
• K8sPodSample
• K8sReplicasetSample
• K8sServiceSample
• K8sStatefulsetSample
• K8sVolumeSample

Kubernetes 状態メトリクス

Kubernetes cluster explorerで必要なのは、以下のkube state metrics（KSM）のみです。

• コンテナデータ

• クラスターデータ

• ノードデータ

• ポッドデータ

• ボリュームデータ

• APIサーバーデータ

  1

• コントローラマネージャデータ

  1

• ETCDデータ

  1

• スケジューラデータ

  1

¹管理されたKubernetes環境（EKS、GKE、AKSなど）では収集されません

以下の一部を無効化することをご検討ください。

• デーモンセットデータ

• デプロイメントデータ

• エンドポイントデータ

• 名前空間データ

• ReplicaSetデータ

  2

• サービスデータ

• StatefulSetデータ

²デフォルトのアラートで使用：「ReplicaSetに必要な数のポッドがありません」

マニフェストの状態メトリックを更新する例（デプロイメント）

$
[spec]
$
  [template]
$
    [spec]
$
      [containers]
$
        [name=kube-state-metrics]
$
        [args]
$
        #- --collectors=daemonsets
$
        #- --collectors=deployments
$
        #- --collectors=endpoints
$
        #- --collectors=namespaces
$
        #- --collectors=replicasets
$
        #- --collectors=services
$
        #- --collectors=statefulsets

マニフェストの状態メトリックを更新する例（ClusterRole）

$
[rules]
$
# - apiGroups: ["extensions", "apps"]
$
#   resources:
$
#   - daemonsets
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: ["extensions", "apps"]
$
#   resources:
$
#   - deployments
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: [""]
$
#   resources:
$
#   - endpoints
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: [""]
$
#   resources:
$
#   - namespaces
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: ["extensions", "apps"]
$
#   resources:
$
#   - replicasets
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: [""]
$
#   resources:
$
#   - services
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: ["apps"]
$
#   resources:
$
#   - statefulsets
$
#   verbs: ["list", "watch"]

nri-bundleチャートの構成lowDataMode

Helm チャートは、詳細情報を削除して取り込むデータ量を削減するオプションをサポートしています。これを有効にするには、 nri-bundle グラフで global.lowDataMode を true に設定します。

lowDataMode nri-bundleチャートの3つの特定のコンポーネントに影響します。

1. インフラストラクチャエージェントの間隔を15 }秒から30秒に増やします。
2. Prometheus OpenMetricsの統合では、以下のHelmドキュメントに示されているように、いくつかのメトリックが除外されます。
3. ラベルと注釈の詳細はログから削除されます。

この構成の詳細については、 Helmドキュメントを参照してください。

New Relic のオンホスト統合は、Postgresql、MySQL、Kafka、RabbitMQ などのサードパーティ サービスの多様な統合セットを表します。このドキュメントの範囲内ですべての最適化手法を提供することは不可能ですが、これらの手法は一般的に適用されます。

• サンプリングレートの管理

• コレクションの幅を増減できる構成部分を管理します

• カスタムクエリを可能にする構成部分を管理します。

• すべてのオンホスト統合データに適用するインフラストラクチャ エージェントのカスタム属性を管理します。

  いくつかの例を使って説明します。

  PostgreSQLの統合

  成長ドライバー

  • 監視対象テーブル数
  • 監視対象指標数

  PostgreSQLのオンホスト統合設定では、データ量の管理に役立つこれらの調整可能な設定が提供されています。

• interval: デフォルトは 15 秒です

• COLLECTION_LIST: 監視するテーブルのリスト (ALL を使用してすべてを監視します)

• COLLECT_DB_LOCK_METRICS: dblockメトリクスを収集

• PGBOUNCER: pgbouncerメトリクスを収集

• COLLECT_BLOAT_METRICS: 肥大化指標を収集する

• METRICS: メトリックのみを収集するには、 trueに設定します

• INVENTORY: trueに設定すると、インベントリの収集のみが有効になります

• CUSTOM_METRICS_CONFIG: カスタム コレクション クエリを含む構成ファイル

  Sample config:

  integrations:
    - name: nri-postgresql
      env:
        USERNAME: postgres
        PASSWORD: pass
        HOSTNAME: psql-sample.localnet
        PORT: 6432
        DATABASE: postgres
        COLLECT_DB_LOCK_METRICS: false
        COLLECTION_LIST: '{"postgres":{"public":{"pg_table1":["pg_index1","pg_index2"],"pg_table2":[]}}}'
        TIMEOUT:  10
      interval: 15s
      labels:
        env: production
        role: postgresql
      inventory_source: config/postgresql

  コピー

  Kafkaとの統合

  成長ドライバー

  • クラスタ内のブローカー数
  • クラスタ内のトピック数

  Kafkaのオンホスト統合設定では、データ量の管理に役立つ、これらの調整可能な設定が提供されています。

• interval: デフォルトは 15 秒です

• TOPIC_MODE: 収集するトピックの数を決定します。オプションはall 、 none 、 listまたはregexです。

• METRICS: メトリックのみを収集するには、 trueに設定します

• INVENTORY: trueに設定すると、インベントリの収集のみが有効になります

• TOPIC_LIST: 監視するトピック名の JSON 配列。topic_mode が list に設定されている場合にのみ有効です。

• COLLECT_TOPIC_SIZE: メトリクス トピック サイズを収集します。オプションはtrueまたはfalseで、デフォルトはfalseです。

• COLLECT_TOPIC_OFFSET:メトリクス トピック オフセットを収集します。オプションはtrueまたはfalseで、デフォルトはfalseです。

  トピック レベルのメトリクス、特にオフセットの収集は、収集に多くのリソースを消費する可能性があり、データ量に影響を与える可能性があります。新しい Kafka トピックをクラスターに追加するだけで、クラスターの取り込み量が 1 桁増加する可能性があります。

  MongoDBとの連携

  成長ドライバー

  • 監視対象データベース数

  MongoDBとの連携では、このような調整可能な設定が用意されており、データ量の管理に役立てることができます。

• interval: デフォルトは 15 秒です

• METRICS: メトリックのみを収集するには、 trueに設定します

• INVENTORY: trueに設定すると、インベントリの収集のみが有効になります

• FILTERS: データベース名からコレクション名の配列への JSON マップ。空の場合、デフォルトですべてのデータベースとコレクションになります。

  使用するオンホスト統合では、デフォルトですべてのデータベースからメトリクスを収集することになっている FILTERS のようなパラメータに注意することが重要です。これは、監視の優先順位を使用して収集されたデータを合理化できる領域です。

  Example configuration with different intervals for METRIC and INVENTORY:

  integrations:
    - name: nri-mongodb
      env:
        METRICS: true
        CLUSTER_NAME: my_cluster
        HOST: localhost
        PORT: 27017
        USERNAME: mongodb_user
        PASSWORD: mongodb_password
      interval: 15s
      labels:
        environment: production
  
    - name: nri-mongodb
      env:
        INVENTORY: true
        CLUSTER_NAME: my_cluster
        HOST: localhost
        PORT: 27017
        USERNAME: mongodb_user
        PASSWORD: mongodb_password
      interval: 60s
      labels:
        environment: production
      inventory_source: config/mongodb

  コピー

  Elasticsearchの統合

  成長ドライバー

  • クラスタ内のノード数
  • クラスタ内のインデックス数

  Elasticsearchとの連携では、このような調整可能な設定が用意されており、データ量の管理に役立てることができます。

• interval: デフォルトは 15 秒です

• METRICS: メトリックのみを収集するには、 trueに設定します

• INVENTORY: trueに設定すると、インベントリの収集のみが有効になります

• COLLECT_INDICES: インデックス メトリックを収集するかどうかを通知します。

• COLLECT_PRIMARIES: プライマリ メトリックを収集するかどうかを示します。

• INDICES_REGEX: 収集するインデックスをフィルタリングします。

• MASTER_ONLY: 選択されたマスターのみでクラスタ メトリックを収集します。

  Example configuration with different intervals for METRICS and INVENTORY:

  integrations:
    - name: nri-elasticsearch
      env:
        METRICS: true
        HOSTNAME: localhost
        PORT: 9200
        USERNAME: elasticsearch_user
        PASSWORD: elasticsearch_password
        REMOTE_MONITORING: true
      interval: 15s
      labels:
        environment: production
  
    - name: nri-elasticsearch
      env:
        INVENTORY: true
        HOSTNAME: localhost
        PORT: 9200
        USERNAME: elasticsearch_user
        PASSWORD: elasticsearch_password
        CONFIG_PATH: /etc/elasticsearch/elasticsearch.yml
      interval: 60s
      labels:
        environment: production
      inventory_source: config/elasticsearch

  コピー

  JMXの統合

  成長ドライバー

  • に記載されている指標 COLLECTION_CONFIG

  JMX 統合は本質的に汎用的です。これにより、任意の JMX インスタンスからメトリクスを取得できます。この統合によって収集される内容を制御できます。一部の企業では、New Relic 環境の JMX メトリクスが、収集されたすべてのデータの比較的高い割合を占めています。

  JMX統合は、データ量の管理に役立つこれらの調整可能な設定を提供します。

• interval: デフォルトは 15 秒です

• METRICS: メトリックのみを収集するには、 trueに設定します

• INVENTORY: trueに設定すると、インベントリの収集のみが有効になります

• METRIC_LIMIT: エンティティごとに収集できるメトリックの数。この制限を超えると、エンティティは報告されません。0 の制限は、制限がないことを意味します。

• LOCAL_ENTITY: ローカル エンティティのすべてのメトリックを収集します。localhost を監視する場合にのみ使用されます。

• COLLECTION_FILES: メトリック コレクション定義ファイルへの完全なファイル パスのコンマ区切りリスト。オンホスト インストールの場合、デフォルトの JVM メトリック コレクション ファイルは/etc/newrelic-infra/integrations.d/jvm-metrics.ymlにあります。

• COLLECTION_CONFIG: JSON としてのメトリクス コレクションの構成。

  取り込まれるデータ量を最も左右するのはCOLLECTION_CONFIGエントリです。スクレイピングしている JMX モデルを理解すると、最適化に役立ちます。

  COLLECTION_CONFIG JVM メトリックの例

  COLLECTION_CONFIG='{"collect":[{"domain":"java.lang","event_type":"JVMSample","beans":[{"query":"type=GarbageCollector,name=*","attributes":["CollectionCount","CollectionTime"]},{"query":"type=Memory","attributes":["HeapMemoryUsage.Committed","HeapMemoryUsage.Init","HeapMemoryUsage.Max","HeapMemoryUsage.Used","NonHeapMemoryUsage.Committed","NonHeapMemoryUsage.Init","NonHeapMemoryUsage.Max","NonHeapMemoryUsage.Used"]},{"query":"type=Threading","attributes":["ThreadCount","TotalStartedThreadCount"]},{"query":"type=ClassLoading","attributes":["LoadedClassCount"]},{"query":"type=Compilation","attributes":["TotalCompilationTime"]}]}]}'

  コピー

  NonHeapMemoryUsage.Initなど、その構成から1つのエントリを省略すると、収集されるデータ量全体に具体的な影響があります。

  COLLECTION_CONFIG Tomcat メトリクスの例

  COLLECTION_CONFIG={"collect":[{"domain":"Catalina","event_type":"TomcatSample","beans":[{"query":"type=UtilityExecutor","attributes":["completedTaskCount"]}]}]}

  コピー

  その他のオンホストインテグレーション

  その他にも、収集の最適化に役立つ設定オプションを持つオンホスト統合が多数あります。よく使われるものをいくつか紹介します。

• NGINX

• MySQL

• Redis

• Apache

• RabbitMQ

  これは良い スタート地点 もっと学ぶために。

このセクションでは、Kentikのktranslateエージェントに依存するNewRelicのネットワークパフォーマンスモニタリングに焦点を当てます。このエージェントは非常に洗練されており、主要な最適化を行う前に、高度な構成ドキュメントを完全に理解することが重要です。構成オプションは次のとおりです。

• mibs_enabled: KTranslate Docker イメージがポーリングするすべてのアクティブな MIB の配列。discovery_add_mibs属性がtrueの場合、このリストは検出中に自動的に生成されます。ここにリストされていない MIB は、構成ファイル内のどのデバイスでもポーリングされません。MIB-NAME.tableName構文を使用して、MIB ファイルで SNMP テーブルを直接指定できます。例: HOST-RESOURCES-MIB.hrProcessorTable .

• user_tags: key:value ペアの属性で、デバイスにより多くのコンテキストを提供します。このレベルのタグは、構成ファイル内のすべてのデバイスに適用されます。

• devices: フローを監視するデバイスのセクション一覧

• traps: SNMP トラップで監視する IP とポートを構成します (デフォルトは127.0.0.1:1162です)。

• discovery: エンドポイントを検出する方法を構成します。このセクションでは、次のパラメーターがスコープを増減するために最も効果的です。

  • cidrs: CIDR 表記のターゲット IP 範囲の配列。
  • ports: SNMP ポーリング中にスキャンするターゲット ポートの配列。
  • debug: 検出中にデバッグ レベルのログを有効にするかどうかを示します。デフォルトでは、 false
  • default_communities: SNMP ポーリング中にスキャンする SNMPv1/v2c コミュニティ ストリングの配列。この配列は順番に評価され、検出は最初に通過したコミュニティを受け入れます。

  可観測性のニーズに見合う価値を生み出さないデータのフィルタリングをサポートするために、 global.match_attributes.{}またはdevices.<deviceName>.match_attributes.{}属性マップを設定できます。

  これにより、データを New Relic に送信する前に KTranslate レベルでフィルタリングが提供され、インターフェイスなどの監視をきめ細かく制御できるようになります。

  詳細については、ネットワークパフォーマンス監視の構成を参照してください。

ログは、通常、独自のルーティングルールと変換ルールを備えた専用の転送レイヤーを介してログをルーティングするという点で、テレメトリの最も柔軟なソースの1つです。さまざまなフォワーダーがあるため、最も一般的に使用されるフォワーダーに焦点を当てます。

• APM言語エージェント（最近のバージョン）

• Fluentd

• Fluentbit

• New Relic インフラエージェント (Fluentbit 内蔵)

• Logstash

  APMエージェントログのサンプリング

  New Relic 言語エージェントの最新バージョンは、ログを New Relic に直接転送できます。各 APM エージェント インスタンスからのロギングのスパイクがどのくらい大きくなるかについて、いくつかの制限を管理することが必要な場合があります。

  環境変数 NEW_RELIC_APPLICATION_LOGGING_FORWARDING_MAX_SAMPLES_STOREDを使用してサンプリングを有効にし、APM エージェントのログ キューに保存されるログの最大数を指定して構成できます。これはカスタム優先キューに基づいて動作し、すべてのログ メッセージに優先順位を与えます。トランザクション内で発生したログには、トランザクションの優先順位が与えられます。

  ログのキューは、優先順位とログの到着時期に基づいて並べ替えられます。優先度の高いものが最初に設定され、必要に応じて最新のログが優先されます。ログは個別にキューに追加され (トランザクション内のログも含めて)、制限に達すると、キューの最後にあるログが押し出され、新しいログが優先されます。

  以下のリソース セクションには、ログ ボリュームを簡単な方法で追跡するのに役立つ クイックスタート ダッシュボード があります。ログ量を追跡すると、可観測性のニーズに合わせてサンプリング レートを調整または無効にすることができます。

  FluentdまたはFluentbitでのフィルターの構成

  ほとんどの一般的なフォワーダーは、フィルタリングや変換を含む、かなり完全な ルーティング ワークフロー を提供します。当社のインフラストラクチャ エージェントは、不要なログをフィルタリングするための非常にシンプルなパターンを提供します。

  レコードをフィルタリングするための正規表現。tail 、 systemd 、 syslog 、および tcp (形式 noneの場合のみ) ソースでのみサポートされます。このフィールドは、Unix システムの grep -E と同様の方法で機能します。たとえば、キャプチャされている特定のファイルについて、次を使用して WARN または ERROR を含むレコードをフィルタリングできます。

  - name: only-records-with-warn-and-error
      file: /var/log/logFile.log
      pattern: WARN|ERROR

  コピー

  有益なフィルタリングまたは解析を行う Fluentbit 用の Fluentd 構成を事前に作成している場合は、それらをログ構成にインポートできます。これを行うには、 logging.d フォルダー内の任意の .yaml ファイルで config_file パラメーターと parsers パラメーターを使用します。

• config_file: 既存の Fluent Bit 設定ファイルへのパス。 重複するソースがあると、New Relic の

  ログ管理

  でメッセージが重複します。

• parsers_file：既存のFluentBitパーサーファイルへのパス。

  次のパーサー名が予約されています： rfc3164 、 rfc3164-local 、およびrfc5424 。

  データ パイプラインのログに属性またはタグを挿入し、変換を実行する方法を学習すると、New Relic ドロップ ルールを使用してダウンストリーム機能をドロップするのに役立ちます。ソースに関するメタデータでログを強化することで、バックエンドに何をドロップするかについて一元的かつ可逆的な決定を下すことができます。少なくとも、次の属性が何らかの形式でログに存在することを確認してください。

• チーム

• 環境(dev/stage/prod)

• アプリケーション

• データセンター

• ログレベル

  以下は、ルーティングとフィルタリングの詳細なリソースです。

• Fluentdの一般的なフィルタとルーティングのパターン

• Fluentbitデータパイプライン

• New Relic インフラストラクチャエージェントによるログの転送

  インフラストラクチャエージェントのデフォルトの属性セットを調整する

  インフラストラクチャ エージェントは、ホストに追加されたカスタム タグを含むいくつかの属性をデフォルトで追加します。構成では、New Relic に aws.[attributename]の形式で表示される多数の AWS タグなど、それ以外の多くのタグが取り込まれる可能性があります。これらの属性は重要であるため、計画された構成変更と比較して、視覚化、分析、アラートのニーズを評価することを強くお勧めします。たとえば、Kubernetes クラスターからのログは、次のようなメタデータがなければ役に立ちません。

• cluster_name

• pod_name

• container_name

• node_name

New Relic には、Prometheus メトリクスを New Relic に送信するための 2 つの主要なオプションが用意されています。メトリクスの取り込みを管理するためのベスト プラクティスは、主に 2 番目のオプションである Prometheus OpenMetrics 統合 (POMI) に焦点を当てています。これは、このコンポーネントが New Relic によって作成されたためです。

オプション1： Prometheusリモート書き込み統合

Prometheus サーバーのスクレイピング構成オプションについては、 「Prometheus config docs」を参照してください。これらのスクレイピング構成により、Prometheus サーバーによってどのメトリクスが収集されるかが決まります。remote_write パラメータを設定すると、収集したメトリクスを New Relic Metric API 経由で New Relic データベース (NRDB) に書き込むことができます。

オプション2： Prometheus OpenMetrics統合（POMI）

POMI は、動的に検出された Prometheus エンドポイントと静的な Prometheus エンドポイントの両方からメトリクスを取得するスタンドアロン統合です。次に、POMI は、New Relic Metric API を介してこのデータを NRDB に送信します。この統合は、現在 Prometheus サーバーを実行していないお客様にとって理想的です。

POMI：スクレープレーベル

POMI は、デフォルトでラベルまたはアノテーション prometheus.io/scrape=true を含む Prometheus エンドポイントを検出します。これは、クラスターにデプロイされているものによっては、多数のエンドポイントになる可能性があるため、大量のメトリクスが取り込まれる可能性があります。

scrape_enabled_label パラメータをカスタムのものに変更することをお勧めします（例:newrelic/scrape)、データの取り込みが最も重要な場合には、Prometheus エンドポイントに選択的にラベルを付ける必要があります。

最新のリファレンス設定については、 nri-prometheus-latest.yamlを参照してください。

POMI config parameter:

# Label used to identify scrapable targets. 
# Defaults to "prometheus.io/scrape"
  scrape_enabled_label: "prometheus.io/scrape"

POMI は、デフォルトでノードレベルで公開されている Prometheus エンドポイントを検出します。これには通常、Kubelet と cAdvisor からのメトリクスが含まれます。New Relic Kubernetes Daemonset を実行している場合は、POMI が重複したメトリクスを収集しないように require_scrape_enabled_label_for_nodes: true を設定することが重要です。

New Relic Kubernetes Daemonsetの対象となるエンドポイントについては、 GitHubのKubernetesREADMEを参照してください。

POMI: ノードのラベルをスクレイプする

POMI は、デフォルトでノードレベルで公開されている Prometheus エンドポイントを検出します。これには通常、Kubelet と cAdvisor からのメトリクスが含まれます。New Relic Kubernetes Daemonset を実行している場合は、POMI が重複したメトリクスを収集しないように require_scrape_enabled_label_for_nodes: true を設定することが重要です。

New Relic Kubernetes Daemonsetの対象となるエンドポイントについては、 GitHubのKubernetesREADMEを参照してください。

POMIコンフィグパラメーター

# Whether k8s nodes need to be labeled to be scraped or not. 
# Defaults to false.
  require_scrape_enabled_label_for_nodes: false

POMI：との共存 nri-kubernetes

New RelicのKubernetes統合は、箱から出してすぐに多くのメトリックを収集します。ただし、Kubernetesクラスターから利用可能なすべてのメトリックを収集するわけではありません。

POMI 設定には、 New Relic Kubernetesがすでに Kube State Metrics から収集しているメトリックのサブセットの disable メトリック コレクションを表示する、次のようなセクションがあります。

Kubelet と cAdvisor のメトリクスが重複しないように require_scrape_enabled_label_for_node: true を設定することも非常に重要です。

POMI config parameters:

transformations:
    - description: "Uncomment if running New Relic Kubernetes integration"
      ignore_metrics:
        - prefixes:
          - kube_daemonset_
          - kube_deployment_
          - kube_endpoint_
          - kube_namespace_
          - kube_node_
          - kube_persistentvolume_
          - kube_persistentvolumeclaim_
          - kube_pod_
          - kube_replicaset_
          - kube_service_
          - kube_statefulset_

POMI：リクエスト/リミット設定

POMIを実行するときは、約500kDPMを生成するクラスターに次のリソース制限を適用することをお勧めします。

• CPU制限：1コア（1000m）
• メモリ制限：1Gb 1024（1G）

POMI にクラスターから十分なリソースを提供するには、CPU とメモリのリソース要求を設定する必要があります。これを非常に低い値に設定します (例:cpu: 50m) により、クラスター リソースが「ノイジー ネイバー」によって消費される可能性があります。

POMI config parameter:

spec:
  serviceAccountName: nri-prometheus
  containers:
  - name: nri-prometheus
    image: newrelic/nri-prometheus:2.2.0
    resources:
      requests:
        memory: 512Mi
        cpu: 500m
      limits:
        memory: 1G
        cpu: 1000m

POMI：DPMとカーディナリティの推定

カーディナリティはGBインジェストあたりの請求額とは直接関係ありませんが、New Relicはカーディナリティと1分あたりのデータポイントについて一定のレート制限を維持しています。Prometheus クラスタからカーディナリティと DPM を可視化できることは、非常に重要なことです。

すでに Prometheus Server を実行している場合は、 POMI または remote_writeを有効にする前に、DPM とカーディナリティの推定を実行できます。

Data points per minute (DPM):

rate(prometheus_tsdb_head_samples_appended_total[10m]) * 60

Top 20 metrics (highest cardinality):

topk(20, count by (<DoNotTranslate>**name**</DoNotTranslate>, job)({__name__=~".+"}))

一部の New Relic クラウド統合は、クラウド プロバイダーの API からデータを取得します。この実装では、AWS CloudWatch、Azure Monitor、GCP Stackdriver などのモニタリング API からデータが収集され、特定のサービスの API からインベントリ メタデータが収集されます。

他のクラウド統合は、AWS Kinesisなどのストリーミングサービスを介してプッシュされるストリーミングメトリック（または「プッシュ」メトリック）からデータを取得します。

ポーリングAPIベースの統合

クラウド統合からのより多くのまたはより少ないデータをレポートしたい場合、またはクラウド アカウントの制限レートやスロットル制限に達しないようにクラウド プロバイダーの API の使用を制御する必要がある場合は、構成設定を変更して変更できます。報告されるデータの量。主なコントロールは次の 2 つです。

• ポーリング周波数の変更

• データの報告内容の変更

  投票頻度の変更を希望するビジネス上の理由の例としては、以下のようなものがあります。

• Billing

  : AWS CloudWatch の請求を管理する必要がある場合は、ポーリング頻度を下げることをお勧めします。 これを実行する前に、クラウドインテグレーションに設定されているアラート条件がこの削減の影響を受けないことを確認してください。

• New services

  : 新しいサービスや設定をデプロイしていて、より頻繁にデータを収集したい場合は、ポーリング頻度を一時的に増やすことが必要になる場合があります。

  注意

  統合のコンフィギュレーション設定を変更すると、アラート条件やチャートトレンドに影響を与える場合があります。

  詳細については、「 ポーリングの構成」を参照してください。

  「ストリーミング」または「プッシュ」メトリック

  API ポーリングを使用する代わりに、 ストリーミング サービスを 介してデータをプッシュするオプションを提供するクラウド統合が増えており、これにより遅延が大幅に削減されます。一部のユーザーが気づいている問題の 1 つは、サンプリング レートを構成できないため、音量の制御がそれほど簡単ではないことです。

  データを削除するための New Relic ルールは、ボリュームが大きすぎるストリーミング メトリクスをフィルタリングして除外する主な方法です。ただし、ストリーム量を制限するためにクラウドプロバイダー側でできることがいくつかあります。

  たとえば、AWS では、条件キーを使用して CloudWatch* 名前空間へのアクセスを制限できます。

  次のポリシーは、ユーザーがMyCustomNamespaceという名前空間でのみメトリックを公開するように制限します。

  {
    "Version": "2012-10-17",
    "Statement": {
      "Effect": "Allow",
      "Resource": "*",
      "Action": "cloudwatch:PutMetricData",
      "Condition": {
        "StringEquals": {
          "cloudwatch:namespace": "MyCustomNamespace"
        }
      }
    }
  }

  コピー

  次のポリシーでは、ユーザーはCustomNamespace2を除く任意の名前空間でメトリックを公開できます:

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Resource": "*",
        "Action": "cloudwatch:PutMetricData"
      },
      {
        "Effect": "Deny",
        "Resource": "*",
        "Action": "cloudwatch:PutMetricData",
        "Condition": {
          "StringEquals": {
            "cloudwatch:namespace": "CustomNamespace2"
          }
        }
      }
    ]
  }

  コピー

すべての New Relic ドロップ ルールは、同じバックエンド データ モデルと API によって実装されます。当社のログ管理は、ドロップ ルールの作成と監視を非常に簡単にする強力な UI を提供します。

以前、このチュートリアル シリーズでは、特定のデータを非推奨にする方法を示すいくつかの演習を実行することで、テレメトリの優先順位付けについて説明しました。この例をもう一度見てみましょう。

Omit debug logs (knowing they can be turned on if there is an issue) (saves 5%)

方法1：ログUI

• ログUIのフィルターを使用して気になるログを特定します： level: DEBUG 。

• ドロップしたいログが見つかることを確認してください。

• level:debugやlog_level:Debugなどの代替構文を確認してください。これらのバリエーションは一般的です。

• Manage data

  の下で

  Drop filters

  をクリックし、「デバッグ ログを削除」という名前のフィルターを作成して有効にします。

• ルールが機能することを確認します。

方法2: 弊社のNerdGraph APIを利用する。

• 関連する NRQL クエリを作成します。

  SELECT count(*) FROM Log WHERE `level` = 'DEBUG'

  コピー

• 削除したいログが見つかったことを確認してください。

• 属性名と値のバリエーションを確認してください ( DebugとDEBUG )。

• 以下のNerdGraph文を実行し、動作することを確認します。

mutation {
  nrqlDropRulesCreate(
    accountId: YOUR_ACCOUNT_ID
    rules: [
      {
        action: DROP_DATA
        nrql: "SELECT * FROM Log WHERE `level` = 'DEBUG'"
        description: "Drops DEBUG logs.  Disable if needed for troubleshooting."
      }
    ]
  ) {
    successes {
      id
    }
    failures {
      submitted {
        nrql
      }
      error {
        reason
        description
      }
    }
  }
}

推奨事項を実装しましょう： Drop process sample data in DEV environments 。

• 関連するクエリを作成します。

  SELECT * FROM ProcessSample WHERE `env` = 'DEV'

  コピー

• ドロップするプロセスサンプルが見つかることを確認してください。

• ENV や Environmentなど、 env の他のバリエーションがないか確認してください。

• Dev や Developmentなどのさまざまな DEV を確認します。

• NerdGraph APIを使用して、以下のステートメントを実行し、動作を確認してください。

  mutation {
    nrqlDropRulesCreate(
      accountId: YOUR_ACCOUNT_ID
      rules: [
        {
          action: DROP_DATA
          nrql: "SELECT * FROM ProcessSample WHERE `env` = 'DEV'"
          description: "Drops ProcessSample from development environments"
        }
      ]
    ) {
      successes {
        id
      }
      failures {
        submitted {
          nrql
        }
        error {
          reason
          description
        }
      }
    }
  }

  コピー

多くの場合、冗長なカバレッジでデータを削減することで、データ使用量を削減できます。たとえば、AWS RDS 統合と、SQL データベースを監視する New Relic オンホスト統合 ( nri-mysql や nri-postgresqlなど) の 1 つが実行されている環境では、重複するメトリクスの一部を破棄できる場合があります。

たとえば、次のようなクエリを実行できます。

FROM Metric select count(*) where metricName like 'aws.rds%' facet metricName limit max

これにより、パターンに一致するすべての metricName 値が表示されます。

結果から、パターン aws.rds.cpu%のメトリクスが大量にあることがわかります。他のインストルメンテーションがあるため、これらを削除できます。

• 関連するクエリを作成します。

  FROM Metric select * where metricName like 'aws.rds.cpu%' facet metricName limit max since 1 day ago

  コピー

• 削除したいプロセス サンプルが見つかったことを確認してください。

• NerdGraph APIを使用して、以下の文を実行し、動作することを確認する。

  mutation {
    nrqlDropRulesCreate(
      accountId: YOUR_ACCOUNT_ID
      rules: [
        {
          action: DROP_DATA
          nrql: "FROM Metric select * where metricName like 'aws.rds.cpu%' facet metricName limit max since 1 day ago"
          description: "Drops rds cpu related metrics"
        }
      ]
    ) {
      successes {
        id
      }
      failures {
        submitted {
          nrql
        }
        error {
          reason
          description
        }
      }
    }
  }

  コピー

ドロップ ルールに関する重要な点の 1 つは、特定の属性を削除しながら残りのデータの整合性を維持するルールを設定できることです。これを使用して、NRDB からプライベート データを削除したり、スタック トレースや大きすぎるログ レコード内の JSON の大きなチャンクなどの大きすぎる属性を削除したりできます。

これらのドロップルールを設定するには、 actionフィールドを{ DROP_DATA }ではなくDROP_ATTRIBUTESに変更します。

mutation {
  nrqlDropRulesCreate(
    accountId: YOUR_ACCOUNT_ID
    rules: [
      {
        action: DROP_ATTRIBUTES
        nrql: "SELECT stack_trace, json_data FROM Log where appName='myApp'"
        description: "Drops large fields from logs for myApp"
      }
    ]
  ) {
    successes {
      id
    }
    failures {
      submitted {
        nrql
      }
      error {
        reason
        description
      }
    }
  }
}

この例では、特定のトレース ID の相対分布を利用して、ランダム サンプリングを近似できます。rlike 演算子を使用すると、スパンの trace.id 属性の先頭の値を確認できます。次の例では、スパンの約 25% が削除される可能性があります。

SELECT * FROM Span WHERE trace.id rlike r'.*[0-3]' and appName = 'myApp'

便利な表現は次のとおりです。

• r'.*0' 約6.25％

• r'.*[0-1]' 約12.5％

• r'.*[0-2]' 約18.75％

• r'.*[0-3]' 約25.0％

  数字が足りなくなったら、次のような文字を使用できます。

• r'.*[a0-9]' 約68.75%

• r'.*[a-b0-9]' 約75.0%

  完全なミューテーションの例を次に示します。

  mutation {
    nrqlDropRulesCreate(
      accountId: YOUR_ACCOUNT_ID
      rules: [
        {
          action: DROP_DATA
          nrql: "SELECT * FROM Span WHERE trace.id rlike r'.*[0-3]' and appName = 'myApp'"
          description: "Drops approximately 25% of spans for myApp"
        }
      ]
    ) {
      successes {
        id
      }
      failures {
        submitted {
          nrql
        }
        error {
          reason
          description
        }
      }
    }
  }

  コピー

  ヒント

  trace.idは 16 進数であるため、 trace.idのすべての文字は0123456789abcdefの値になります。RLIKEパターンに追加した各文字は、最後の文字が均等に分散されていると仮定すると、span イベント内の行の追加の 1/16 と一致します。16 進数で使用されない F を超える文字を追加した場合、追加された数字は一致率に影響しません。

前述の例は、NRDB の他のイベントまたはメトリクスに対してこれらの手法を使用するために知っておく必要があるすべてを示しています。覚えておいてください: クエリできる場合は削除できます。ドロップ ルールのクエリを構築する正確な方法について質問がある場合は、お問い合わせください。