データの取り込みを最適化する

アカウントは、予算よりも約20％多く取り込みます。彼らはマネージャーから消費を減らす方法を見つけるように頼まれました。それらの最も重要なバリュードライバーは、稼働時間、パフォーマンス、および信頼性です。

彼らの遺産は以下の通りです。

• APM(開発、ステージング、本番)

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

• ブラウザ

• 100台のホストのインフラストラクチャ監視

• K8sのモニタリング（dev, staging, prod）

• ログ（dev, staging, prod - debugを含む）

  最適化計画

  • デバッグログを省略する（問題がある場合はオンにできることを承知で）（5%節約できる）
  • Kubernetesクラスターエクスプローラーを表示するために必要のないいくつかのK8s状態メトリックを省略します（10％節約）
  • 新機能のA/Bテストを多く行っていた頃に収集していたカスタムブラウザのイベントを削除（10%節約可能）

  これらの変更を実行した後、チームは予算を5％下回るようになり、NPMパイロットを実行するためのスペースが解放されました。彼らのマネージャーは、大幅な稼働時間と信頼性の可観測性を失わないことに満足しています。

  最終結果

  • 当初予算より5%減
  • 稼働時間、パフォーマンス、および信頼性の目標を提供するNPMパイロット用に作成されたヘッドルーム
  • 稼働時間と信頼性の可観測性の損失を最小限に抑える

モバイルモニタリングとブラウザモニタリングに重点を置いた新しいユーザー向けプラットフォームを担当するチームは、予算を50％上回っています。摂取量を適切なサイズにする必要がありますが、カスタマーエクスペリエンスの可観測性を犠牲にしないことに固執しています。

彼らの遺産は以下の通りです。

• モバイル

• ブラウザ

• APM

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

• プロセスサンプルを含む30台のホスト上のインフラ

• バックエンドの非同期プロセスのサーバーレス監視

• そのサーバーレス機能からのログ

• 各種クラウドインテグレーション

  最適化計画

  • サーバーレスのログを省略する（基本的にLambdaとの連携で得られるものと冗長になっている）
  • そのホストのプロセスのサンプルレートを1分ごとに減少させる
  • DEV環境でのサンプルデータのドロップ処理
  • New Relic infra agentが提供する他のインフラ監視と冗長性が高いEC2統合をオフにする。

  最終結果

  • 当初予算より5％オーバー
  • ピークシーズンを乗り切るのに十分
  • 顧客体験の観測可能性を損なわない

  変更を実行した後、元の予算をわずか5％上回っていますが、ピークシーズンを乗り切るにはこれで十分であると彼らは結論付けています。

あるチームが、大規模なPythonモノリスを4つのマイクロサービスにリファクタリングしている最中です。モノリスは、顧客データベースやキャッシュレイヤーなど、多くのインフラを新しいアーキテクチャと共有しています。彼らは予算を70%超過しており、モノリスを正式に廃止するまであと2ヶ月しかない。

彼らの遺産は以下の通りです。

• K8sの監視（マイクロサービス）

• New Relic ホスト監視 (monolith)

• APM（マイクロサービス、ホスト監視）

• 分散トレース(マイクロサービス、ホスト監視)

• Postgresql（共有）

• Redis(共有)

• MSSQL (マイクロサービスアーキテクチャのための将来のDB)

• ロードバランサーのログ取得（マイクロサービス、ホスト監視）

  最適化計画

  • ロードバランサーのログを5xxレスポンスコードのみ監視するように設定する（monolith）
  • モノリスを実行しているホストのProcessSample 、 StorageSample 、およびNetworkSampleから60秒のカスタムサンプルレート
  • 現在、新しいアーキテクチャではMSSQLを使用していないため、MSSQLの監視を無効にします。
  • モノリスの分散トレースは、マイクロサービスアーキテクチャではあまり役に立たないので、無効にしてください。

  最終成果

  • 当初予算を1％下回る
  • イノベーションと成長の可観測性を失うことはありません

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

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

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

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

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

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

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

  容量の管理

  ビジネスをサポートするには、アプリケーションへのすべての呼び出しが必要であると想定できますが、アーキテクチャ全体でより節約できる可能性があります。極端な場合、クライアントによって10秒ごとに呼び出されるユーザープロファイルマイクロサービスがある場合があります。これにより、一部のユーザー情報が他のクライアントによって更新された場合の遅延を減らすことができます。ただし、私たちが持っている1つの手段は、このサービスへの呼び出しの頻度を、たとえば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インスタンスで大きく変動するのは、データベースの呼び出し回数と、どのような設定をしたかという点です。データベースクエリの監視をどの程度冗長にするかは、かなりコントロールできます。これらのクエリは、トランザクショントレースページに表示されます。

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

• 難読化されたクエリデータではなく、生のクエリデータを収集する、またはクエリの収集をオフにする

• スタックトレースの閾値の変更

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

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

  イベント制限の設定

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

  キャップされ、サンプリングの対象となるイベントは以下の通りです。

