データ インジェスト ガバナンスは 、組織によって収集されたテレメトリ データの最適な価値を得るためのプラクティスです。これは、多数のビジネス ユニットとワーキング グループを持つ複雑な組織にとって特に重要です。これは、New Relic データの取り込みを最適化するための 4 部構成のガイドの第 2 部であり、 オブザーバビリティの成熟度に関するシリーズ の一部です。
このガイドには、データの取り込みを最適化するための詳細な推奨事項が含まれています。このガイドを使用する前に、 一般的なデータ管理ドキュメント を確認することをお勧めします。
データ インジェスト ガバナンス プラクティスのこの段階では、組織によって現在生成されているすべてのテレメトリの概要を把握する必要があります。この単元では、取り込み統計をアカウント、テレメトリ タイプ、アプリケーションなどのさまざまなグループに分類することに重点を置いています。これらの数値は、取り込みデータの最適化および取り込みデータ の予測 段階に通知するために使用されます。
以下のディメンジョンについて、構造化された内訳レポートを作成する方法を学びます。
組織 組織内の特定のアカウント 請求可能なテレメトリタイプ さらに、以下のような詳細なブレイクダウンを作成する方法を学びます。
アプリケーション（APM |ブラウザ|モバイル） Kubernetesクラスタ インフラストラクチャの統合 組織内のどのグループがどのタイプのデータとその量を提供しているかを正確に理解します。
消費イベントの種類を理解する 請求可能なすべてのテレメトリは、 NrConsumptionおよびNrMTDConsumptionイベントで追跡されます。このガイドでは、 NrMTDConsumptionよりも詳細なリアルタイムデータを提供するNrConsumptionのクエリ方法に焦点を当てています。 NrConsumption属性usageMetricは、テレメトリタイプを示します。
NrConsumptionを使用すると、「過去30日間に各アカウントが取り込んだブラウザ監視データの量」などの質問をすることができます。および「過去30日間から摂取量はどのように変化しましたか？」そのデータを返すクエリは次のとおりです。
FROM NrConsumption SELECT sum ( GigabytesIngested ) WHERE usageMetric = 'BrowserEventsBytes' SINCE 30 days AGO COMPARE WITH 30 days AGO FACET consumingAccountName
応答には、アカウントごとに取り込んだブラウザ監視データのGB数が表示されます。
$ Banking platform, 75 GB, +2.9%
$ Marketing platform, 40 GB, -1.3%
以下は、さまざまなusageMetricタイプ、構成イベント（データが格納されるイベントタイプ）、およびデータ取り込みの作成を担当するエージェントまたはメカニズムのタイプの内訳です。
請求可能なテレメトリの内訳表 NrcConsumption.usageMetric。
構成要素のイベント
ソース
InfraHostBytes
SystemSample、StorageSample、InfrastructureEvent、 NetworkSample
インフラストラクチャー・エージェント
InfraProcessBytes
ProcessSample
インフラストラクチャー・エージェント
InfraIntegrationBytes
サードパーティのプラットフォーム統合のためのさまざまなイベント、および ContainerSample
オンホスト統合 と特定のクラウド統合
ApmEventsBytes
Transaction、 TransactionError 、そしておそらく WorkloadStatus
APMエージェント
TracingBytes
Span, SpanEvent
APMエージェントとOpenTelemetry
BrowserEventsBytes
Browser、 BrowserInteraction 、 Browser:EventLog 、 Browser:JSErrors 、 JavaScriptError 、 PageView 、 PageViewTiming 、 PcvPerf
Browserエージェント
MobileEventsBytes
Mobile、 MobileReqest 、 MobileRequestError 、 MobileSession 、 MobileHandleException 、 MobileCrash
モバイルエージェント
SeverlessBytes
クラウド固有のもの（AWS Lambdaのイベントなど）
クラウド特化型（AWS Lambdaとの連携など）
LoggingBytes
Log パターンのパーティション固有のイベントと同様に [partition].Log
各種（Fluentd、FluentBit、Syslog、クラウド専用ストリーミングサービス）
MetricEventBytes
Metric
メトリックAPIとそれを使用する統合（ディメンションメトリック ）から、またはブラウザーエージェント、APMエージェント、モバイルエージェント（メトリックタイムスライスデータ ）などのエージェントから。
CustomEventBytes
各種
さまざまなAPI。アカウントで利用可能なすべてのイベントタイプを表示するには、 SHOW EVENT TYPESを使用します 。
組織の月間インジェスト目標値を把握する 使用量ベースの価格設定モデル では、テレメトリデータとユーザーの両方が使用量とコストに影響します。このガイドは、テレメトリデータの価値を最大化することに焦点を当てています。このセクションでのユーザーの言及は、ユーザーとデータのバランスを取るためのさまざまなオプションを理解するのに役立ちます。
利用計画には、一般的に3つのタイプがあります。利用プランは、組織のインジェストターゲットの設定方法に影響する場合があります。
コミットメント契約 を結んでいる場合は、データ取り込みの月間目標予算が設定されている可能性があります。たとえば、1 日あたり 5 TB の目標と 100 人のフル プラットフォーム ユーザーを設定したとします。このタイプの契約では、ユーザーは "トレードオフ" になる可能性がありますが、組織内の他の利害関係者とこれについて話し合って、オブザーバビリティの目標に適した組み合わせを得られるようにすることをお勧めします。一部のお客様は、1 年間の使用量の変動を考慮して計画を立てますが、今のところ、1 か月の使用量の予算が、年間契約料金の合計を 12 で割ったものであると仮定しましょう。
必要なフルプラットフォームユーザーとコアユーザーの数がわかっている場合は、次の式を使用できます。
( monthly_target_spend - ( num_fso_users * per_fso_cost ) - ( num_core_users * per_core_cost ) ) / YOUR_INGESTED_DATA_COST
データコストがわかりませんか？ 取り込んだデータ を参照してください。
使った分だけ 従量制プラン では、事前に決定された年間コミットメントはありませんが、月々の支出には理解できる制限がある可能性があります。このモデルでは、次のことを行って、ターゲットの摂取量を決定します。
( monthly_target_spend - ( num_fso_users * per_fso_cost ) - ( num_core_users * per_core_cost ) ) / YOUR_INGESTED_DATA_COST
データコストがわかりませんか？ 取り込んだデータ を参照してください。
無料版 [#free-tier] すべての エディション で、毎月 100 GB のデータを無料で取り込むことができます。無料金額を超えるデータ取り込み価格の詳細については、 定価表を 参照してください。
ベースラインと変更モデリングに役立つNRQL操作を理解する レート 用途 特定の期間から取得されたデータのサンプルを取得し、特定のレートを生成する必要がある場合は、 rate演算子を使用します。たとえば、データの毎日のサンプルを取得し、それに基づいて30日のレートを計算します。
与えられたデータのサンプルに基づき、レートを計算する
過去1ヶ月の1日平均摂取量を確認する。
SELECT rate ( sum ( GigabytesIngested ) , 1 day ) AS 'Daily Ingest Rate (GB)' FROM NrConsumption WHERE productLine = 'DataPlatform' LIMIT MAX SINCE 30 days AGO
組織全体に対する私たちのシンプルな回答は
$ Daily ingest rate: 30.4 k
このクエリでは、先月の1日の取り込み量が約30TBであったことがわかります。
MonthOf 用途 これは、取り込み計算を特定の暦月に制限することが重要な場合に使用します。たとえば、統合のための摂取量は1月下旬に増加し、2月中旬まで続いた可能性があります。このオペレーターは、請求に使用される特定の暦月への取り込みをファセット化するのに役立ちます。
暦月別のファセット
SELECT sum ( GigabytesIngested ) AS 'Daily Ingest Rate (GB)' FROM NrConsumption WHERE productLine = 'DataPlatform' FACET monthOf ( timestamp ) LIMIT MAX SINCE 56 weeks AGO
結果の表は、かなり高い変動性を示しています。 8月と9月はかなりhotだったことに注意してください。その一部は私たちの組織の季節性ですが、テレメトリカバレッジの幅を広げることにも関連していました。
$ | MONTH OF TIMESTAMP | GB INGESTED |
比較する 用途 これは、ある期間と別の期間の間の摂取量または摂取率の変化量を評価する場合に使用します。これは、摂取量が予期せず上昇しているかどうかを知るために重要です。
簡易変更解析
SELECT sum ( GigabytesIngested ) FROM NrConsumption WHERE productLine = 'DataPlatform' AND usageMetric = 'BrowserEventsBytes' SINCE 6 months AGO UNTIL 1 week AGO TIMESERIES 7 weeks COMPARE WITH 2 months ago
成長パターンを理解するためのCOMPAREWITH の使用を示すチャートの例。
スライディングウィンドウ 用途 より広いパターンを確認するために、摂取の定期的な変動の影響を取り除く必要がある場合にこれを使用します。
テレメトリは本質的にノイズが多いです。実世界の現象は、信号に多くのランダムな山と谷を残すスパートで発生します。これは、現象の完全な複雑さを表示できるという点で優れています。ただし、トレンドを見ようとすると、細部に気を取られる可能性があります。 NRQLは、各データポイントを少し古いポイントと組み合わせることにより、時系列を滑らかにする強力な方法を提供します。これでは、極端なincreaseやdecreaseではなく、全体的な時間的傾向に焦点を当てましょう。
1日の摂取量に対する生の時系列のギザギザに注意してください。
FROM NrConsumption SELECT rate ( sum ( GigabytesIngested ) , 1 day ) WHERE productLine = 'DataPlatform' SINCE 26 weeks AGO TIMESERIES 1 DAY
平滑化なし の日次レート時系列
ここで、4日間のスライディングウィンドウ を使用して、1日のイベントの影響を減らすと、より鮮明な画像が表示されます。 4日は、 weekendsの影響を曖昧にするため、適切な選択です。したがって、日曜日のデータは、金曜日のデータなどとある程度結合されます。
FROM NrConsumption SELECT rate ( sum ( GigabytesIngested ) , 1 day ) WHERE productLine = 'DataPlatform' since 24 weeks ago TIMESERIES 1 DAY SLIDE BY 4 days
平滑化を使用し た日次レート時系列
デリバティブ 用途 これを使用して、特定の期間における統計的な変化率を推定します。変化率は、導関数を近似するために線形最小二乗回帰を使用して計算されます。
NRQLは、変化率を評価するためのいくつかのツールを提供します。前の例で見たように、ブラウザの指標が過去数か月で非常に大幅に増加したため、これは便利です。この変化率分析ではderivative演算子を使用しており、主な成長が9月初旬に起こったことをある程度確信できます。 7日間の導関数に基づく成長率はややマイナスであるように思われるため、BrowserEventsBytesの取り込みで現時点で新しいプラトーに達した可能性があります。
SELECT derivative ( sum ( GigabytesIngested ) , 7 day ) FROM NrConsumption WHERE productLine = 'DataPlatform' and usageMetric = 'BrowserEventsBytes' LIMIT MAX SINCE 3 MONTHS AGO UNTIL THIS MONTH TIMESERIES 1 MONTH slide by 3 days COMPARE WITH 1 WEEK AGO
7日間の派生物を使用して摂取傾向を調査する
bytecountestimate() アプリケーション（APM、ブラウザー、モバイル）による取り込み これらのクエリーは、各サブアカウントで実行するか、アカウント固有のチャートでダッシュボードを表示します。このクエリーは、1週間の集金に基づき、30日分の料金を見積もる。
30日料金の見積もり
APM：
FROM Transaction , TransactionError , TransactionTrace , SqlTrace , ErrorTrace , Span SELECT rate ( bytecountestimate ( ) / 10 e8 , 30 day ) AS 'GB Ingest' FACET appName SINCE 1 WEEK AGO
ブラウザ：
FROM PageAction , PageView , PageViewTiming , AjaxRequest , JavaScriptError SELECT rate ( bytecountestimate ( ) / 10 e8 , 30 day ) AS 'GB Ingest' FACET appName SINCE 1 WEEK AGO
モバイル：
FROM Mobile , MobileRequestError , MobileSession SELECT rate ( bytecountestimate ( ) / 10 e8 , 30 day ) AS 'GB Ingest' FACET appName SINCE 1 WEEK AGO
統合によるメトリックインジェスト このファセットに表示されるusage.Integration値の例は次のとおりです。
com.newrelic.mssql（New Relic MSSQLオンホスト統合）
com.newrelic.rabbitmq（New Relic RabbitMQオンホスト統合）
EC2（AWSのEC2統合版）
Lambda（ラムダの統合版）
これらのクエリは、特定の各アカウントまたはアカウント固有のグラフを含むダッシュボードで実行します。
30日間の料金を見積もります。
FROM Metric SELECT rate(bytecountestimate()/10e8, 30 day) FACET usage.integrationName SINCE 1 WEEK AGO
7日間の合計：
FROM Metric SELECT bytecountestimate ( ) / 10 e8 FACET usage . integrationName SINCE 1 WEEK AGO
さまざまなインフラストラクチャエンティティによるログの取り込み すべてのNewRelicテレメトリタイプ の中で、ログデータが最も変動が大きいものです。Logレコードにはほぼすべてのフィールドを含めることができ、多くの場合、特定のログレコードに何が含まれるかは不明です。共通のスキーマがないため、ログの取り込みのベースライン化には、他のデータ型のベースライン化よりも少し多くの分析が必要になる場合があります。
より便利な基本的なログ取り込み手法の1つは、ホスト、コンテナ、さらにはKubernetesクラスタごとに取り込みを推定することです。ここではいくつかの例を示します。
過去3時間のホストによるログの取り込み（合計）：
FROM Log SELECT bytecountestimate ( ) / 10 e8
WHERE host is not NULL SINCE 3 hours ago FACET host
ホストによるログの取り込み（30日レート）：
FROM Log SELECT rate ( bytecountestimate ( ) / 10 e8 , 30 day )
WHERE host is not NULL SINCE 3 hours ago FACET host
cluster_nameによるログの取り込み（30日レート）：
FROM Log SELECT rate ( bytecountestimate ( ) / 10 e8 , 30 day )
WHERE host is not NULL SINCE 3 hours ago FACET cluster_name
cluster_nameおよびcontainer_nameによるログの取り込み（30日レート）：
FROM Log SELECT rate ( bytecountestimate ( ) / 10 e8 , 30 day )
WHERE host is not NULL SINCE 3 hours ago FACET cluster_name , container_name
Kubernetesクラスターによる取り込み 30日料金の見積もり
FROM K8sClusterSample , K8sContainerSample , K8sDaemonsetSample , K8sDeploymentSample , K8sEndpointSample , K8sHpaSample , K8sNamespaceSample , K8sNodeSample , K8sPodSample , K8sReplicasetSample , K8sServiceSample , K8sVolumeSample SELECT rate ( bytecountestimate ( ) / 10 e8 , 30 day ) AS 'GB Ingest' FACET clusterName SINCE 1 WEEK AGO
プロセスサンプル ProcessSample 非常に大量のイベントになる可能性があります。この例では、コマンドラインごとに30日間の取り込みを計算します。
コマンド名による30日単位の見積もり
FROM ProcessSample SELECT rate ( bytecountestimate ( ) / 10 e8 , 30 day ) AS 'GB Ingested' FACET commandName SINCE 1 DAY AGO
eventType() 用途 クエリでイベントレベルの粒度が必要な場合や、アカウントに存在するカスタムイベントに慣れていない場合は、 eventType()演算子を使用してください。
多くの場合、複数のイベントを選択するクエリを使用します。これは主要な手段の1つであり、特定のエージェントまたは統合が送信するデータの量を判別する必要があります。
次のクエリは、Kubernetes統合が送信しているデータの量を示しています。
K8sControllerManagerSample ,
SELECT bytecountestimate ( ) / 10 e8 AS 'Gigabytes'
それ自体は強力ですが、単一の集計値のみを返します。
データ固有のイベントがどれだけ消費しているかを知るためにさらに深く掘り下げる必要がある場合は、ファセット句でeventType()を使用してその結果を取得できます。
前のクエリに句FACET eventType()を追加すると、次のようになります。
K8sイベントタイプごとの取り込みのリスト
イベントタイプを表示 用途 アカウントに存在するイベントが不明な場合は、 SHOW EVENT TYPESを使用してください。
SHOW EVENT TYPES 特定の期間のアカウント内のすべてのイベントタイプを一覧表示します。詳細については、「 イベントタイプ の表示」を参照してください。特定の時間枠を使用すると、特定のイベントがいつシステムに侵入し始めたかをよりよく理解するのに役立ちます。
FACETmetricName 用途 クエリでメトリック名レベルの粒度が必要な場合は、 FACET metricNameを使用します。
メトリックを実際に調査し、それぞれからのデータの相対量を把握するための最良の方法は、 SELECT FROM MetricクエリでFACET metricNameを使用することです。リストを絞り込むためにWHERE句を組み込むことができます。たとえば、 metricNameのテキストkube_podを含むメトリックの相対的な取り込み量を表示するには、次のようなクエリを実行します。
SELECT bytecountestimate ( ) / 10 e8 as 'Gigabytes' from Metric facet metricName where metricName like '%kube_pod%' since 1 day ago limit max
Metric 名前空間のmetricName 属性による取り込みのリスト
このデータ取り込みガバナンスの改善手順の一部として実行する主な手順は次のとおりです。
これらの手順については、以下で詳しく説明します。
ダッシュボードをインストールするには：
データ取り込みガバナンスのクイックスタート に移動します。ブラウザウィンドウの右上部分にある[ Install this quickstartをクリックします。 該当する場合: アカウント スイッチャーでプライマリまたはトップレベルのアカウントを選択します。 Doneをクリックします。クイックスタートのインストールが完了したら、 Data ingest governance baselineダッシュボードを開きます。 そうすると、新しくインストールされたダッシュボードが表示されます。
メインの概要タブには、強力な時系列表示を含む様々なチャートが表示されます。
組織全体のベースライン取り込み時系列
2つ目のタブでは、サブアカウントと利用指標ごとのベースラインレポートが表示されます。
組織全体のベースライン レポート ビュー
残りのタブには、ブラウザデータ、APMデータ、ログ、トレースなどの特定のテレメトリタイプの詳細ビューが表示されます。たとえば、次のスクリーンショットはブラウザの詳細ページを示しています。
単一のテレメトリタイプ（この場合はブラウザデータ）に焦点を当てた取り込みの詳細の例。
ディテールタブは以下の通り。
APM： ApmEventsBytes トレース： TracingBytes ブラウザ： BrowserEventsBytes モバイル： MobileEventsBytes インフラ（ホスト）： InfraHostBytes インフラ（プロセス）：InfraProcessBytes インフラ（統合）： InfraIntegrationBytes カスタムイベント： CustomEventsBytes サーバーレス： ServerlessBytes ピクシー： PixieBytes 前提条件の項で、毎月の使用量目標の考え方について説明しました。実際には、軌道に乗せるためにいくつかの目標値を設定してもよいでしょう。
デイリーレートまたは月間インジェストに関する組織全体の目標。 最適な内訳を確保するためのデータ種類ごとの目標（例えば、ログは1日1TB、メトリクスは1日2TBなど）。 特定のサブアカウントまたはビジネスユニットに対する目標。 この例では、組織の総摂取量を1か月あたり< 360TBに設定する組織があります。これは、摂取量を1日あたり20 TB（1か月あたり600 TB）以上に減らした後の新しい目標でした。
ターゲットの測定を容易にするために、静的な数値360000をSELECTステートメントに追加してしきい値の折れ線グラフを追加しました。
SELECT 360000 , rate ( sum ( GigabytesIngested ) , 30 day ) AS '30 Day Rate' FROM NrConsumption WHERE productLine = 'DataPlatform' since 30 days ago limit max compare with 1 month ago TIMESERIES 7 days
NRQLを使用して、ターゲットの30日間の取り込みターゲット を表す線をレンダリングできます。
日次レート目標線を適用することもできます。 360000を30で割ると、1日あたりの料金目標として12000を使用します。 Daily ingest rate (compare with 3 months prior)チャートを更新します。
SELECT 12000 , rate ( sum ( GigabytesIngested ) , 1 day ) AS avgGbIngestTimeseries FROM NrConsumption WHERE productLine = 'DataPlatform' TIMESERIES AUTO since 9 months ago limit max COMPARE WITH 3 months ago
NRQLを使用して、毎日の摂取ターゲット を表す線をレンダリングできます。
30日間の取り込みレポートを作成するには：
以前にインストールしたデータ取り込みガバナンスベースラインダッシュボードを開きます。 [ベースラインレポート ]タブをクリックします。 「過去30日間」の表の右上にある...をクリックして、 Export as CSV CSVをGoogleスプレッドシート、または選択したスプレッドシートにインポートします。 または、ダッシュボードをインストールしなかった場合は、このクエリを使用して、クエリビルダー でカスタムグラフを作成できます。
SELECT sum ( GigabytesIngested ) AS 'gb_ingest_30_day_sum' , rate ( sum ( GigabytesIngested ) , 1 day ) AS 'gb_ingest_daily_rate' , derivative ( GigabytesIngested , 90 day ) as 'gb_ingest_90_day_derivative' FROM NrConsumption WHERE productLine = 'DataPlatform' since 30 days ago facet consumingAccountName , usageMetric limit max
以下は、Google Sheetsに取り込んだシートの例です。
ベースラインダッシュボードの表形式ページからエクスポートされたスプレッドシート
スクリーンショットは、30日間のインジェストトータルでソートされたテーブルです。
必要に応じて、タイムラインと詳細の一部を自由に調整してください。たとえば、過去数か月の間にある程度の変化を感じるために、90日デリバティブを抽出することを選択しました。目的に合わせて、デリバティブの期間を簡単に変更できます。
最適化 や予測 など、データ取り込みガバナンスの他のフェーズを容易にするために、レポートに有用な列を追加します。次のフィールドは、最適化と計画の決定をガイドするのに役立ちます。
注意事項成長の異常とそれに関する説明を記載すること。予測される大きな成長がある場合は、それを示す。 技術担当者：特定のアカウントのマネージャーまたは特定のテレメトリタイプに関連する人物の名前。 摂取量の異常を検出するためのいくつかの手順を次に示します。
この取り込みアラートガイド を使用して、データ消費量の増加に驚かないようにしてください。少なくとも、以下を作成します。
季節的な増加を超えて、データ取り込みの月間目標値を超えた場合に通知する閾値アラート 取り込みデータの急激な増加を通知する異常アラート アラートを使用して消費の異常を特定することに加えて、NewRelicLookoutを使用して潜在的な摂取の異常を調査できます。
Lookoutを使用すると、ほぼすべてのNRQLクエリを提供でき、特定の期間にわたって異常を検索します。以下のビューは、このクエリに基づいています。
SELECT rate ( sum ( GigabytesIngested ) , 1 day ) AS avgGbIngest FROM NrConsumption WHERE productLine = 'DataPlatform' FACET usageMetric
Lookoutを使用して、 usageMetric によって取り込みの異常を見つけることができます。
このビューを取得するには、ファセットフィールドをconsumingAccountNameに変更します。
Lookoutを使用して、 AccountName を使用することにより、取り込みの異常を見つけることができます。
前のセクションでは、 NrConsumptionをプライマリソースとして使用する取り込みbaselineダッシュボードをインストールしました。その高レベルのビューに加えて、 bytescountestimate()を使用してほぼすべてのイベントまたはメトリックの取り込みを推定する他の視覚化を作成できます。 bytescountestimate()の詳細な概要については、前提条件のセクションで説明しました 。
エンティティ内訳ダッシュボードをインストールするには：
ベースライン・ダッシュボードに使用したのと同じクイックスタート にアクセスします。
ブラウザウィンドウの右上のセクションで[ Install this quickstartをクリックします。
ダッシュボードのインポート機能 を使用して、APM、ブラウザモニタリング、モバイルモニタリング、またはKubernetesクラスタを含むすべてのアカウントにインストールする必要があります。 （パートナーシップがある場合：このダッシュボードをパートナーシップ所有者アカウントまたはPOAにインストールしないでください。）このダッシュボードは複数のアカウントにインストールできます。親/子アカウント構造がある場合：ダッシュボードを親アカウントにインストールし、ダッシュボードを変更して、アカウント固有のグラフをすべて1つのダッシュボードに含めることができます。
Doneをクリックします。
クイックスタートのインストールが完了したら、 Data governance entity breakdownsダッシュボードを開きます。
エンティティ内訳ダッシュボードは、 bytecountestimate（） を使用して、アプリケーションやクラスター名などの有用な属性によるファセットの取り込みを行います
このセクション を参照して、これらのブレイクダウンでどのイベントタイプが使用されているかを正確に確認することができます。
ヒント これらのクエリは、 NrConsumptionのような事前に集計されたデータソースからは機能しないため、より多くのリソースを消費します。一部の環境でより適切に機能するように、追加のWHERE }句とLIMIT句を使用して時間枠を調整する必要がある場合があります。
New Relicのクラウド統合は、多くの場合、データ取り込みの成長の重要なソースになる可能性があります。優れた視覚化がなければ、成長がどこから来ているのかを特定するのは非常に難しい場合があります。これは、これらの統合の構成が非常に簡単であり、組織の通常のCI/CDパイプラインの一部ではないためです。また、正式な構成管理システムの一部ではない場合もあります。
幸いなことに、この強力な New Relic Instant Observability から直接 インストールできます。
このパッケージによってインストールされる個々のダッシュボードには、次のものが含まれます。
AWSの統合 Azureの統合 GoogleCloudPlatformの統合 オンホストインテグレーション Kubernetes このクイックスタート には、ほぼすべてのクラウド統合、オンホスト統合、Kubernetes統合によってデータを分類する非常にきめ細かいダッシュボードのセットが含まれています。
次の質問に答えることで、ベースラインデータを解釈し、正しい推論を行う能力に自信をつけることができます。これらの質問には、 データ取り込みベースライン およびデータ取り込みエンティティの内訳 ダッシュボードを使用して回答できます。説明されているようにこれらのダッシュボードをインストールし、これらの質問のうちどれだけに答えられるかを確認してください。
質問 過去1週間の組織全体（すべてのアカウント）の一般的な1日の摂取率はどれくらいですか？ 3ヶ月前は何でしたか？ 取り込みによる（組織全体の）テレメトリタイプの上位3つは何ですか？各テレメトリタイプとその最新の30日間の取り込み率を一覧表示します。 この組織の取り込みに貢献しているアカウントはいくつありますか？ 現在、月に50TBを超える貢献をしているアカウントはいくつありますか？ 過去30日間の取り込みに関して上位3つのアカウントは何ですか？ 最も消費量の多いアカウントのこの1月の暦月のGB摂取量はどれくらいですか？ 過去30日間のApmEventsBytes摂取量の上位3つのアカウントは何ですか 過去9か月間に、特定のアカウントのテレメトリタイプの取り込みに関して最大の増加はどれですか。減少はどうですか？ ApmEventsBytesに最も貢献しているアカウントに移動し、 data governance entity breakdown dashboard }をインストール/開きます。過去24時間の取り込みごとの上位3つのAPMアプリケーションと、それぞれの24時間の取り込み率をリストします。
プロセス セクションでは、データ取り込みの視覚化とレポートの作成について説明しました。これで、データ駆動型の視覚的アプローチを使用してデータの取り込みを確認できます。このアプローチを使用して、自分と同僚が共同作業を行うことができます。
今後は、どのビジュアライゼーションに使用するかを決定します。
その他の関連リソースは次のとおりです。
