みなさんこんにちは。マネージドサービス課の塩野です。
今回もNew Relicのクエリ言語であるNew Relic Query Language(NRQL)についての話題です。
クラスター全体の平均CPU使用率は正常なのに、アラートが鳴り止まない。調査すると、特定の1台だけが95%を超えて悲鳴を上げていた、という経験はないでしょうか。全体の平均値は便利な指標ですが、個別のサーバーに潜む問題を見落とす原因にもなります。
インフラエンジニアが本当に知りたいのは、システム全体の健康状態と同時に、個々のサーバーの状況です。New RelicのNRQLには、この課題を解決するFACET句という強力な機能があります。FACETを使うと、データを特定の属性でグループ化し、全体像と個別のバラつきを同時に把握できます。
基本:ホスト別にメトリクスを可視化する
最も基本的なFACETの使い方は、メトリクスをホスト名ごとに分けて表示することです。InfrastructureエージェントがMetricとして収集しているCPU使用率を、各ホストごとに可視化してみましょう。
SELECT average(host.cpuPercent) FROM Metric FACET entity.name SINCE 1 hour ago TIMESERIES
FACET entity.nameという一行を加えるだけで、個々のサーバーのCPU使用率が別々の線グラフとして描画されます。どのサーバーが高負荷なのか、特定のサーバーだけCPUが急上昇していないかが即座に分かります。
数十台から数百台のサーバーがある環境では、LIMIT句で表示数を絞り込むと便利です。
SELECT average(host.cpuPercent) FROM Metric FACET entity.name SINCE 1 hour ago LIMIT 10
このクエリは、CPU使用率が高い上位10台だけを表示します。リソースを最も消費しているサーバーを素早く特定できるため、トラブルシューティングの効率が上がります。
実践:FACET CASESで役割ごとにグループ化する
個々のサーバーよりも「役割ごとのグループ」で状況を把握したい場面も多いでしょう。ここで活躍するのがFACET CASESです。サーバーのホスト名に役割を示す接頭辞(web-01、db-01など)をつける命名規則を活かせば、役割ごとのグループを自動作成できます。
SELECT average(host.cpuPercent) FROM Metric FACET CASES( WHERE entity.name LIKE 'web%' AS 'Web Servers', WHERE entity.name LIKE 'db%' AS 'DB Servers', WHERE entity.name LIKE 'cache%' AS 'Cache Servers' ) SINCE 1 hour ago TIMESERIES
ホスト名がwebで始まるサーバーをWebサーバーグループ、dbで始まるサーバーをDBサーバーグループとして自動分類します。サーバーが増減してもクエリの書き換えが不要で、動的なインベントリ管理が実現できる点が便利です。
注意:グループ内での平均化について
ただし重要な注意点があります。FACET CASESでグループ化すると、同じグループ内のサーバーのメトリクスが平均化されます。つまり、Webサーバーグループに10台のサーバーがある場合、その10台全体の平均CPU使用率が表示されます。
これは全体傾向を把握するには便利ですが、グループ内の特定の1台だけに問題がある場合、その異常が平均値に埋もれてしまう可能性があります。たとえば、9台が20%、1台が90%のCPU使用率だった場合、グループ全体では約27%と表示され、一見正常に見えてしまいます。
そのため、FACET CASESは「役割ごとの全体傾向を把握する」用途に適しており、個別サーバーの異常検知にはFACET entity.nameを併用することをおすすめします。まずFACET CASESで異常のあるグループを特定し、次にFACET entity.nameでそのグループ内の問題サーバーを絞り込むという2段階のアプローチが効果的です。
応用:クラウド属性を活用した多角的な分析
FACETの真価は、クラウド環境のメタデータと組み合わせたときに発揮されます。New Relicは、AWSやGCPなどの属性情報を自動的に収集するため、それをFACETで活用できます。
たとえば、Availability Zone(AZ)ごとの負荷分散を確認する場合は次のようなクエリが使えます。
SELECT average(host.cpuPercent) FROM Metric FACET aws.availabilityZone SINCE 1 hour ago TIMESERIES
特定のAZだけCPU使用率が高い場合、そのAZに負荷が集中していることが分かります。ロードバランサーの設定見直しや、リソース追加の判断材料になるでしょう。
インスタンスタイプ別のパフォーマンス比較も有用です。
SELECT average(host.cpuPercent) FROM Metric FACET ec2InstanceType SINCE 1 day ago
高価なインスタンスが本当に性能を発揮しているのか、安価なインスタンスで十分なのかを確認できます。適切なリソース配分とコスト最適化の両立に役立ちます。
運用Tips:ダッシュボードのインタラクティブフィルター
New Relicのダッシュボードでは、FACETを使ったチャートを「フィルター」として機能させられます。チャート内の要素をクリックすると、ダッシュボード全体がその要素でフィルタリングされる仕組みです。
この機能は、チャートを追加する際に「Filter the current dashboard」オプションを有効にすることで利用できます。バーチャート、ヒートマップ、パイチャート、テーブルで使用可能です。
障害発生時に、負荷の高いサーバーをFACETチャートから見つけ、クリック一つでそのサーバーの詳細をダッシュボード全体で確認できます。従来は各チャートで個別にホスト名を指定し直す必要がありましたが、その手間が不要になります。
まとめ
New RelicのFACET機能の本質的な価値は、全体像と個別のバラつきを同時に把握できる点にあります。平均値だけでは見落としてしまう異常を即座にあぶり出せることが最大の強みです。
深夜にアラートが鳴ったとき、最初に確認すべきはFACET entity.nameで各サーバーの状態を可視化したグラフです。問題が特定ノードの故障なのか、トラフィック急増による全体負荷なのかを1秒で判別できます。
FACET CASESは役割ごとの全体傾向把握に便利ですが、グループ内で平均化されるため、個別サーバーの異常検知にはFACET entity.nameとの併用が効果的です。クラウド環境では、Availability ZoneやインスタンスタイプといったメタデータをFACETで活用することで、キャパシティプランニングやコスト最適化の判断材料が得られます。
100台のサーバーから1台の異常を見つけ出すことは、もはや困難な作業ではありません。FACETを使いこなすことで、迅速かつ的確な異常検知が可能になります。
この記事がどなたかのお役に立てれば幸いです。
関連記事
◆ 塩野 正人
◆ マネージドサービス部 所属
◆ X(Twitter):@shioccii
◆ 過去記事はこちら
前職ではオンプレミスで仮想化基盤の構築や運用に従事。現在は運用部隊でNew Relicを使ってサービス改善に奮闘中。New Relic User Group運営。