利用データについてのクエリとアラート

New Relicの使用量と請求について理解できるように、請求関連の使用量を把握するための使用量UIを用意しています。また、カスタムNRQLクエリを実行して追加の詳細を取得したり、使用量が特定のレベルに達した場合のアラート通知を作成したりできます。

使用量UIを使用する際、または消費クエリを実行する際は、次の点に注意してください。

• 結果は概算であり、請求金額の計算に使用される値と正確には一致しません。
• これらのツールを使用して、使用率の高い領域を見つけて追跡します。
• クエリを使用してアラートを作成すると、上限に近づいているかどうかがわかります。

データインジェスト使用量のクエリ

使用量UIは、時間の経過に伴うデータの取り込みを表示します。UIが提供するものよりも詳細な情報が必要な場合は、さまざまなNRQLクエリを使用できます。以下の例には2つのデータ型が含まれています。

• NrConsumption：これを使用して、時間ごとの使用量の詳細を詳しく調べます。請求書の代替にはなりません。
• NrMTDConsumption: これを使用して、毎月の合計使用量の概算を確認します。

FROM NrConsumption SELECT sum(GigabytesIngested) 
WHERE productLine = 'DataPlatform' 
SINCE 3 months ago TIMESERIES 1 day

FROM NrConsumption SELECT sum(GigabytesIngested) 
WHERE productLine = 'DataPlatform' SINCE 3 months ago 
FACET usageMetric TIMESERIES 1 day

FROM Metric SELECT bytecountestimate()/10e8 AS 'GB Estimate' 
SINCE 24 hours ago
FACET metricName LIMIT 10 TIMESERIES 1 hour

FROM NrMTDConsumption SELECT latest(GigabytesIngested) 
WHERE productLine = 'DataPlatform'

データの取り込みとクエリの制限

データ取り込み制限およびクエリ制限の詳細については、New Relicのデータ制限を参照してください。

ユーザー数のクエリ

ユーザー数の表示については、使用量UIを参照してください。それ以上の詳細が必要な場合は、以下のNRQLクエリの例を使用できます。ユーザーの計算方法の詳細は、請求対象ユーザーの計算を参照してください。

ほとんどのNew Relic組織には、コアユーザーを追加する機能があります。このセクションでは、これらの組織で機能するクエリを説明します。コアユーザーのロック解除をオプトインしていない古い組織にいる場合は、コアユーザーなしの組織のクエリを参照してください。

ユーザへのクエリのルールは次のとおりです。

• NrMTDConsumptionイベントのみを使用してください。
• ユーザーのクエリに使用される属性はCoreUsersBillableとFullPlatformUsersBillableです。

以下に、ユーザー数を決定するためのNRQLクエリの例をいくつかご紹介します。

直近1か月のフルプラットフォームユーザー

このクエリでは、その月の請求対象となるフルプラットフォームユーザーの数が表示されます。つまり、今すぐ請求された場合に、その月のフルプラットフォームユーザー数に対して請求される金額が表示されます。

FROM NrMTDConsumption 
SELECT latest(FullPlatformUsersBillable) 
SINCE 3 hours ago

直近1か月のコアユーザー

このクエリでは、現在請求されているコアユーザーの数が表示されます。

FROM NrMTDConsumption 
SELECT latest(CoreUsersBillable)
SINCE 3 hours ago

推定コスト

フルプラットフォームユーザーの当月のコストを取得するためのクエリです。組織のフルプラットフォームのユーザーコストを把握する必要があります。

FROM NrMTDConsumption 
SELECT latest(FullPlatformUsersBillable) * YOUR_PER_FULL_PLATFORM_USER_COST
SINCE 3 hours ago

コアユーザーなしの組織に対するユーザークエリ

これらのクエリは、2つのユーザータイプ（ベーシックユーザーとフルプラットフォームユーザー）しか利用できない一部の古いNew Relic組織に適用されます。

Syntheticsの使用

各エディションには、一定数のSyntheticsチェックが無料で含まれています。詳細については、Syntheticsの制限を参照してください。

NrMTDConsumptionイベントは使用量UIを強化し、使用量のアラートに使用する必要があります。

NrDailyUsageイベントは、Syntheticsの使用状況をさらに詳しく分析するのに役立ちますが、結果は使用量UIとNrMTDConsumptionイベントと一致しない可能性があります。1日に1回生成されます。使用状況のタイムスタンプは、New Relicが合成チェックを受信して処理する時間に対応します。これにより、syntheticチェックが実行された時間と比較して、使用状況データにわずかな違いが生じる場合があります。

FACETをNrDailyUsageイベントと使用すると、使用量をアカウント、ロケーション、モニタータイプ、モニター名など、複数のカテゴリに分割できます。親アカウント構造がある場合は、親アカウントでクエリを実行して、その親アカウントとその子アカウントの集計された使用状況を確認してください。

成功と失敗の確認はどちらも、全体的なSynthetics使用量に寄与します。以下は、両方のイベントタイプを適切に使用して、Syntheticsの使用量を表示してファセットするためのサンプルクエリです。

SELECT latest(freeConsumption) AS 'Included checks', latest(billableConsumption) AS 'Extra checks'
FROM NrMTDConsumption
WHERE metric='SyntheticChecks'
SINCE this month

SELECT latest(freeConsumption) AS 'Included checks', latest(billableConsumption) AS 'Extra checks'
FROM NrMTDConsumption
WHERE metric='SyntheticChecks'
SINCE 6 months ago 
FACET monthOf(timestamp)