• エージェント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言語エージェントの新しいバージョンでは、ログをNewRelicに直接転送できます。場合によっては、各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
  }

  コピー

  データ量は、 InfiniteTracingを使用しているかどうかによっても異なります。

  APM エージェントの標準分散トレース (上記) はトレースの最大 10% をキャプチャしますが、すべてのデータを分析して最も関連性の高いトレースを見つけたい場合は、無限トレースを設定できます。標準の分散トレースに代わるこの方法は、すべての APM 言語エージェントで利用できます。

  月間の摂取量を少しでも増やすための主なパラメータは以下の通りです。

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

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

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

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

拒否リストの使用

リクエストは3つの方法でブロックされます。

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

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

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

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

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

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

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

1. one.newrelic.comにアクセスし、をクリックし、[ブラウザ] をクリックします。

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

3. 左のナビゲーションで、 アプリの設定 をクリックします。

4. Ajaxリクエスト拒否リストの下に、適用するフィルターを追加します。

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

分析設定は、イベントデータの収集を有効または無効にします。これらのイベントはNewRelicに報告され、クラッシュ分析ページで使用されます。

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

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

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

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

構成可能なサンプリングレート

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

| パラメーター | デフォルト | 無効 | | --------------------------- | ------- | ------- | | metrics_storage_sample_rate | 5 | -1 | | metrics_process_sample_rate | 20 | -1 | | metrics_network_sample_rate | 10 | -1 | | metrics_system_sample_rate | 5 | -1 | | metrics_nfs_sample_rate | 5 | -1 |

プロセスサンプル

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

enable_process_metrics: true

これは、 metrics_process_sample_rateを-1に設定するのと同じ効果があります。

デフォルトでは、メモリ不足のプロセスはサンプリングから除外されます。詳細については、 disable-zero-mem-process-filterを参照してください。

include_matching_metricsを設定することで、New Relicに送信されるデータの量を制御できます。これにより、メトリック属性の値に基づいてメトリックデータの送信を制限できます。

メトリックの属性のいずれかにリテラルまたは部分的な値を定義して、メトリック データを含めます。たとえば、 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"

メトリクス データを除外するために同様に機能するexclude_matching_metricsが利用可能です。

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

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

