NerdGraphでデータを落とす

データインジェストを管理する一つの方法は、データドロップのルールを設定することです。データドロップをサポートしているデータに対して、以下のことができます。

重要ではない価値の低いデータを除外する
機密性の高いデータを除外

概要

データドロップのルールを設定すると、その時点以降のデータのみが影響を受けます。すでに取り込まれている既存のデータは、編集や削除ができません。詳しくは、NerdBytesのビデオ（7分9秒）をご覧ください。

NerdGraphを使用する以外にも、データをドロップする方法は以下の通りです。

Prometheus remote write を使用している場合は、 Drop Prometheus remote write data を参照してください。
ログを報告している場合は、UI ログデータをドロップすることができます。
APM メトリックのタイムスライスデータを削除したい場合は、メトリックの正規化ルールを使用することができます。

要件

ドロップフィルターのルールを作成・編集できるかどうかは、どのユーザーモデルを使っているかによって異なります。

New Relic One のユーザーモデル："NRQL ドロップルール" ケイパビリティを持つロールを割り当てる必要があります。
オリジナルのユーザーモデル： Adminロールを持っている必要があります。

現在、データドロップの対象となるデータタイプは以下の通りです。

APMで報告されたイベント
ブラウザで報告されるイベント
モバイルで報告されたイベント
シンセティック・レポート・イベント
カスタムイベント（ APMエージェントAPI や Event API で生成されるようなもの）。
ログデータ（UIを使ってデータをドロップすることも可能です )
* トレーススパンの分散
デフォルトのインフラ監視イベントおよびインフラ統合イベント、ただしこの例外を除く。
- ダウンサンプルされた SystemSample, ProcessSample, NetworkSample および StorageSample の時間窓が 59 分より長いものはドロップできません。このデータは、データインジェストにはカウントされません。
Dimensional metrics 、以下のような注意点があります。
- 請求への影響： New Relic One の価格では、ドロップデータは請求対象外です。オリジナル価格の場合、ドロップしたデータは請求対象となります。
- events-to-metricsサービスによって生成されたメトリクスについて: ドロップルールは機能しませんが、events-to-metricルールを無効にするか再設定することで、これらのメトリクスを停止したり、属性を刈り込んだりすることができます。

将来的にはさらに多くのタイプに対応する予定です。

ドロップデータルールの作成

注意

データをドロップするかどうかは慎重に判断してください。ドロップしたデータは復元できません。この機能を使用する前に、以下の注意情報を確認してください。

データをドロップするには、 NerdGraph-format drop rule を作成します。

NRQL ドロップするデータタイプを指定する文字列
NRQL 文字列の適用方法を指定する アクション タイプ

NerdGraph explorer で形成し、呼び出しを行うことができます。

データを落とすには2つの方法があります。

データタイプ全体またはデータサブセット をドロップします (オプションのフィルタ付き)。これは、 DROP_DATA action タイプを使用し、フォームのNRQLを使用します。
```
SELECT * FROM DATA_TYPE_1, DATA_TYPE_2 (WHERE OPTIONAL_FILTER)
```
このタイプのドロップルールでは、 SELECT 句に * 以外のものを使用することはできません。
データ型から属性をドロップ （オプションのフィルタ付き）。これは、 DROP_ATTRIBUTES action タイプを使用し、フォームのNRQLを使用します。
```
SELECT dropAttr1, dropAttr2 FROM DATA_TYPE (WHERE OPTIONAL_FILTER)
```
このタイプのドロップルールでは、生の属性名の空でないリストを渡す必要があります。

NRQL制限

すべてのNRQL句がドロップルールの生成に意味を持つわけではありません。 WHERE 句を用意することで、特定の属性を持つデータを選択することができます。 LIMIT, TIMESERIES, COMPARE WITH, FACET などの他の節の機能は使用できません。

SINCE と UNTIL は、ドロップルールではサポートされていません。時間を指定したルールがある場合（たとえば、将来のある時点まですべてをドロップする）、 WHERE timestamp< (epoch milliseconds in the future) を使用してください。また、 SINCE を使って過去のデータをドロップすることはできません。NRQL のドロップルールは、ドロップルールが作成された後に報告されたデータにのみ適用されます。すでに報告されているデータを削除する必要がある場合は、New Relic の担当者にお問い合わせください。

