[New Relic] 実務で使えるNRQL逆引き集〜 SREの現場で役立つ20のクエリパターン

みなさんこんにちは。マネージドサービス課の塩野です。

今回もNew Relicのクエリ言語であるNew Relic Query Language（NRQL）についての話題です。

SREやインフラエンジニアの日常業務では、システムの状態を素早く把握し、問題を迅速に特定する能力が求められます。New RelicのNRQL(New Relic Query Language)は、膨大な監視データから必要な情報を引き出すための強力なツールです。

この記事では、実際の運用現場でよく遭遇する20の課題に対して、すぐに使えるNRQLクエリパターンを紹介します。各クエリはコピー&ペーストで利用でき、皆さんの環境に合わせて少しカスタマイズするだけで実践できる内容になっています。

この記事で学べること

リソース監視とキャパシティ管理のためのクエリパターン
パフォーマンス分析とトラブルシューティングの手法
インフラストラクチャ運用を効率化するクエリ
アラートとSLO管理に役立つ分析方法

想定読者と前提知識

この記事は、New Relicの基本的な使い方を理解しており、これからNRQLを活用してさらに深い分析を行いたいと考えているエンジニアを対象としています。NRQLの基本構文(SELECT、FROM、WHERE)について理解があれば、記事の内容を十分に活用できます。

NRQLクエリの基本構造

本題に入る前に、NRQLの基本構造を簡単におさらいしましょう。

基本的なクエリ形式

SELECT 関数(属性) 
FROM データタイプ 
WHERE 条件 
SINCE 期間 
FACET グループ化する属性

よく使う集計関数

NRQLでは以下のような集計関数が頻繁に使われます。

average(): 平均値を計算
count(): イベント数をカウント
max() / min(): 最大値・最小値を取得
percentile(): パーセンタイル値を計算（例: percentile(duration, 95)で95パーセンタイル）
sum(): 合計値を計算
stddev(): 標準偏差を計算（データのばらつきを評価）

データソースの種類

New Relicでは主に以下のようなデータソースを扱います。

Metric: ディメンショナルメトリクスデータ（インフラエージェントからのhost.xxx形式など）
Transaction: APMから収集されるトランザクションデータ
PageView: ブラウザ監視からのページビューデータ
Log: ログデータ

※上記以外のデータソースは下記をご参照ください

docs.newrelic.com

それでは、実際のクエリパターンを見ていきましょう。

カテゴリ別クエリ集

リソース監視とキャパシティ管理

1. CPU使用率が低いホストの特定（オーバースペック検出）

長期間にわたってCPU使用率が低いホストは、コスト最適化の対象になります。このクエリでは、過去1週間の平均CPU使用率をホスト別に表示し、リソースの利用状況を把握します。

SELECT average(host.cpuPercent) AS 'Avg CPU %'
FROM Metric 
FACET hostname 
SINCE 1 week ago

ポイント: 結果を見て平均CPU使用率が常に20%未満のホストがあれば、インスタンスサイズのダウンサイジングを検討できます。より詳細な分析には、max()やpercentile()も併せて確認しましょう。

2. メモリ使用量の増加傾向を分析（メモリリーク検出）

時間とともにメモリ使用量が増加し続けているサーバーは、メモリリークの可能性があります。derivative()関数を使って、1時間ごとのメモリ増加率を可視化します。

SELECT derivative(host.memoryUsedBytes, 1 hour) 
FROM Metric 
FACET hostname 
TIMESERIES 
SINCE 24 hours ago

ポイント: derivative()は時系列データの変化率を計算します。右肩上がりのグラフが続く場合、メモリリークの調査が必要です。

3. ディスク容量の枯渇予測

現在のディスク使用量の傾向から、あと何日で容量が尽きるかを予測します。これにより、ディスクパンクを事前に防げます。

SELECT average(host.disk.usedPercent) 
FROM Metric 
FACET hostname, device 
TIMESERIES 
SINCE 7 days ago

ポイント: このクエリで得られた傾向から、手動で容量枯渇の時期を見積もります。New RelicのアラートやPREDICT句と組み合わせることで、より高度な予測も可能です。