• {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デプロイメントでコードとして可観測性を使用している場合、これらは非常に簡単です。 K8の取り込みを減らすことを決定する前に、このKubernetesデータ取り込み分析ダッシュボードをインストールすることを強くお勧めします。このダッシュボードを入手するには、 インフラストラクチャ統合のクイックスタートを参照してください。

スクレイプ間隔

可観測性の目的に応じて、スクレイプ間隔の調整を検討できます。デフォルトは15秒です。現在、Kubernetesクラスターエクスプローラーは45秒ごとにのみ更新されます。 K8sデータの主な用途がKCEの視覚化をサポートすることである場合は、スクレイプ間隔を20秒に変更することを検討してください。 15秒から20秒への変更は、大きな影響を与える可能性があります。これの管理の詳細については、 Helm統合スクレイプ間隔のドキュメントを参照してください。

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

Kubernetes Integration v3以降では、ラベルを付けることで、どの名前空間をスクレイピングするかをフィルタリングできます。デフォルトでは、すべての名前空間がスクレイピングされます。

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

Kubeステートメトリクス

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

• コンテナデータ
• クラスターデータ
• ノードデータ
• ポッドデータ
• ボリュームデータ
• APIサーバーデータ¹
• コントローラマネージャデータ¹
• ETCDデータ¹
• スケジューラデータ¹

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

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

• デーモンセットデータ
• デプロイメントデータ
• エンドポイントデータ
• 名前空間データ
• ReplicaSetデータ²
• サービスデータ
• 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

当社のヘルムチャートは、詳細情報をドロップする代わりに、取り込まれるデータの量を減らすオプションの設定をサポートしています。有効にするには、 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: カスタム コレクション クエリを含む構成ファイル

  サンプル構成：

  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などのパラメーターに注意することが重要です。これは、監視の優先順位を使用して、収集されたデータを合理化できる領域です。

  METRICと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: 選択されたマスターのみでクラスタ メトリックを収集します。

  METRICSと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言語エージェントの最近のバージョンでは、ログをNewRelicに直接転送できます。場合によっては、各APMエージェントインスタンスからのログスパイクの大きさの制限を管理したい場合があります。

  環境変数を使用してサンプリングを有効にできます NEW_RELIC_APPLICATION_LOGGING_FORWARDING_MAX_SAMPLES_STORED

  これは、APMエージェントのログキューに保存されるログの最大数を提供するだけで構成されます。カスタム優先キューに基づいて動作します。すべてのログメッセージが優先されます。トランザクション内で発生するログは、トランザクションの優先順位を取得します。

  ログのキューは、優先度とログの到着時刻に基づいて並べ替えられます。優先度の高い方が優先され、必要に応じて最新のログが優先されます（キュー内の各エントリのカウントを保持します）。ログはキューに個別に追加され（トランザクション内のログも含む）、制限に達すると、キューの最後にあるログがプッシュされ、新しいログが優先されます。以下のリソースセクションには、簡単な方法でログボリュームを追跡するのに役立つクイックスタートダッシュボードがあります。ログボリュームを追跡すると、可観測性のニーズに合わせてサンプリングレートを調整または無効にすることができます。

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

  ほとんどの一般的なフォワーダーは、フィルタリングと変換を含むかなり完全なルーティング ワークフローを提供します。New Relic のインフラストラクチャ エージェントは、不要なログをフィルタリングするための非常に単純なパターンをいくつか提供します。レコードをフィルタリングするための正規表現。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構成がある場合は、それらをNewRelicロギング構成にインポートできます。これを行うには、 logging.dフォルダ内の任意の.yamlファイルでconfig_fileおよびparsersパラメータを使用します。

• config_file：既存のFluentBit構成ファイルへのパス。ソースが重複していると、NewRelicのログ管理でメッセージが重複します。

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

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

  データパイプラインのログに属性（またはタグ）を挿入する方法と変換を実行する方法を学ぶと、NewRelicドロップルールを使用してダウンストリーム機能をドロップするのに役立ちます。ソースに関するメタデータを使用してログを拡張することにより、バックエンドに何をドロップするかについて、一元化された簡単に元に戻せる決定を行うことができます。少なくとも、次の属性が何らかの形でログに存在することを確認してください。

• チーム

• 環境(dev/stage/prod)

• アプリケーション

• データセンター

• ログレベル

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

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

• Fluentbitデータパイプライン

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

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

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

• cluster_name

• pod_name

• container_name

• node_name

New Relicは、PrometheusメトリックをNewRelicに送信するための2つの主要なオプションを提供します。このドキュメントでメトリックの取り込みを管理するためのベストプラクティスは、主にオプション2（Prometheus OpenMetrics統合（POMI））に焦点を当てています。これは、このコンポーネントがNewRelicによって作成されたためです。

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

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

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

POMIは、動的に発見されたPrometheusのエンドポイントと静的なエンドポイントの両方からメトリクスをスクレイピングするスタンドアローンの統合です。POMI は、このデータを New Relic Metric API 経由で NRDB に送信します。この統合は、現在 Prometheus Server を実行していないお客様にとって理想的です。

POMI：スクレープレーベル

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

scrape_enabled_labelパラメータをカスタム（たとえばnewrelic/scrape ）に変更し、データの取り込みが最大の懸念事項である場合は、Prometheusエンドポイントに選択的にラベルを付けるか注釈を付けることをお勧めします。

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

POMI構成パラメーター：

# 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構成には、これに似たセクションが表示されます。これにより、NewRelicKubernetes統合がKubeStateMetricsからすでに収集しているメトリックのサブセットのメトリック収集が無効になります。

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

POMI構成パラメーター：

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）

CPUとメモリのリソース要求は、POMIがクラスターから十分なリソースを受け取るように、適切な値に設定する必要があります。これを極端に低い値（CPU：50mなど）に設定すると、クラスターリソースが「ノイズの多いネイバー」によって消費される可能性があります。

POMI構成パラメーター：

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 を可視化できることは、非常に重要なことです。

すでにPrometheusServerを実行している場合は、POMIまたはremote_writeを有効にする前に、そこでDPMとカーディナリティの見積もりを実行できます。

1分あたりのデータポイント（DPM）：

rate(prometheus_tsdb_head_samples_appended_total[10m]) * 60

上位20のメトリック（最高のカーディナリティ）：

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

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

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

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

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

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

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

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

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

• 新しいサービス：新しいサービスまたは構成を展開していて、より頻繁にデータを収集する場合は、ポーリングの頻度を一時的に増やすことをお勧めします。

  注意

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

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

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

  ますます多くのクラウド統合が、APIポーリングを使用する代わりに、ストリーミングサービスを介してデータをプッシュするオプションを提供しています。これにより、レイテンシーが大幅に削減されることが証明されています。一部のユーザーが観察した問題の1つは、サンプリングレートを構成できないため、ボリュームの制御が簡単ではないことです。

  データをドロップするための新しい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 によって実装されています。しかし、New Relic のログ管理は、ドロップルールを非常に簡単に作成および監視できる強力な 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などの代替構文を確認してください。これらのバリエーションは一般的です。
• [データの管理]で、[ドロップフィルター]クリックし、[デバッグログの削除]という名前のフィルターを作成して有効にします。
• ルールが機能することを確認します。

方法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 ENVや Environment

• DevなどのさまざまなDEVを確認してください Development

• 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 統合が実行されている環境と、 nri-mysqlやnri-postgresqlなどの SQL データベースを監視する New Relic オンホスト統合の 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％

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

mutation {
  nrqlDropRulesCreate(
    accountId: YOUR_ACCOUNT_ID
    rules: [
      {
        action: DROP_ATTRIBUTES
        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
      }
    }
  }
}

NRDBの他のイベントやメトリックにこれらのテクニックを使用するために必要な知識は、前述の例ですべてわかるはずです。クエリーができれば、それをドロップすることができる。ドロップルールのクエリを構成する正確な方法について質問がある場合は、New Relic に連絡してください。