2つのアクションタイプにはこれらの制限があります。

DROP_DATA のみ使用可能 SELECT *.
DROP_ATTRIBUTES では、 SELECT を"raw" 属性（ aggregator function が適用されていない属性）で使用する必要があります。これは、 SELECT * を使用できないことも意味します。さらに、データタイプに不可欠な属性もあり、 を削除することはできません。 （イベントデータの タイムスタンプ など）。これらの属性を含めると、登録に失敗します。

ドロップルールの例

以下にドロップルールの例を示します。

例えば、自分にとって重要でないイベントタイプがNew Relicに送信されていることに気づいたとします。また、それらのイベントタイプの送信元をすぐに止めることは現実的ではなく、エージェントやAPIインスツルメンテーションの変更が必要になります。ドロップルールを使用すれば、同じ目的を達成するためのより簡単な方法です。

以下は、 Event1 と Event2 という2つのイベントタイプをドロップする NerdGraph 呼び出しの例です。

mutation {
    nrqlDropRulesCreate(accountId: YOUR_ACCOUNT_ID, rules: [
        {
            action: DROP_DATA
            nrql: "SELECT * FROM Event1, Event2"
            description: "Drops all data for Event1 and Event2."
        }
    ])
    {
        successes { id }
        failures {
            submitted { nrql }
            error { reason description }
        }
    }
}

例えば、複数のソースから届く大量のカスタムイベントタイプがあるとします。そのデータのすべてが重要でないと判断した場合、ドロップルールを使用することができます。以下は、特定の条件に基づいてイベントをフィルタリングするドロップルールの例です。

mutation {
    nrqlDropRulesCreate(accountId: YOUR_ACCOUNT_ID, rules: [
        {
            action: DROP_DATA
            nrql: "SELECT * FROM MyCustomEvent WHERE appName='LoadGeneratingApp' AND environment='development'"
            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."
        }
    ])
    {
        successes { id }
        failures {
            submitted { nrql }
            error { reason description }
        }
    }
}

あるイベントの属性に個人識別情報(PII)が含まれていることに気づいたとします。サービスをアップデートしてデータの送信を停止する作業を行っていますが、それまでの間、New RelicへのさらなるPIIの保存を停止する必要があります。 DROP_DATA ルールを使って、ドアから入ってきたデータをすべてドロップすることはできますが、残りのデータはまだ価値があります。そのため、ドロップルールを登録して、問題のあるPIIだけをデータから削除することができます。

mutation {
    nrqlDropRulesCreate(accountId: YOUR_ACCOUNT_ID, rules: [
        {
            action: DROP_ATTRIBUTES
            nrql: "SELECT userEmail, userName FROM MyCustomEvent"
            description: "Removes the user name and email fields from MyCustomEvent"
        }
    ])
    {
        successes { id }
        failures {
            submitted { nrql }
            error { reason description }
        }
    }
}

ドロップルールの動作確認

ドロップルールを作成したら、期待通りに動作しているかどうかを確認します。ルールは、登録が成功した後、すぐに有効になるはずなので、登録したクエリの TIMESERIES バージョンを実行して、データがドロップすることを確認してみてください。

ドロップルールタイプ	NRQL
`DROP_DATA`	ドロップルールNRQL。 `SELECT * FROM MyEvent WHERE foo = bar` バリデーションNRQL。 `SELECT count(*) FROM MyEvent WHERE foo = bar TIMESERIES` これで0に下がるはずです。他に影響がないことを確認するために、 `WHERE` 句を反転させます。
`drop_attributes`	ドロップルールNRQL。 `SELECT dropAttr1, dropAttr2 FROM MyEvent WHERE foo = bar` バリデーションNRQL。 `SELECT count(dropAttr1), count(dropAttr2) FROM MyEvent WHERE foo = bar TIMESERIES` 両方の行が0になるはずです。これらの属性を含むイベントに影響を与えていないことを確認するために、 `WHERE` 句を反転させます。

ドロップルールタイプ

NRQL

DROP_DATA

ドロップルールNRQL。

SELECT * FROM MyEvent WHERE foo = bar

バリデーションNRQL。

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

これで0に下がるはずです。他に影響がないことを確認するために、 WHERE 句を反転させます。

drop_attributes

