データの取り込みを管理する1 つの方法は、 Pipeline Control cloudルールを使用することです。 Pipeline cloudルールを作成するには、 New Relicの使用量ベースの価格設定を使用する必要があります。

作成できるルールには 2 つのカテゴリがあります。

• データ削除ルール

  • 次の形式の NRQL を使用して、データ タイプ全体またはデータのサブセット(オプションのフィルターを使用)をドロップします。

    DELETE FROM DATA_TYPE_1, DATA_TYPE_2 (WHERE OPTIONAL_FILTER)

    コピー

• 属性ルールの削除

  • 次の形式の NRQL を使用して、データ型から属性を削除します(オプションのフィルターを使用) 。

    DELETE dropAttr1, dropAttr2 FROM DATA_TYPE (WHERE OPTIONAL_FILTER)

    コピー
  • このタイプのルールでは、 SELECT句に生の属性名の空でないリストを渡す必要があります。

課金対象としてカウントされるデータと課金対象としてカウントされないデータの詳細については、 「データ取り込み」を参照してください。

クラウドルールのデータ範囲

cloudルールを使用して、次のデータ タイプを対象にします。

• APMで報告されたイベント

• ブラウザで報告されるイベント

• モバイルで報告されたイベント

• シンセティック・レポート・イベント

• カスタムイベント（ APMエージェントAPI や Event API で生成されるようなもの）。

• ログデータ（UIを使ってデータをドロップすることも可能です )

• * トレーススパンの分散

  デフォルトのインフラストラクチャ監視イベント と インフラストラクチャ統合 イベント。いくつかの注意事項:

  • このデータを削除すると、生データは削除されますが、集約されたSystemSample 、 ProcessSample 、 NetworkSample 、およびStorageSampleイベントは引き続き利用できます (詳細については、 「データ保持期間」を参照してください)。 このデータは引き続き利用可能ですが、取り込みにはカウントされず、課金対象にはなりません。
  • 生のインフラストラクチャ データはアラートに使用されるため、そのデータをドロップした場合、そのデータについてアラートを発行することはできません。集計されたデータは引き続き利用できるため、59 分を超える時間範囲のデータがグラフに表示される場合があります。

• 次元メトリックス。 注意点:

  • イベント-to-メトリクス サービスによって生成されたメトリクスの場合: クラウド ルールは機能しませんが、イベント-to-メトリクス ルールを無効にするか再構成することで、これらのメトリクスを停止したり、プロパティを削除したりできます。
  • メトリック タイムスライス データはcloudルールでは削除できません。 APMメトリックタイムスライスデータの詳細については、このドキュメントを参照してください。

NRQL制限

• NRQL クエリの長さの制限は4096文字です。長さを超えると、 INVALID_NRQL_TOO_LONGエラーが発生します。分割できない長いクエリに基づいてデータを削除する必要がある場合は、 New Relic サポートにお問い合わせください。
• JOIN サブクエリはサポートされていません。
• 特定の属性を持つデータを選択するには、 WHERE句を指定できます。
• LIMIT 、 TIMESERIES 、 COMPARE WITH 、 FACETなどの機能やその他の句は使用できません。
• SINCE UNTILはサポートされていません。時間固有のルールがある場合（たとえば、将来のある時点まですべてをドロップするなど）、 WHERE timestamp < (epoch milliseconds in the future)を使用します。
• SINCEを使用して履歴データを削除することはできません。クラウド ルールは、ルールの作成後に報告されたデータにのみ適用されます。すでに報告されているデータを削除する必要がある場合は、 「既存のデータの削除」を参照するか、 New Relic サポートにお問い合わせください。

監査ルールの履歴

誰がcloudルールを作成および削除したかを確認するには、 アカウント監査ログを作成します。 リスト エンドポイントには、ルールを作成したユーザーのユーザー ID も含まれます。

データを落とす際の注意点

クラウド ルールは各データ ポイントに個別に適用されます。たとえば、次の 3 つのデータ ドロップ ルールを見てみましょう。

1. DELETE FROM MyEvent WHERE myAttr not in ('staging')
2. DELETE FROM MyEvent WHERE myAttr not in ('production')
3. DELETE FROM MyEvent WHERE myAttr in ('development')

これらの 3 つのルールは各データ ポイントに個別に適用されます。要約すると、任意の値を持つmyAttrを含むすべてのMyEventイベントが削除されます。

• myAttr: 'staging' -> ルール2に一致
• myAttr: 'production' -> ルール 1 に一致
• myAttr: 'development' -> ルール1、2、3に一致
• myAttr: 'uuid-random-string' -> ルール1と2に一致