4. ネットワークトラフィックが最大のホストを特定

ネットワーク帯域を大量に消費しているホストを特定することで、帯域不足の原因を突き止められます。

SELECT sum(host.net.transmitBytesPerSecond) 
FROM Metric 
FACET hostname 
TIMESERIES 
SINCE 3 hours ago

ポイント: transmitBytesPerSecondは送信バイト数なので、受信側も確認したい場合はreceiveBytesPerSecondも併せてチェックしましょう。

5. リソース使用状況の週次比較

先週と今週のリソース使用状況を比較することで、トラフィックの増減や異常なパターンを検出できます。

SELECT average(host.cpuPercent) 
FROM Metric 
TIMESERIES 
COMPARE WITH 1 week ago 
SINCE 1 day ago

ポイント: COMPARE WITH句を使うことで、過去の同時期との比較が簡単にできます。異常な増減があれば、さらに詳しく調査しましょう。

パフォーマンス分析とトラブルシューティング

6. エラー率をアプリケーション別に可視化（サイレント障害の検出）

全体の平均では正常に見えても、特定のアプリケーションだけがエラーを吐いている場合があります。percentage()関数を使って、各アプリケーションごとのエラー率を計算します。

SELECT percentage(count(*), WHERE numeric(httpResponseCode) >= 500) AS 'Error Rate %'
FROM Transaction 
FACET appName 
TIMESERIES 
SINCE 1 hour ago

ポイント: percentage()関数は、全トランザクションのうち条件（この場合httpResponseCode >= 500）を満たす割合をパーセントで返します。numeric()関数でhttpResponseCodeを数値に変換することで、比較演算子が正しく機能します。FACET appNameを使うことで、アプリケーションごとに個別にエラー率が計算され、特定のアプリだけエラー率が高い場合に素早く検出できます。トランザクション名で分析したい場合は、FACET nameを使用することもできます。

7. レスポンスタイムの分布を確認

レスポンスタイムの分布を確認することで、性能のばらつきやボトルネックを特定できます。histogram()関数を使います。

SELECT histogram(duration, 50, 20) 
FROM PageView 
SINCE 1 week ago

ポイント: histogram(duration, 50, 20)は、0〜50秒の範囲を20個のバケットに分割してヒストグラムを作成します。多くのリクエストがどの時間帯に集中しているかが分かります。

8. パーセンタイル値で性能を多角的に評価

平均値だけでなく、50パーセンタイル（中央値）、95パーセンタイル、99パーセンタイルを同時に表示することで、性能の全体像を把握できます。

SELECT percentile(duration, 50, 95, 99) 
FROM Transaction 
TIMESERIES AUTO 
SINCE 6 hours ago

ポイント: 95パーセンタイルや99パーセンタイルは、一部のユーザーが経験している最悪のパフォーマンスを示します。SLO管理にも重要な指標です。

9. 標準偏差でサービスの安定性を評価

標準偏差を使うことで、レスポンスタイムのばらつき（不安定性）を数値化できます。前日との比較も行います。

SELECT stddev(host.cpuPercent) 
FROM Metric 
TIMESERIES 
COMPARE WITH 1 day ago 
SINCE 3 hours ago

ポイント: stddev()が大きいほど、値のばらつきが大きいことを示します。リリース後に標準偏差が増加している場合、パフォーマンスが不安定になっている可能性があります。

10. トランザクションのスループットを分析

単位時間あたりのトランザクション数（スループット）を確認することで、システムの処理能力や負荷状況を把握できます。

SELECT rate(count(*), 1 minute) 
FROM Transaction 
WHERE appName = 'YourAppName' 
TIMESERIES 
SINCE 6 hours ago

ポイント: rate()関数は、指定した時間単位あたりのイベント数を計算します。この例では1分あたりのトランザクション数を表示しています。

インフラストラクチャ運用

11. ホスト一覧の取得とタグによるフィルタリング

特定のタグが付いていないホスト（野良リソース）を発見することで、管理されていないリソースを特定できます。