ドロップルールNRQL。

SELECT dropAttr1, dropAttr2 FROM MyEvent WHERE foo = bar

バリデーションNRQL。

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

両方の行が0になるはずです。これらの属性を含むイベントに影響を与えていないことを確認するために、 WHERE 句を反転させます。

ルールを見る

以下は、アカウントに設定されているドロップルールを返すNerdGraphコールの例です。

{
    actor {
        account(id: YOUR_ACCOUNT_ID) {
            nrqlDropRules {
                list {
                    rules {
                        id
                        nrql
                        accountId
                        action
                        createdBy
                        createdAt
                        description
                    }
                    error { reason description } 
                }
            }
        }
    }
}

ドロップルールの削除

以下は、特定の2つのドロップルールを削除するNerdGraphコールの例です。

mutation {
    nrqlDropRulesDelete(accountId: YOUR_ACCOUNT_ID, ruleIds: ["48", "98"]) {
    successes {
        id
        nrql
        accountId
        action
        description
    }
    failures {
        error { reason description }
        submitted { ruleId accountId }
        }
    }
}

ドロップルール履歴の監査

ドロップルールの作成者と削除者を確認するには、アカウントの監査ログを照会してください。リストエンドポイントには、ルールを作成した人のユーザーIDも含まれています。

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

ドロップルールを作成する際には、ルールが設定した条件を満たすデータを正確に識別し、廃棄することに責任を負います。また、ルールの監視だけでなく、New Relic に開示したデータの監視にも責任があります。

New Relic は、この機能によってお客様が抱えるデータ開示の懸念を完全に解決できることを保証するものではありません。New Relic は、お客様が作成したルールがどれだけ効果的であるかをレビューまたは監視しません。

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

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

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

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

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

例えば、 containerId を属性として追加することは、ライブのトラブルシューティングや最近の分析には役立ちますが、より大きなトレンドを求めて長期間にわたってクエリを行う場合には必要ないかもしれません。 containerId のようなものは非常にユニークであるため、メトリックのカーディナリティ制限に到達すると、その UTC 日の残りのロールアップの合成が停止してしまう可能性があります。

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

使用方法

ディメンション・メトリクス・ロールアップから属性をドロップ （オプションのフィルタ付き）。これは、 DROP_ATTRIBUTES_FROM_METRIC_AGGREGATES アクション タイプを使用し、フォームのNRQLを使用します。

SELECT dropAttr1, dropAttr2 FROM Metric (WHERE OPTIONAL_FILTER)

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

mutation {
    nrqlDropRulesCreate(accountId: YOUR_ACCOUNT_ID, rules: [
        {
            action: DROP_ATTRIBUTES_FROM_METRIC_AGGREGATES
            nrql: "SELECT containerId FROM Metric WHERE metricName = 'some.metric'"
            description: "Removes the containerId from long term querys."
        }
    ])
    {
        successes { id }
        failures {
            submitted { nrql }
            error { reason description }
        }
    }
}

動作を確認するには、ルールがピックアップされ、集計データが生成されるまで3～5分待ちます。次に、上記のNRQLの例があなたのドロップルールであると仮定して、以下のクエリを実行します。

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

最初のクエリはメトリック・ロールアップを検索し、 containerId が新しいドロップ・ルールに従ってドロップされたため、0 に落ちるはずです。2つ目のクエリは、 RAW キーワードを使用してメトリックローを取得しますが、生データは新しいドロップルールの影響を受けないため、引き続き安定しているはずです。カーディナリティへの影響を確認する方法の詳細については、 Understand and query high cardinality metrics を参照してください。

制約事項

DROP_ATTRIBUTES に適用されるすべての制限は、 DROP_ATTRIBUTES_FROM_METRIC_AGGREGATES にも適用されますが、 Metric データタイプのみを対象とすることができるという追加の制限があります。また、 Metric のクエリでは、 events to metrics のルールによって作成されたデータを対象としており、 Metric のクエリでは、 timeslice data を対象としており、これらは機能しません。

詳細情報

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

NerdGraphの基礎知識と用語集
NRQLの基礎知識
Explorers Hub NRQLドロップルールに関するコミュニティの議論を参照してください。

本書は、お客様のご参考のために原文の英語版を機械翻訳したものです。

概要

要件