New Relic は、この機能によってデータ漏洩に関する懸念が完全に解決されることを保証することはできません。New Relic開発したルールの有効性をレビューしたり監視したりしません。 常にクエリをテストおよび再テストし、ドロップ ルールの作成後に意図したとおりに動作することを確認してください。

センシティブなデータに関するルールを作成すると、どのような種類のデータを保持しているのか、データやシステムの形式（例えば、電子メールアドレスや特定のクレジットカード番号を参照することなど）などの情報が漏れてしまいます。作成したルールは、そのルールに含まれるすべての情報を含めて、関連するロールベースのアクセス制御権限を持つすべてのユーザーが表示および編集できます。

ドロップされるのは新規データのみです。既存のデータ の編集や削除はできません 。

cloudルールの管理

ルールを作成および編集するには、 Pipeline Control UIまたはNerdGraph API エクスプローラー( one.newrelic.com > Apps > NerdGraph API explorer )を使用できます。

ユースケースの例

mutation {
  entityManagementCreatePipelineCloudRule(
    pipelineCloudRuleEntity: {
      description: "Event1 and Event2 are unimportant, see ticket DM-1234"
      name: "Drop all data for Event1 and Event2"
      nrql: "DELETE FROM Event1, Event2"
      scope: { id: "your_nr_account_id", type: ACCOUNT }
    }
  ) {
    entity {
      id
      name
      nrql
    }
  }
}

mutation {
  entityManagementCreatePipelineCloudRule(
    pipelineCloudRuleEntity: {
      description: "Drops all data for MyCustomEvent that comes from the LoadGeneratingApp in the dev environment, because there is too much and we don’t look at it"
      name: "Drop MyCustomEvent from LoadGeneratingApp in dev"
      nrql: "DELETE FROM MyCustomEvent WHERE appName='LoadGeneratingApp' AND environment='development'"
      scope: { id: "your_nr_account_id", type: ACCOUNT }
    }
  ) {
    entity {
      id
      name
      nrql
    }
  }
}

mutation {
  entityManagementCreatePipelineCloudRule(
    pipelineCloudRuleEntity: {
      description: "Removes the user name and email fields from MyCustomEvent"
      name: "Drop username and email from MyCustomEvent"
      nrql: "DELETE userName, userEmail FROM MyCustomEvent"
      scope: { id: "your_nr_account_id", type: ACCOUNT }
    }
  ) {
    entity {
      id
      name
      nrql
    }
  }
}

ルールが機能することを確認する

cloudルールを作成したら、期待どおりに動作しているかどうかを確認することをお勧めします。 登録が成功するとすぐにルールが有効になるはずなので、登録したクエリのTIMESERIESバージョンを実行して、データが削除されるかどうかを確認してください。

注: 時系列データは、イベント時間 (処理時間ではない) を x 軸としてレンダリングされます。New Relic は最大 24 時間先のタイムスタンプを持つデータを受け入れるため、ルールが作成される前に New Relic に送信されたが、イベント タイムスタンプがルール作成後のデータが表示される場合があります。

DELETE FROM MyEvent WHERE foo = bar

SELECT count(*) FROM MyEvent WHERE foo = bar TIMESERIES

DELETE dropAttr1, dropAttr2 FROM MyEvent WHERE foo = bar

SELECT count(dropAttr1), count(dropAttr2) FROM MyEvent WHERE foo = bar TIMESERIES

NerdGraphの例

cloudルールを作成する

ドロップデータ:

mutation {
  entityManagementCreatePipelineCloudRule(
    pipelineCloudRuleEntity: {
      description: "Since we only care about MyEvent in staging and production, let's drop all MyEvent data in the test environment"
      name: "Drop MyEvent in test environment"
      nrql: "DELETE FROM MyEvent where environment = 'test'"
      scope: { id: "your_nr_account_id", type: ACCOUNT }
    }
  ) {
    entity {
      id
      name
      nrql
    }
  }
}

ドロップ属性:

mutation {
  entityManagementCreatePipelineCloudRule(
    pipelineCloudRuleEntity: {
      description: "We don't care about jvmId and targetAttr in the test environment, let's drop those attributes"
      name: "Drop jvmId and targetAttr from MyEvent in test environment"
      nrql: "DELETE jvmId, targetAttr FROM MyEvent where environment = 'test'"
      scope: { id: "your_nr_account_id", type: ACCOUNT }
    }
  ) {
    entity {
      id
      name
      nrql
    }
  }
}

cloudルールを削除する

mutation {
  entityManagementDelete(
    id: "MTAyNTY1MHxOR0VQfFBJUEVMSU5FX0NMT1VEX1JVTEV8MDE5NWI0NDYtNjk5My03NGE5LWEyYjktMzBjMzQ1ODM0NTUz"
  ) {
    id
  }
}