SELECT count(*) 
FROM Metric 
FACET hostname 
WHERE tags.Project IS NULL

ポイント: タグ管理はインフラ運用の基本です。このクエリで管理タグが欠けているホストを定期的にチェックしましょう。

12. サービスやプロセスの停止履歴を確認

インフラストラクチャで発生したイベントを確認することで、サービスの起動・停止などの変更履歴を追跡できます。

SELECT count(summary)
FROM InfrastructureEvent 
WHERE category = 'services' 
FACET hostname, summary
SINCE 1 day ago

ポイント: InfrastructureEventには、プロセスやサービスの起動・停止、設定変更などのイベントが記録されています。summary属性には具体的な変更内容が含まれており、LIKE '%stopped%'などでフィルタリングすることで特定の種類のイベントに絞り込めます。障害調査時に「いつ」「どのホスト」で変更が発生したかを追跡する際に役立ちます。

13. アベイラビリティゾーン別のパフォーマンス比較

特定のAZだけパフォーマンスが悪い場合、クラウドベンダー側の問題かもしれません。AZ別にCPU使用率を比較します。

SELECT average(host.cpuPercent) 
FROM Metric 
FACET awsAvailabilityZone 
TIMESERIES 
SINCE 6 hours ago

ポイント: クラウド環境では、特定のAZで一時的な問題が発生することがあります。このクエリで素早く切り分けができます。

14. OS バージョン別のホスト台数を集計

セキュリティアップデートの計画などで、OSバージョンごとのホスト台数を把握したい場合に使います。

SELECT count(*) 
FROM SystemSample 
FACET operatingSystem 
SINCE 1 day ago