SELECT (sum(syntheticsFailedCheckCount) + sum(syntheticsSuccessCheckCount)) 
AS 'Total Checks' 
FROM NrDailyUsage 
WHERE syntheticsTypeLabel != 'Ping' 
SINCE 1 month ago 
FACET consumingAccountName

SELECT (sum(syntheticsFailedCheckCount) + sum(syntheticsSuccessCheckCount)) 
AS 'Total Checks' 
FROM NrDailyUsage 
WHERE syntheticsTypeLabel != 'Ping' 
SINCE 1 month ago 
FACET syntheticsTypeLabel

SELECT (sum(syntheticsFailedCheckCount) + sum(syntheticsSuccessCheckCount)) 
AS 'Total Checks' 
FROM NrDailyUsage 
WHERE syntheticsTypeLabel != 'Ping' 
SINCE 1 month ago 
FACET syntheticsMonitorName

SELECT (sum(syntheticsFailedCheckCount) + sum(syntheticsSuccessCheckCount)) 
AS 'Total Checks' 
FROM NrDailyUsage 
WHERE syntheticsTypeLabel != 'Ping' 
SINCE 1 month ago 
FACET syntheticsLocationLabel

コスト関連のクエリ

以下は、当月の推定コストの理解に役立つクエリの推奨事項です。

FROM NrMTDConsumption 
SELECT latest(GigabytesIngestedBillable) * YOUR_PER_GB_COST

FROM NrMTDConsumption 
SELECT latest(GigabytesIngestedBillable) * .35

利用アラートを設定

請求の管理の一助として、アラートを設定し、データの取り込みやユーザー数の想定外の利用増について通知を行えます。

使用関連のアラート条件を作成する前に、以下のヒントを参考にしてください。

• アラート設定方法の基本については、NRQLアラート条件を参照してください。
• イベントタイマー集計方式は、まれに発生するデータに対して最適に機能するため推奨されます。

NRQLアラート条件の例は次のとおりです。

FROM NrConsumption 
SELECT sum(GigabytesIngested) 
WHERE productLine = 'DataPlatform'

FROM NrConsumption 
SELECT sum(GigabytesIngested) 
WHERE productLine = 'DataPlatform' 
AND consumingAccountId = YOUR_CHILD_ACCOUNT_ID

FROM NrMTDConsumption 
SELECT latest(GigabytesIngested) 
WHERE productLine = 'DataPlatform'

FROM NrMTDConsumption 
SELECT latest(FullPlatformUsersBillable)

FROM NrMTDConsumption 
SELECT latest(GigabytesIngestedBillable) * YOUR_PER_GB_COST

データ取り込み制限およびクエリ制限に関連するアラートの設定については、データ制限に達した場合のアラートの設定を参照してください。

アカウントへの変更のクエリ

アカウントに対して行った変更（ユーザー管理に関連する変更など）を確認するには、NrAuditEventをクエリできます。

使用状況関連のイベントと属性

お客様の使用状況を理解するためにクエリを実行する、プライマリイベントは次のとおりです。

• NrConsumption は、1時間ごとに利用状況を記録しますが、これは「リアルタイム」利用と同じです。このイベントを使用して、期間中の利用トレンドを観察します。
• NrMTDConsumption NrConsumptionイベントから集計値を生成します。このイベントを使用して、毎月の請求期間の利用を把握します。これは、ユーザー数をクエリする上で最適なイベントです。

使用関連のイベントにアタッチされる最も重要な属性の一部をここに示します。

バイト数の推定

使用法について詳しく知るために使用できるツールには、関数bytecountestimate()があります（例として、関数を使用するこのクエリを参照してください）。

bytecountestimate()を使用する上で知っておくべき重要なポイント：

• 検出されたすべてのデータが返されますが、データの一部はお客様による取り込みと請求にカウントされないため、実際の使用量の推定値にすぎません。そのため、さまざまなソースから報告されたデータを調査したり、報告されたデータの上限を把握したりする場合に特に役立ちます。
• 主に24時間未満の時間範囲のクエリに使用し、必要に応じて外挿を実行することをお勧めします。この関数では大量のデータのクエリが必要になり、24時間を超える範囲のデータは検出されないためです。

使用状況の推定について詳しくは、使用状況の推定に関するブログ記事をご覧ください。

以下に、bytecountestimate()の仕組みについて技術的な詳細を示します。

• 取り込みにはカウントされませんが、bytecountestimate()関数によって返されるデータにはいくつかの種類があります。つまり、この関数では、実際の使用量よりもmoreデータが表示されることがあります。まれに使用量が少な目に表示される場合がありますが、その場合でも差異はごくわずかです。
• エンティティから報告される一部のテレメトリーデータは、共通の属性（New Relicアカウントに関する属性など）を共有します。取り込みの際に重複した属性はカウントされませんが、bytecountestimate()によってそれらの属性がカウントされます。このため、bytecountestimate()クエリと実際の使用量の間に大きな差異が生じる場合があります。
• 当社のAPM、ブラウザ監視、モバイル監視では、メトリックタイムスライスデータと呼ばれるデータ型が報告されます。このデータは他のデータ型とは異なり、NRDBに保存されないため、このデータに対してbytecountestimate()を使用しようとすると、混乱を招く可能性があります。このデータをクエリする際は、メトリクス名ではなくアプリケーション名でファセットすることをお勧めします。