cloudルールを表示

単一のcloudルールを取得します。

{
  actor {
    entityManagement {
      entity(
        id: "MTAyNTY1MHxOR0VQfFBJUEVMSU5FX0NMT1VEX1JVTEV8MDE5NWI0M2UtYmFhNy03NDk3LWI0N2ItNjUyMmEzZDFmZTFi"
      ) {
        id
        ... on EntityManagementPipelineCloudRuleEntity {
          id
          name
          description
          nrql
          metadata {
            createdBy {
              id
            }
            createdAt
          }
        }
      }
    }
  }
}

すべてのcloudルールを一覧表示します。

{
  actor {
    entityManagement {
      entitySearch(query: "type = 'PIPELINE_CLOUD_RULE'") {
        entities {
          id
          type
          ... on EntityManagementPipelineCloudRuleEntity {
            id
            name
            nrql
          }
          metadata {
            createdBy {
              id
            }
          }
        }
      }
    }
  }
}

ドロップできないイベントと属性

cloudルールを使用して次のイベントとプロパティを削除することはできません:

ディメンション・メトリック・ロールアップでの属性の削除

Dimensional metrics メトリクスをロールアップに集約して長期保存し、長期的なクエリを最適化する方法として メトリクスのカーディナリティ制限 がこのデータに適用されます。

この機能を利用して、長期間の保存や問い合わせには必要ないが、リアルタイムの問い合わせのために維持しておきたい属性を決めることができます。

たとえば、属性としてcontainerIdを追加すると、ライブトラブルシューティングや最近の分析に役立ちますが、より大きな傾向を長期間にわたってクエリする場合は必要ない場合があります。 containerIdのようなユニークなものがどれほどユニークであるかにより、それはあなたをメトリックカーディナリティの限界に向かって素早く駆り立てることができ、ヒットするとそのUTC日の残りのロールアップの合成を停止します。

また、この機能により、カーディナリティの高い の属性を生データに残し、ロールアップから削除することができ、カーディナリティの限界に近づくスピードをよりコントロールすることができます。

使用方法

Drop attributes from dimensional metrics rollups (オプションのフィルター付き)これは次の形式の NRQL を使用します:

DELETE dropAttr1, dropAttr2 FROM MetricAggregate (WHERE OPTIONAL_FILTER)

NerdGraphのリクエスト例をご紹介します。

mutation {
  entityManagementCreatePipelineCloudRule(
    pipelineCloudRuleEntity: {
      description: "We don't care about targetAttr in the test environment in dimensional metric rolloups, let's drop those attributes"
      name: "Drop targetAttr from Metric aggregate rollups in test environment"
      nrql: "DELETE targetAttr FROM MetricAggregate where environment = 'test'"
      scope: { id: "your_nr_account_id", type: ACCOUNT }
    }
  ) {
    entity {
      id
      name
      nrql
    }
  }
}

動作していることを確認するには、ルールが選択され、集計データが生成されるまで 3 ～ 5 分待ちます。次に、上記のNRQL例がパイプライン制御cloudルールであると仮定して、次のクエリを実行します。

SELECT count(targetAttr) FROM Metric WHERE metricName = 'some.metric' TIMESERIES SINCE 2 hours ago
SELECT count(targetAttr) FROM MetricRaw WHERE metricName = 'some.metric' TIMESERIES SINCE 2 hours ago

最初の書き込みはメトリクス ロールアップを取得します。新しいドロップ ルールに従ってcontainerIdドロップされているため、0 にドロップされるはずです。 2 番目の書き込みは、 MetricRawイベント タイプを使用してメトリクスの生データを取得します。生データは新しいドロップ ルールの影響を受けないため、引き続き安定して保持されます。 これがカーディナリティに与える影響を確認する方法の詳細については、 「高いカーディナリティ メトリクスを理解して書く」を参照してください。

制限

プロパティのドロップ ルールに適用されるすべての制限は、ディメンション メトリクス ロールアップ ルールからのプロパティのドロップに適用されますが、 MetricAggregateデータ タイプのみを対象にすることができるという追加の制限があります。 また、 メトリクスルールへのイベントによって作成されたMetric書き込みターゲティング データや、 Metric書き込みターゲティング時間区切りデータにも機能しません。

もっと詳しく知る

もっと知りたい方へのおすすめ情報

• NerdGraphの基礎知識と用語集
• NRQLの基礎知識
• ルールに関するコミュニティのディスカッションについては、 サポート フォーラム を参照してください。cloud
• 複雑な組織のデータ取り込みの管理の詳細については、 データ取り込みガバナンスを参照してください。