**ポイ`: 古いOSバージョンが残っている場合、セキュリティリスクとなる可能性があります。定期的な棚卸しに活用しましょう。

15. パッケージ更新履歴の確認

システムパッケージの変更履歴を確認することで、予期しない設定変更を検出できます。

SELECT summary, hostname
FROM InfrastructureEvent 
WHERE category = 'packages' 
SINCE 1 week ago 
LIMIT 100

ポイント: InfrastructureEventのcategory = 'packages'には、yumやaptなどのパッケージマネージャーによる変更履歴が記録されています。特定のホストに絞り込みたい場合は、WHERE category = 'packages' AND hostname = 'web-server-01'のように条件を追加します。予期しない設定変更は障害の原因になるため、変更管理の一環として定期的にチェックすることをおすすめします。

アラートとSLO管理

16. アラート発火回数をCondition別にランキング

どのアラート設定が最も頻繁に発火しているかを確認します。通知疲れの原因を特定できます。

SELECT count(*) 
FROM NrAiIncident 
FACET conditionName 
SINCE 1 week ago

ポイント: NrAiIncidentにはアラート発火の履歴が記録されています。FACETクエリの結果はデフォルトで発火回数の多い順に表示されるため、どのアラート設定が最も頻繁に発火しているかが一目で分かります。発火回数が多すぎるアラートは、閾値の見直しが必要かもしれません。本当に重要なアラートが埋もれないよう、定期的に見直しましょう。

17. SLO達成率の計算

可用性のSLOを計算します。この例では、HTTPステータスコードが500未満のリクエストの割合を算出しています。

SELECT percentage(count(*), WHERE numeric(httpResponseCode) < 500) AS 'Success Rate %'
FROM Transaction 
SINCE 1 day ago

ポイント: SLOを99.9%に設定している場合、このSuccess Rateが99.9%以上であれば目標達成です。numeric()関数を使ってhttpResponseCodeを数値に変換することで、比較演算子（<, >, <=, >=）が正しく動作します。エラー率の傾向を時系列で見たい場合は、末尾にTIMESERIESを追加しましょう。

18. エラーバジェットの燃焼速度を監視

現在のエラー率が続いた場合、あとどれくらいでエラーバジェットが尽きるかを推定します。

SELECT (1 - (percentage(count(*), WHERE numeric(httpResponseCode) < 500) / 99.9)) * 100 AS 'Burn Rate %'
FROM Transaction 
SINCE 1 hour ago

ポイント: Burn Rateが高い場合、このままではSLOを達成できない可能性があります。早めの対策が必要です。numeric()関数を使ってhttpResponseCodeを数値変換することで、正確なエラー率の計算ができます。このクエリは、99.9%のSLO目標に対してどれだけ早くエラーバジェットを消費しているかを示します。

19. 異常値の検出（CPU使用率）

CPU使用率が異常に高いホストを検出します。threshold値は環境に合わせて調整してください。

SELECT max(host.cpuPercent) 
FROM Metric 
WHERE host.cpuPercent > 90 
FACET hostname 
SINCE 1 hour ago

ポイント: 90%以上のCPU使用率が続く場合、キャパシティ不足やアプリケーションの問題が考えられます。

20. 時間帯別のパフォーマンス比較

営業時間と夜間でパフォーマンスがどう変わるかを比較します。時間帯によるリソース配分の最適化に役立ちます。

SELECT average(duration) 
FROM Transaction 
FACET hourOf(timestamp) 
SINCE 1 week ago

ポイント: hourOf()関数は、タイムスタンプから時間帯だけを抽出します。ピーク時間帯の特定や、バッチ処理の影響分析に便利です。

クエリ作成のベストプラクティス

効率的なクエリの書き方

NRQLクエリを作成する際は、以下の点に注意すると、より効率的で保守性の高いクエリになります。

1. 適切な時間範囲を指定する

必要以上に長い時間範囲を指定すると、クエリの実行時間が長くなります。まずは短い時間範囲で試し、必要に応じて拡大しましょう。

2. WHERE句で事前にフィルタリングする

FACET句でグループ化する前に、WHERE句で不要なデータを除外することで、クエリのパフォーマンスが向上します。

3. 集計関数を適切に選ぶ

単純な傾向を見たい場合: average()
外れ値の影響を避けたい場合: percentile()
データのばらつきを評価したい場合: stddev()

それぞれの関数の特性を理解して使い分けましょう。

よくある間違いと対策

間違い1: 平均値だけを見て判断する

平均値は外れ値の影響を受けやすいため、パーセンタイル値も併せて確認することをおすすめします。

間違い2: データソースの混同

ディメンショナルメトリクス(FROM Metric)とイベントデータ(FROM SystemSampleなど)は異なるデータ構造を持っています。属性名も異なる場合があるので、公式ドキュメントで確認しましょう。

間違い3: TIMESERIESとの組み合わせに注意

一部の関数(predictLinear()など)は、TIMESERIESクエリでは意図した結果が得られない場合があります。公式ドキュメントの推奨事項を確認しましょう。

パフォーマンスを考慮したクエリ設計

大量のホストを扱う場合

LIMIT句を使って結果を制限し、必要なデータだけを取得するようにしましょう。デフォルトのLIMITは10ですが、最大5000まで指定できます。

複雑な計算が必要な場合

ネストされた集計やサブクエリを活用することで、1つのクエリで複雑な分析が可能です。ただし、クエリが複雑になりすぎると保守性が下がるので、適度なバランスを保ちましょう。

まとめ

この記事では、SREやインフラエンジニアが実務で遭遇する20の典型的な課題に対して、すぐに使えるNRQLクエリパターンを紹介しました。

NRQLを活用した運用の改善ポイント

1. データに基づいた意思決定

勘や経験だけでなく、実際のメトリクスデータに基づいて判断することで、より正確な問題特定と対策が可能になります。

2. 問題の早期発見

定期的にこれらのクエリを実行し、ダッシュボードに組み込むことで、問題が深刻化する前に検知できます。

3. コスト最適化

リソースの使用状況を可視化することで、過剰なリソースを削減し、コストを最適化できます。

4. チーム全体での知識共有

よく使うクエリをドキュメント化し、チーム内で共有することで、誰もが同じレベルの分析ができるようになります。

さらに学習を深めるためのリソース

NRQLについてさらに深く学びたい方は、以下の公式リソースをご活用ください。

この記事がどなたかのお役に立てれば幸いです。

blog.serverworks.co.jp