序章
今日、アプリケーションとデータのインフラストラクチャはこれまでにないほど複雑で、内部の動作に関する豊富なデータが生成されています。そのため、モニタリングの手法は進化し、DevOps チーム、アプリケーション開発者、運用およびインフラストラクチャ・チームは、オブザーバビリティ（可観測性）のベストプラクティスを採用するようになりました。オブザーバビリティを実践する上で最も重要ことは、スタック内のすべてのデータを計測することです。
しかし、これらすべてのデータを自分たちだけで処理しようとすると、別の課題が発生するだけです。正しいデータを正しいフォーマットで記録していますか？ソフトウェアへの需要の増加に伴って増加する負荷を処理するのに十分なデータ・パイプラインの大きさがありますか？New Relicでは、オブザーバビリティは不安を増やすものではなく、不安を軽減するものであるべきだと考えています。
そのためには、統一されたデータベースを備えた単一のオブザーバビリティ・プラットフォームが必要です。
-
すべてのテレメトリーデータを一箇所に集め、システム内のすべてのデータポイントを接続して見ることができるため、ビジネスに影響を与える問題を特定、理解、解決することができます。
-
柔軟なスキーマに基づいて構築されているので、今まで考えたことがないような質問にも素早く回答を得ることができます。
-
ビジネスの成長に合わせてスケールアップし、予測しづらい需要の変化に対応できるよう、制限を設けていません。
このような機能がTelemetry Data Platformの特徴です。
世界で最も強力な運用データ分析プラットフォーム「Telemetry Data Platform」
Telemetry Data PlatformはNew Relic Oneの原動力となっています。「世界で最も強力なテレメトリー・プラットフォーム」と呼ぶのには理由があります。クエリの応答時間の中央値は60ミリ秒と非常に速く、99%のパーセンタイルの応答時間は2秒以下です。500億件以上のレコードをスキャンするような非常に大規模なクエリであっても、99%が30秒以内に終了します。Telemetry Data Platform は、1分間に10億以上のデータポイントをインジェストするので、どのお客様の需要が増加した場合でもTelemetry Data Platform は何億ものデータポイントの増分を簡単に処理します。
その裏では、Telemetry Data Platformという非常に大規模な分散システムが動いています。マルチテナントクラウドサービス上で大規模なクエリが数千のCPUコア上で同時に実行され、数十億のレコードを数秒で処理できるようになっています。
Telemetry Data Platformは、世界中のお客様の予測不可能な需要をサポートするために、制限なく拡張できるように設計されています。過去10年間で顧客基盤が小売からエンターテイメント、アパレルからヘルスケア、ゲームからEコマースに至るまで多岐にわたって増えており、Telemetry Data Platformの規模は拡大してきました。また、マルチテナントアーキテクチャを採用しているため、小規模なお客様でも大規模なお客様と同様の大規模なコンピューティングリソースの恩恵を受けることができます。
単一のホスト、単一のアプリケーションからスタートする場合でも、あるいは何万ものホストやアプリケーションインスタンスを持つエンタープライズ企業でも、Telemetry Data Platform はお客様のニーズをサポートします。お客様のビジネスやデータの成長に合わせて、Telemetry Data Platform は、お客様のビジネス要件をサポートするためにスケールアップしていきます。
では、Telemetry Data Platform はどのようにしてこれらを実現しているのでしょうか？このホワイトペーパーでは以下の内容を説明しています。
-
Telemetry Data Platformの背後にあるデータモデル
-
Telemetry Data Platformに格納されているテレメトリーデータタイプ
-
大量のデータを簡単に検索できるSQLライクなクエリ言語
-
Telemetry Data Platformのインジェストとクエリの方法を学ぶための重要なリソース
時系列データを目的としたテレメトリ・データ・プラットフォームの構築方法
優れたデータベースは、データの保存や検索以上のものを提供してくれます。優れたデータベースは、分析や集計などの付加価値サービスを提供するため、チームは重い計算をデータベースサーバに任せることができます。データベースのクエリ機能は、その有用性のもう一つの重要な側面であり、そのクエリ能力はデータモデルによって決定されます。
Telemetry Data Platform は時系列データを格納しています。時系列データとはデータポイントを時間順にインデックスしたものであり、これはテレメトリーデータにおいて重要な分類です。このセクションでは、時系列データのための3つの異なるモデルを紹介し、柔軟性のあるスキーマを持つリレーショナルモデルを採用した理由を説明します。
Note: このセクションでは、メトリクス、つまり一定の間隔でグループ化された、または収集された測定値の集合体についての議論が必要です。このホワイトペーパーでは、メトリクスおよびその他のテレメトリーデータタイプと Telemetry Data Platform との関係について、後ほど詳しく説明します。
一次元の時系列中心のモデル: シンプルだが十分ではない
上で定義したように、時系列データとは、特定の期間や間隔でインデックス化したデータのことです。
各行が時系列を表す次の例を考えてみましょう。各時系列は、メトリック名といくつかのタグによって識別されます。
| Metric name | Tags | Time series (time:value pairs) |
|---|---|---|
|
cpuTime |
host=server1, dataCenter=east | t1:22, t2:14, t3:34, ... |
| cpuTime | host=server2, dataCenter=east | t1:37, t2:11, t3:94, ... |
| responseTime | database=mysql, data=inventory | t1:15, t2:45, t3:90, t4:57... |
| ... | ... | ... |
典型的なクエリAPIは、時系列を名前やフィルタで選択したり、タグでグループ化したりする仕組みを提供しています。単一のメトリック名をクエリする必要がある場合、これはうまく機能しますが、複数のメトリック名を一度にクエリする必要がある場合は、あまり便利ではありません。
例えば、cpuTimeSpentとnumRequestsProcessedの2つのメトリクスを持っているとします。リクエストごとのCPUコストの経時変化を観察したいとします。概念的には、これはcpuTimeSpent/numRequestsProcessedという単純な除算です。しかし、時系列データを問い合わせるためにこの式を表現するのは簡単ではありません。多くのシステムでは、クライアントは両方の時系列を取得し、クライアント側で除算を行います。実際、このような検索と除算を行うのに20行のコードが必要な例を見てきました。(データベースの中には、複数のメトリクスを扱うためにベクトルマッチングを使用するものもあります。この方法でも機能はしますが、ユーザーがアクロバティックなことをしないといけません。)
プログラミング言語の観点から見ると、時系列中心のモデルの欠点は、1次元の配列しかサポートしていないことです。言い換えると、時系列データは時間をインデックスとしてもつ配列です。複数の配列を扱う場合、このモデルを使用するシステムは、配列内の要素を相関させるためのベクトルマッチングのような複雑なメカニズムに頼らなければなりません。これはアプリケーションにとってよくないことです。「これらのシステムはデータベースシステムの利点のいくつかを提供していましたが、アプリケーション開発者がよく利用する伝統的なデータベース機能の多くを欠いていました」とGoogleのSpanner: Becoming a SQL Systemの著者は書いています。そして「重要な例としてはロバストなクエリ言語があります。開発者はアプリケーションのデータを処理したり集計したりするために複雑なコードを書かなければなりませんでした」。
リレーショナルモデルかつ固定スキーマ: テーブルが多すぎて結合が困難
一次元データの問い合わせには厳しい制約が課されるため、いくつかのデータベースでは時系列データにリレーショナルモデルを使用しています。このモデルでは、各データポイントはリレーショナルテーブルの行として表示され、タイムスタンプとタグは列として表示されます。例えば、以下のようになります。
| time | host | dataCenter | cpuTime | memoryUsed |
|---|---|---|---|---|
| t1 | server1 | east | 17 | 2078 |
| t2 | server2 | east | 48 | 3810 |
| ... | ... | ... | ... | ... |
このアプローチでは、SQLの力をフルに活用することができますが、各メトリックとタグスキーマに対して明示的にcreate table文を実行する必要があります。これは不便なだけではありません。スキーマの数が多い場合、テーブルの数が多くなり、データベースに負荷がかかります。同様に、スキーマの変更（alter table）を実行すると、大規模なパフォーマンス問題が発生します。
また、マルチメメトリクスクエリもやはり問題になるでしょう。このモデルでは、（上記の例のように）1つのテーブルに複数のメトリクスを入れることができますが、1つのスキーマではすべてのデータにフィットしないため、テーブルをまたいでクエリを行う必要がある場合があります。
このシナリオを考えてみましょう。ホストメトリクス用のhostテーブルと、numRequestsなどのアプリケーションメトリクス用のapplicationテーブルがあります。cpuTime / numRequestsを計算するには、time 列で SQL 結合を行い、2 つのテーブルをつなぎ合わせる必要があります。2つのテーブルの行が常に完全に一致するタイムスタンプを持っていない限り、time_bucket()functionをtime列に適用して、タイムスタンプをtimeバケットの境界にスナップする必要があります。例えば、以下のようになります。
select time_bucket('1 hour', hostTable.time) as bucketTime, sum(cpuTime) / sum(numRequests) from hostTable, applicationTable where time_bucket('1 hour', processTable.time) = bucketTime group by bucketTime order by bucketTime
この例では、time列に対してgroup byを使用して時系列を生成する非直感的な方法を示しています。対照的に、New Relic Query Language (NRQL)では、直感的なtimeseries句を使用して、複数のテーブルにまたがって時系列を問い合わせることができます。
Telemetry Data Platformの秘伝のソース: 柔軟なスキーマを備えたリレーショナルモデル
複数テーブルの問題を解決するために、Telemetry Data Platform は柔軟なスキーマを持つリレーショナルモデルを使用しています。このモデルでは、テーブル内の行は同じスキーマを使用する必要はありません。実際には、より使いやすくするためにcreate tableステートメントは一切ありません。Telemetry Data Platform のデータベースが新しいカラムをインジェストすると、自動的にテーブルのスキーマに追加されます。本質的には、Telemetry Data Platform は、すべての行のスキーマの統合をテーブルスキーマとして使用します。
（次の例のように）Telemetry Data Platform の柔軟なスキーマでは、各行はデータポイントを表します。1行目はhostとdataCenterをタグとしてcpuTimeメトリクスを保持しています。2 行目はhostとappNameをタグとしてappRequestsメトリクスを保持しています。(metricName列は実際にはメタデータ列です。メタデータ列については、このドキュメントの "Schema Introspection" セクションで説明します)。
| time | metricName | cpuTime | host | dataCenter | appName | appRequests |
|---|---|---|---|---|---|---|
| t1 | cpuTime | 27 | server1 | east | ||
| t2 | appRequests | server1 | invoiceApp | 78 | ||
| ... | ... | ... | ... | ... | ... | ... |
列が行に存在しない場合、その値はnullです（灰色のセルで示されています）。このような場合には、「is null」と「is not null」の演算子は通常通りに動作します。たとえば、hostタグを持つすべてのメトリクスの名前を取得するには、select uniques(metricName) where host is not nullと実行します。
プログラミング言語の観点から見ると、これは2 次元配列です。それぞれのメトリクスはテーブルのスキーマとして表現されるため、複数のメトリクスをクエリするのも簡単に記述できます。たとえば、NRQLを使用してリクエストごとのCPUコストの時系列データを生成するには、次のように実行します。
From Metric select sum(cpuTime) / sum(appRequests) timeseries
モニタリング業界では、「次元」メトリクスとは、経過時間関連の属性（開始時間および終了時間）、エンティティID、地域、ホストなどの属性をキーと値のペアとして添付したメトリクスデータを指します。詳細に属性を取得することで、深い分析とクエリが可能になります。Telemetry Data Platformは、以下のソースからの次元メトリックをサポートしています。
New Relic のMetric API(上記ツールで使用されている基礎となる API)
スキーマの自己生成: New Relicのファーストクラスオブジェクトであるメタデータ
Telemetry Data Platformがデータをインジェストすると、スキーマの自己生成(introspection)のためにカラム名と型を返すkeyset()関数を使って、そのデータに基づいたテーブルスキーマを自動的に生成します。行が列の名前として表現できるキーと値のペアのリストとしてみなすことができ、そしてこの関数はキーの集合を返すため、「keyset」と呼ばれています。
keyset()関数は行を入力として受け取り、スキーマ（名前と型を持つ列のリスト）を出力として生成します。MetricNameカラム（"Metric "テーブルでのみ利用可能）と合わせて、Telemetry Data Platformはリッチなメタデータクエリ機能を提供し、ユーザーはスキーマ自己生成により、NRQLにより分析をフルパワーで適用することができます。
NRQLのいくつかの例を紹介します。
| NRQLクエリ | 使い方 |
|---|---|
select keyset() from myTable |
This query returns the schema of rows timestamped in the past hour; since 1 hour ago is the default time window for a query. |
select keyset() from myTable since 8 days ago until 7 days ago |
This query asks, “What was the schema like a week ago?” Since it’s a standard select statement, you can use the standard time range clauses. |
select keyset() from myTable where hostname is not null |
This query returns the schema of rows with a hostname column. You can use the standard where clause. |
select keyset() from Metric where metricName = ‘cpuTime’ |
This query returns the schema for the given metric name only. This is a handy way to get the tag set for a metric name. |
select keyset() from Metric facet metricName |
Facet is the NRQL equivalent of group by. This query returns the schema of many metric names, grouped by metric name. |
select uniqueCount(metricName) from Metric |
This query tells you how many unique metric names you have. |
select uniques(metricName) from Metric where metricName = ‘cpu%’ |
This query returns all metric names starting with cpu. |
select uniques(metricName) from Metric where hostname = ‘server1’ |
This query returns all metric names with a hostname tag of server1. |
次の章では、Telemetry Data Platform に格納されている主なデータ型について説明します。
テレメトリーの統一: Telemetry Data Platformの主要なデータタイプ
オブザーバビリティの時代には、すべてを計測し、すべてのテレメトリーデータを一箇所に表示する必要があります。New Relicでは、メトリクス、イベント、ログ、トレース（略してMELT）がオブザーバビリティに不可欠なデータタイプであると考えています。あらゆるものを計測し、MELTを使用してシステム内の関係性や依存関係、詳細なパフォーマンスや健全性に関する基本的な知識を形成することは、オブザーバビリティを実践していることを意味します。しかし、これらの接続を形成するためには、Telemetry Data Platformのような柔軟なスキーマ上に構築された単一の統一されたデータベースが必要です。
Telemetry Data Platformは、4つの主要なテレメトリデータタイプをサポートしています。
-
メトリクス: 一定の時間間隔でグループ化された、または収集された測定値の集合体。
-
イベント: システム内のある時点で発生した離散的な事象
-
ログ: タイムスタンプ付きの（通常は構造化されている）テキストベースのメッセージ
-
トレース: 分散トレースと呼ばれるもので、マイクロサービスのエコシステム内の異なるコンポーネント間のイベント（またはトランザクション）の離散的で不規則な因果連鎖のサンプルです。
New Relicではこれらのテレメトリーデータタイプは、
-
異なるデータタイプは異なるテーブルに格納されていますが、Telemetry Data Platformという1つの場所に格納されています。
-
1つのデータモデル（柔軟なスキーマを持つリレーショナルモデル）で統一されています。
-
すべてのデータを同じ言語（NRQL）でクエリすることができます。
NRQL + telemetry data = 統一されたユーザー体験
Telemetry Data Platformを使用すると、各テレメトリデータタイプで一貫性のあるデータモデルとクエリ言語を得ることができます。また、データのクエリだけでなく、プラットフォームの多くの部分には、API内にNRQLが統合されています。たとえば、NRQLを使用してアラート条件を定義したり、NRQLを使用してイベントからメトリクスへの変換ルールを作成したりすることができます。このようなパワーと柔軟性があれば、日々の作業が格段に楽になります。
それでは、これらのデータタイプのそれぞれがTelemetry Data Platformでどのように使用されているかを見てみましょう。
大きなメトリクスのスケーリング
メトリクスはテレメトリーの世界では定番です。大量のデータや定期的に収集されたデータに対して、事前に何を求めるかが分かっている場合に有用です。
規模が重要：他の追随を許さないTelemetry Data Platform の規模
Telemetry Data Platform の分析機能は、大規模データで輝きます。例えば、複数のデータセンターに何万台ものホストを抱える大企業で、どのデータセンターに最も負荷がかかっているかを知りたいとします。次のようなクエリを使用することができます: select average(cpuPercent) from Metric facet dataCenter since 7 days ago. 何千ものホストが複数のデータセンターに分散していることを考えると、このクエリはすべてのホストのcpuPercentメトリックを集約する必要があり、10,000 以上の時系列にアクセスする必要があります。メトリクスやテレメトリデータの世界では、これはよく知られている「高カーディナリティ」問題であり、データセット内で一意な値が大量に存在すると、データベースのデータ解析能力を超えてしまうことがあります。ほとんどの時系列データベースは、少数の時系列のみをチャート化するように設計されているため、このようなタイプのクエリを実行するのに苦労します。しかし、Telemetry Data Platformは、ミリ秒単位で簡単に結果を返します。
Telemetry Data Platformは、以下のメトリクスタイプをサポートしています。
| メトリクス名 | 説明 | クエリ関数 |
|---|---|---|
gauge |
Represents a value that can increase or decrease with time. Examples of gauges include the temperature, CPU usage, and memory. For example, there is always a temperature, but you are periodically taking the temperature and reporting it. |
|
count |
Measures the number of occurrences of an event. Examples include cache hits per reporting interval and the number of threads created per reporting interval. Examples include cache hits per reporting interval and the number of threads created per reporting interval. |
|
summary |
Used to report pre-aggregated data, or information on aggregated discrete events. Examples include transaction count/durations and queue count/durations. |
|
クエリを最適化するためにメトリクスをより長い時間枠で事前に集計することは一般的な手法ですが、Telemetry Data Platformはこの手法を最大限に活用しています。例えば、Telemetry Data Platformは、1分、5分、15分、1時間、6時間、1日のメトリクスデータの集計を生成します。クエリ時に、クエリワーカーは、与えられた時間軸に対して最適なロールアップウィンドウを選択します。例えば、1年に渡るクエリでは1日ロールアップを使用しますが、12時間のクエリでは1分ロールアップを利用します。
イベントを使って非連続に発生する事象の洞察を得る
イベントは、オブザーバビリティのための重要なテレメトリーデータタイプであり、重要なポイントを離散的かつ詳細に記録し分析に活用できます。イベントの一般的な例としては、デプロイメント、トランザクション、エラーなどがあります。イベントを監視することで、リアルタイムでの詳細な分析が可能になります。
Telemetry Data Platformのイベントを使用すると、以下のことが可能になります。
-
自由な形式での取り込み: New Relic APMエージェントによって生成されたイベントに加えて、イベントAPIを使用して、カスタムイベントデータをTelemetry Data Platformの任意のスキーマを持つ任意のテーブルに挿入することができます。
-
NRQL クエリ: イベントはTelemetry Data Platformに保存されているため、NRQLの機能をフルに活用してイベントを照会することができます。これとは対照的に、他の多くのテレメトリシステムでは、イベントを二流のオブジェクトとして扱い、単純な挿入と検索しかサポートしていません。
-
イベントからメトリクスを生成する機能: イベントからメトリクスを生成するサービスは、イベントをメトリクスに集約して保持容量を減らし、クエリをさらに高速化します。イベントからメトリクスを生成するルールを定義するだけで、毎秒何千ものイベントを保存する代わりに、1分間に1つのメトリクスレコードでトランザクションのパフォーマンスを追跡します。
カスタムイベント
カスタムイベントは、あらゆるクリエイティブな方法で使用することができ、アプリケーションのトランザクションなどの大量のイベントを追跡するのに最適です。例えば、ユーザーがウェブサイトで注文するたびにイベントを挿入し、ユーザーID、金額、購入した商品の数、処理時間を記録することができます。このような粒度の高いデータは、集約されたメトリクスの機能を超えて、個々のトランザクションを調査する機能を提供します。各トランザクションは個別のイベントなので、属性間の相関関係を含め、任意の属性の分布を分析することができます。Telemetry Data Platformのカスタムイベントの唯一の要件は、各行にタイムスタンプが必要なことです。
New Relic Agentのイベント
New Relicエージェントはイベントを作成し、そのイベントをクエリして独自のチャートを作成することができます。例えば、APMのTransactionイベントやNew Relic BrowserのPageViewイベントをクエリすることで、デフォルトのチャートよりも深い分析を行うことができます。さらに、クエリAPIを使用して、Telemetry Data Platformに送信したカスタムイベントを活用するNew Relic Oneアプリケーションを作成することができます。
以下の例では、ウェブサイトでの発注を追跡するカスタムイベントデータに対してNRQLクエリを実行する例を示しています。
| Query | Usage |
|---|---|
select histogram(orderDollarAmount, 1000) from Order |
Get a distribution of the order size. |
select uniqueCount(userId) from Order |
Find out how many unique users placed orders. |
select average(processingTime) from Order facet cases(where numItems < 10, where numItems < 50, where numItems < 100) |
Find out if the number of items purchased have an impact on processing time. (This query analyzes correlation between two fields. You can’t do this with two metrics because the transaction level correlation is lost when the numbers are aggregated into two metrics.) |
select average(processingTime) from Order timeseries since 7 days ago |
Find out the average processing time of all orders. (You can get aggregation on fields, just like with metrics. If you had a processingTime metric in the “Metric” table, the query to get this time series from the Metric table would be identical, except that you would be selecting from the Metric table. This showcases the unified query interface for events and metrics.) |
ログのスライシングとダイシング
もともとのテレメトリーデータタイプであるログは、特定のコードブロックが実行されたときにシステムが生成するテキストの行です。開発者は、コード、データベース、キャッシュ、ロードバランサー、あるいはインプロセス計測に適していない古いプロプライエタリなシステムのトラブルシューティングにログを利用しています。
New Relic Logs in Contextは、Telemetry Data PlatformのLogテーブルに書き込み、そこからNRQL経由でログデータにアクセスすることができます。ログのクエリはイベントのクエリと何ら変わりません。つまり、NRQLの全機能をログ分析に利用できます。ディメンションメトリクスと同様に、ログ行にはタグがあり、各タグはログテーブルのカラムとして表現されます。「message」列自体にログテキストが含まれています。ログの取り込み時に任意のタグを指定することができます。
| Timestamp | Host | Message |
|---|---|---|
2020-02-18 18:38:15 |
vpn15c |
%ASA-6-725007: SSL session with client outside:38.108.108.47/35770 to 203.53.240.37/443 terminated |
2020-02-18 18:38:15 |
vpn15c |
%ASA-6-725001: Starting SSL handshake with client outside:38.108.108.47/35770 to 203.53.240.37/443 for TLS session |
2020-02-18 18:38:15 |
vpn15c |
%ASA-6-725016: Device selects trust-point OUTSIDE for client outside:38.108.108.47/35770 to 203.53.240.37/443 |
トレースのスパン
トレースは、マイクロサービスのエコシステム内の異なるコンポーネント間のイベント（またはトランザクション）の離散的で不規則な因果連鎖のサンプルです。トレースは「スパン」と呼ばれる特別なイベントを形成し、因果連鎖を追跡するメカニズムを提供します。そのために、各サービスは「トレースコンテキスト」と呼ばれる相関識別子をお互いに渡し、このトレースコンテキストを使ってスパンに属性を追加します。
New Relic の分散トレースは、Telemetry Data Platform の「Span」テーブルに書き込みを行い、テーブルの各行が1スパンを表します。
| Timestamp | EventType | TraceID | SpanID | ParentID | ServiceID | Duration |
|---|---|---|---|---|---|---|
2/21/2019 15:34:23 |
Span |
2ec68b32 |
aaa111 |
Vending Machine | 23 | |
2/21/2019 15:34:22 |
Span |
2ec68b32 |
bbb111 |
aaa111 |
Vending Machine Backend | 18 |
2/21/2019 15:34:20 |
Span |
2ec68b32 |
ccc111 |
bbb111 |
Credit Card Company | 15 |
2/21/2019 15:34:19 |
Span |
2ec68b32 |
ddd111 |
ccc111 |
Issuing Bank | 3 |
ご期待通り、NRQL を使用して Telemetry Data Platform のスパンデータをクエリすることができます。クエリの例については、ドキュメントを参照してください。
NRQL: Telemetry Data Platformへのゲートウェイ
New Relic Query Language (NRQL、"Nerkel "と発音します) は、Telemetry Data Platform と対話するためのクエリ言語です。これは SQL に似た言語で、時系列のクエリを素早く簡単に行うための拡張機能を備えており、データを自分の条件で探索するために使用できる多くの句や関数を備えています。
New Relicでは、New Relic APMやNew Relic Infrastructureなどのツールで提供されている、すぐに使えるチャートやダッシュボードの多くを構築するために、舞台裏でNRQLを使用しています。また、New Relic Oneチャートビルダーを使ってチャートを作成したり、New Relic Oneアプリケーションをカスタマイズしたりする際には、基本的なものから高度なものまでさまざまなNRQLクエリを利用することができます。多くの場合、チャートを作成するためのクエリを書くのは1行書くのと同じくらい簡単ですが、チャートビルダーのクエリ自動補完機能を使えば、クエリを書くのがさらに簡単になります。
SQLに慣れているユーザーは、基本的にNRQLの使い方を理解しているはずです。NRQLとSQLの構文はほぼ95%重複しており、残りの5%は時系列の構文を表現します。
以下に、NRQLの注目すべき時系列拡張機能を、クエリとチャートの例とともに紹介します。
TIMESERIES: この句は、タイムスタンプによってインデックス化されたデータポイントを生成し、NRQLのほとんどのクエリで利用できます。ここでは、durationフィールドの95パーセンタイルを時間経過とともにグラフ化した例を示します。SELECT percentile(duration, 95) FROM PageView SINCE 1 day AGO TIMESERIES
COMPARE WITH:この句は、比較のために、SINCE/UNTILウィンドウから派生した出力に加えて、同じ時間幅をこの句で指定した分だけ過去にシフトした出力の2つのセットを生成します。ここでは、今日と昨日のセッション数を比較する例を示します。SELECT average(duration) FROM PageView SINCE 2 hours AGO COMPARE WITH 1 day AGO
FACET: この句は、group byを時系列データ用に調整したNRQL版です。次のクエリは、国別の訪問者の地理的内訳を提供し、グループのページビューの持続時間で自動ソートします。SELECT percentile(duration, 95) FROM PageView FACET countryCode
NRQLについてもっと読みたい場合はNRQLユーザーズマニュアルとNRQL達人の秘訣をご覧ください。
Telemetry Data Platformがミリ秒のパフォーマンスを実現する方法
Telemetry Data Platform は毎秒何千ものクエリを、数テラバイトもの保存データの中から答えを必要とするお客様に提供しています。すべてのデータを移動して検索しても意味がないので、代わりにデータにクエリを送信しています。
すべてのクエリは、クラスタ内のデータの位置を特定するクエリルータから始まり、元のクエリを数百ときには数千のワーカーに送信して、関連するデータがどこにあるかをスキャンします。Telemetry Data Platformのマルチテナントクラスターでは、メモリとIOの必要性のバランスをとるために、非常に大きなクエリをより小さな断片に分割しています。これらのクエリの断片は他のルーターに送られ、データを保持しているワーカーに部分的なクエリを配信します。最近実行されたクエリに対してはTelemetry Data Platform のインメモリキャッシュを使って最速に結果を提供し、頻度の低いクエリにはワーカーがディスクからデータをスキャンして対応します。各ワーカーがクエリに答えるためにファイルを読み込むと、プロセスは逆向きに戻っていきます。まず、各ファイルの結果がワーカー上でマージされます。その後、各ワーカーの結果は、元のルーターがすべてのデータを持っているまで再帰的にルーターを介してマージされ、完成した回答がユーザーに返されます。
参考リンク
Telemetry Data Platformは、New Relicユーザーが容易にアクセスできるようになっており、データのインジェストやクエリを行う方法が多数用意されています。
-
データのインジェスト
-
Event API: イベントデータをTelemetry Data Platformに送信します
-
Metric API: カスタムメトリクスデータをTelemetry Data Platformに送信します
-
データのクエリ
-
グラフィカルUIを使って簡単にチャートを作成
-
New Relic Oneチャートビルダー: データのクエリを実行して、カスタムチャートやその他のビジュアライゼーションを作成することができます。また、複数のチャートを含むカスタムダッシュボードを作成することもできます。
-
New Relic Oneダッシュボード: New Relicプラットフォームのどこからでもデータを組み合わせて、柔軟でインタラクティブな視覚化を実現できます。
-
プログラマブルなAPIを使ってTelemetry Data Platformのデータを活用したアプリを作成
-
InsightsクエリAPI: データをクエリするためのREST API
-
NerdGraph: New RelicのGraphQL APIは、効率的で柔軟性の高いAPIクエリ言語です。オーバーフェッチやアンダーフェッチなしに、必要なデータを正確にリクエストすることができます。New Relic NerdGraph GraphiQLエクスプローラを使用して、New Relic Query Language (NRQL) クエリを作成することができます。
NRQL言語については以下のリファレンスを参照ください。
