データの取り込みを管理する1 つの方法は、 Pipeline Control cloudルールを使用することです。 Pipeline cloudルールを作成するには、 New Relicの使用量ベースの価格設定を使用する必要があります。
作成できるルールには 2 つのカテゴリがあります。
データ削除ルール
- 次の形式の NRQL を使用して、データ タイプ全体またはデータのサブセット(オプションのフィルターを使用)をドロップします。DELETE FROM DATA_TYPE_1, DATA_TYPE_2 (WHERE OPTIONAL_FILTER)
- 次の形式の NRQL を使用して、データ タイプ全体またはデータのサブセット(オプションのフィルターを使用)をドロップします。
属性ルールの削除
- 次の形式の NRQL を使用して、データ型から属性を削除します(オプションのフィルターを使用) 。DELETE dropAttr1, dropAttr2 FROM DATA_TYPE (WHERE OPTIONAL_FILTER)
- このタイプのルールでは、
DELETE
句に生の属性名の空でないリストを渡す必要があります。
- 次の形式の NRQL を使用して、データ型から属性を削除します(オプションのフィルターを使用) 。
ヒント
Pipeline Control cloudルールは、ルールを作成した瞬間から到着するデータにのみ適用され、 すでに取り込まれたデータは削除されません。
課金対象としてカウントされるデータと課金対象としてカウントされないデータの詳細については、 「データ取り込み」を参照してください。
クラウドルールのデータ範囲
cloudルールを使用して、次のデータ タイプを対象にします。
APMで報告されたイベント
ブラウザで報告されるイベント
モバイルで報告されたイベント
シンセティック・レポート・イベント
カスタムイベント( APMエージェントAPI や Event API で生成されるようなもの)。
ログデータ(UIを使ってデータをドロップすることも可能です )
デフォルトのインフラストラクチャ監視イベント と インフラストラクチャ統合 イベント。いくつかの注意事項:
- このデータを削除すると、生データは削除されますが、集約された
SystemSample
、ProcessSample
、NetworkSample
、およびStorageSample
イベントは引き続き利用できます (詳細については、 「データ保持期間」を参照してください)。 このデータは引き続き利用可能ですが、取り込みにはカウントされず、課金対象にはなりません。 - 生のインフラストラクチャ データはアラートに使用されるため、そのデータをドロップした場合、そのデータについてアラートを発行することはできません。集計されたデータは引き続き利用できるため、59 分を超える時間範囲のデータがグラフに表示される場合があります。
- このデータを削除すると、生データは削除されますが、集約された
重要
2026 年 1 月 7 日に、 SystemSample
、 ProcessSample
、 NetworkSample
、 StorageSample
のインフラストラクチャ イベントを対象とするドロップ ルールによって集計データがドロップされます。
次元メトリックス。 注意点:
- イベント-to-メトリクス サービスによって生成されたメトリクスの場合: クラウド ルールは機能しませんが、イベント-to-メトリクス ルールを無効にするか再構成することで、これらのメトリクスを停止したり、プロパティを削除したりできます。
- メトリック タイムスライス データはcloudルールでは削除できません。 APMメトリックタイムスライスデータの詳細については、このドキュメントを参照してください。
NRQL制限
- NRQL クエリの長さの制限は4096文字です。長さを超えると、
INVALID_NRQL_TOO_LONG
エラーが発生します。分割できない長いクエリに基づいてデータを削除する必要がある場合は、 New Relic サポートにお問い合わせください。 JOIN
サブクエリはサポートされていません。- 特定の属性を持つデータを選択するには、
WHERE
句を指定できます。 - エンティティ タグは別のプロセスでフェッチされ、パイプラインcloudルールによって評価される MELT データの属性ではないため、データを削除するために
WHERE
句でエンティティ タグを使用しないでください。 LIMIT
、TIMESERIES
、COMPARE WITH
、FACET
などの機能やその他の句は使用できません。SINCE
UNTIL
はサポートされていません。時間固有のルールがある場合(たとえば、将来のある時点まですべてをドロップするなど)、WHERE timestamp < (epoch milliseconds in the future)
を使用します。SINCE
を使用して履歴データを削除することはできません。クラウド ルールは、ルールの作成後に報告されたデータにのみ適用されます。すでに報告されているデータを削除する必要がある場合は、 「既存のデータの削除」を参照するか、 New Relic サポートにお問い合わせください。
監査ルールの履歴
誰がcloudルールを作成および削除したかを確認するには、 アカウント監査ログを作成します。 リスト エンドポイントには、ルールを作成したユーザーのユーザー ID も含まれます。
データを落とす際の注意点
クラウド ルールは各データ ポイントに個別に適用されます。たとえば、次の 3 つのデータ ドロップ ルールを見てみましょう。
重要
ルールを作成するときは、設定した条件を満たすデータをルールが正確に識別して破棄するようにする責任があります。また、ルールと New Relic に開示するデータを監視する責任も負います。
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 )を使用できます。
注意
データを削除する場合は注意が必要です。落としたデータは復元できません。潜在的な問題の詳細については、 「 注意事項 」を参照してください。
Use case examples
ルールが機能することを確認する
cloudルールを作成したら、期待どおりに動作しているかどうかを確認することをお勧めします。 登録が成功するとすぐにルールが有効になるはずなので、登録したクエリのTIMESERIES
バージョンを実行して、データが削除されるかどうかを確認してください。
注: 時系列データは、イベント時間 (処理時間ではない) を x 軸としてレンダリングされます。New Relic は最大 24 時間先のタイムスタンプを持つデータを受け入れるため、ルールが作成される前に New Relic に送信されたが、イベント タイムスタンプがルール作成後のデータが表示される場合があります。
クラウドルールタイプ | NRQL |
---|---|
| Cloud rule NRQL:
Validation NRQL:
これは0に低下するはずです。他に影響がないことを確認するには、 |
| Cloud rule NRQL:
Validation NRQL:
両方の行が0にドロップする必要があります。これらの属性を含むイベントに影響がなく、それでも影響がないことを確認するには、 |
NerdGraph examples
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 } }}
Update a cloud rule
You can modify existing cloud rules to adjust their filtering criteria, data types, or deployment scope.
重要
Cloud rules only apply to data that arrives from the moment you create or update the rule. They do not affect data that has already been ingested. Always test and monitor your updated rules to ensure they're working as intended.
To update an existing Cloud rule, you'll use the updatePipelineCloudRule
mutation. This allows you to change the rule's name, description, and, crucially, its NRQL.
Identify the rule
You'll need the unique entity ID of the cloud rule you wish to update. You can find this ID by querying your rules using NerdGraph. For example:
actor { entitySearch( query: "type = 'PIPELINE_CLOUD_RULE'" ) { results { entities { id name } } } }
Construct your mutation:
Use the updatePipelineCloudRule
mutation, providing the rule's id
and a pipelineCloudRuleEntity
object containing the fields you want to change.
id
: The entity ID of the cloud rule you identified in step 1.pipelineCloudRuleEntity
: An object containing the updated details. You can provide any or all of the below fields:nrql
: The updated NRQL query that defines what data or attributes to drop. This should be aDELETE NRQL
query (for example,DELETE FROM MyEvent or DELETE attribute FROM MyEvent
).name
: The new name for your rule (optional).description
: The new description for your rule (optional).
Suppose you have an existing rule that drops dropAttr1
from MyEventToDrop
eventType. If you want to change it to drop dropAttr2
instead, call the following mutation:
mutation UpdatePipelineCloudRule { updatePipelineCloudRule( id: "MTAyNTY1MHxOR0VQfFBJUEVMSU5FX0NMT1VEX1JVTEV8MDE5ODgwOTUtMmZjNC03MTQ3LTkxMjQtZDk3YjhiY2Y4NGNj" # Replace with your rule's actual entity ID pipelineCloudRuleEntity: { description: "Since we do not need dropAttr2 ingested we would drop this attribute." name: "Update for Dropping dropAttr2 from MyEventToDrop" nrql: "DELETE dropAttr2 FROM MyEventToDrop" } ) { entity { id type name description nrql } }}
Verify the update
Check the API response: The entity object in the response will reflect the updated name, description, and NRQL.
Monitor your data: Send new data that would be affected by the rule and confirm that the dropping behavior has changed as expected. For example, if you changed from dropping attr1 to attr2, ensure attr1 is now ingested and attr2 is no longer appearing.
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)
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 agoSELECT count(targetAttr) FROM MetricRaw WHERE metricName = 'some.metric' TIMESERIES SINCE 2 hours ago
最初の書き込みはメトリクス ロールアップを取得します。新しいドロップ ルールに従ってcontainerId
ドロップされているため、0 にドロップされるはずです。 2 番目の書き込みは、 MetricRaw
イベント タイプを使用してメトリクスの生データを取得します。生データは新しいドロップ ルールの影響を受けないため、引き続き安定して保持されます。 これがカーディナリティに与える影響を確認する方法の詳細については、 「高いカーディナリティ メトリクスを理解して書く」を参照してください。
制限
プロパティのドロップ ルールに適用されるすべての制限は、ディメンション メトリクス ロールアップ ルールからのプロパティのドロップに適用されますが、 MetricAggregate
データ タイプのみを対象にすることができるという追加の制限があります。 また、 メトリクスルールへのイベントによって作成されたMetric
書き込みターゲティング データや、 Metric
書き込みターゲティング時間区切りデータにも機能しません。
もっと詳しく知る
もっと知りたい方へのおすすめ情報
- NerdGraphの基礎知識と用語集
- NRQLの基礎知識
- ルールに関するコミュニティのディスカッションについては、 サポート フォーラム を参照してください。cloud
- 複雑な組織のデータ取り込みの管理の詳細については、 データ取り込みガバナンスを参照してください。