Table of Contents
Great systems are not just built. They are monitored.
MetricFire runs Graphite and Grafana as a fully managed service for growing engineering teams, taking care of storage, scaling, and version updates so your team doesn't have to. Plans start at $19/month, billed per metric namespace rather than per host, and include engineer-staffed support. Integrations work natively with Heroku, AWS, Azure, and GCP, and data is stored with 3× redundancy in SOC2- and ISO:27001-certified data centres.
はじめに
現代のオブザーバビリティプラットフォームは、共通して同じ成果を約束しています。つまり、システムに計測機能を組み込み、テレメトリーデータを送信することで、重要なポイントを迅速に可視化できるというものです。体験としては、ほぼすぐに使い始められる「ターンキー」のように感じられるかもしれません。しかし、この共通の約束の裏側では、オブザーバビリティをどのように実現すべきかについて、プラットフォームごとに大きく異なるアプローチが取られています。内部的には、エージェントのインストール、自動検出されるインテグレーションの有効化、そして統合されたテレメトリーモデルを通じたデータのクエリといった形で実現されることが一般的です。
あるプラットフォームは、インフラ、APM、ログ、トレーシング、シンセティック監視などを単一の画面で扱える包括的なエコシステムを目指しています。一方で、メトリクスにより特化し、明確さや明示的な設定、予測可能な挙動を重視するプラットフォームも存在します。
New RelicとHosted Graphiteは、この2つの思想を象徴する好例です。どちらも強力なツールであり、本番環境レベルのモニタリングに対応しています。しかし、それぞれが最適化している運用スタイルは異なっており、その違いを理解することは、単なる機能比較以上に価値のあることです。
統合の広さ vs. フォーカスされたモニタリング
New Relicは、フルスタックのオブザーバビリティプラットフォームとして位置付けられています。インフラ監視、アプリケーションパフォーマンスモニタリング（APM）、ログ、分散トレーシング、リアルユーザーモニタリング、シンセティック監視などが同一のエコシステム内で利用可能です。また、クラウドプロバイダー、データベース、メッセージキュー、ランタイム、コンテナシステムなどをカバーする幅広いインテグレーションのカタログも備えています。この広さには明確な利点があります。それは統合です。チームはホスト、サービス、アプリケーションを統一されたデータモデルのもとで計測でき、スタックの複数レイヤーからのテレメトリーが1か所に集約されます。ツールの乱立を減らしたい組織にとって、これは非常に魅力的です。
しかし、この広さは表面積の増加にもつながります。インテグレーションが増えるほど設定経路も増えるためです。プラットフォームはメトリクス、ログ、トレースを一貫したインターフェースに統合する必要があり、その統合自体が必然的に複雑さを生みます。たとえば、単一のインフラエージェントをインストールするだけで、ホストのCPU、メモリ、ディスクI/O、実行中のサービス、さらにHAProxyやKubernetesコンポーネントといった検出されたインテグレーションが可視化されます。そこにAPMの計測を追加すると、トランザクショントレース、サービスマップ、アプリケーションレベルのゴールデンメトリクスが同じUIに表示されるようになります。
一方、Hosted Graphite（MetricFire提供）は、よりフォーカスされたアプローチを取っています。これは本質的にメトリクスファーストのモニタリングプラットフォームです。特定のアプリケーションスタックを前提としたり、すべてのテレメトリータイプを統合しようとしたりするのではなく、柔軟なメトリクス収集および可視化システムを提供します。チームはCarbon/Graphiteプロトコル、StatsDのカウンターやゲージ、またはMetricFireのインジェストレイヤーを経由したPrometheusエクスポーターを通じて時系列データを送信し、その後Graphite関数を使って時系列メトリクスからGrafanaダッシュボードを構築します。このシステムはサービスを自動検出したり、モニタリングの枠組み全体を事前構成したりはしませんが、その基盤を提供し、チームが意図的に形作ることを可能にします。考慮すべきレイヤーも少なくなります。
要するに、New Relicはエコシステムの網羅性を重視し、Hosted Graphiteは明確さとコントロールを重視しています。
意図されたデフォルト vs. 意図的な設定
プラットフォーム間の大きな思想的違いは、アラートやダッシュボードの扱い方にも表れます。
New Relicは、意図されたモニタリングパターンを重視しています。レイテンシ、トラフィック、エラー、サチュレーションからなる「ゴールデンシグナル」といった概念は、オンボーディング体験やアラートテンプレートに直接組み込まれています。ベースライン異常検知は、時間の経過とともに期待されるメトリクスの挙動を自動的に計算し、静的なしきい値のみに依存するのではなく、動的なしきい値を超えた際にインシデントをトリガーします。すべての条件をゼロから構築する代わりに、チームは標準化されたモニタリングのベストプラクティスからスタートできます。
- このような自動化は、特に構造化されたガイダンスを求めるチームにとって非常に有用です。しかし、標準化されたアラートパックは前提条件に依存します。特定のメトリクスが存在すること、特定のテレメトリーが計測されていること、命名規則やベースラインが環境と一致していることなどが前提となります。異種混在環境やカスタムスタックのような現実のシステムでは、これらの前提は調整が必要になる場合があります。ひとつの経験則として、「自動化は初期の摩擦を減らすが、検証の必要性をなくすわけではない」と言えるでしょう。
一方、Hosted Graphiteは異なる方法でアラートにアプローチします。Graphite Alertsは、例えば movingAverage(api.requests.count, 5min) > 500 のような明示的な時系列クエリを評価し、条件ロジックは完全に可視化され、メトリクスのパス構造に直接結びついています。自動生成されたゴールデンシグナルのバンドルや、ベースライン異常テンプレートが自動適用されることはありません。その代わり、どのメトリクスが重要か、どのしきい値が問題を意味するか、条件がどれだけ継続する必要があるかを、チーム自身が正確に決定します。
- これはより意図的なセットアップを必要としますが、同時に隠れた前提を最小限に抑えます。設定したものがそのまま動作し、汎用的なベストプラクティステンプレートを環境に合わせて解釈するような抽象レイヤーは存在しません。ここでのトレードオフは明確です。意図されたデフォルトはオンボーディングを加速させる一方で、意図的な設定は長期的な予測可能性を高めます。
2026年時点で、Hosted Graphiteは本番環境にデプロイする前にしきい値の調整を支援する「アラートシミュレーション機能」を導入しています。不透明な異常検知モデルに依存するのではなく、このシミュレーターはユーザーが過去データに対してアラート条件をテストし、どのタイミングでどのようにトリガーされるかを正確に確認できるようにします。これにより、抽象化を増やすことなく、アラート設定をより反復的かつ透明性の高いものにし、ノイズの削減に役立ちます。
統一クエリ言語 vs. 直接的なメトリクス操作
クエリもまた、思想的な違いが現れる領域のひとつです。
New Relicは、NRQLと呼ばれるSQLライクなクエリ言語を使用しており、メトリクス、イベント、ログ、トレースを横断して操作することができます。テレメトリーの種類は共通のデータプラットフォームに統合されているため、チームは単一のクエリモデル内でエンティティをまたいだクエリや高度な集計を実行できます。これにより、同一のインターフェース内でアプリケーションパフォーマンスとインフラメトリクスを関連付けるといった、強力な相関分析ワークフローが可能になりますが、その一方で一定の抽象化も伴います。ユーザーはNRQLを習得し、プラットフォームが内部的にテレメトリーをどのようにモデル化しているかを理解する必要があります。NRQLはメトリクス、イベント、ディメンショナルデータ型を横断して動作し、たとえばエンティティGUIDでファセット分割しながらサービス全体のエラーレートを集計するといったクエリを可能にします。この統一モデルはクロステレメトリー分析を実現しますが、同時にデータが内部でどのように保存されているかの理解を必要とします。SQLに慣れたエンジニアにとって学習コストは必ずしも高くはありませんが、プラットフォーム固有の思考モデルであることには変わりありません。
一方、Hosted Graphiteは、より直接的なクエリアプローチを採用しています。メトリクスはパス構造を持ち、Graphite関数が時系列データを変換し、その結果がアラート評価に使用されます。この思考モデルはシンプルで、基盤となるデータと密接に結びついています。Graphiteのクエリモデルは、階層的なメトリクスパス（例：servers.web01.cpu.user）に直接作用し、描画やアラート評価の前に変換関数を適用します。生のメトリクスと可視化の関係は、ワークフロー全体を通じて透明に保たれます。すでにGraphiteやStatsDのパターンに慣れているチームにとっては、軽量で予測可能に感じられるでしょう。
ここでの違いは機能の優劣ではなく、抽象化の深さにあります。New Relicはテレメトリーを統合し汎用化する一方で、Hosted Graphiteはメトリクスを直接公開し、操作するアプローチを取っています。
一目でわかる比較
| カテゴリ | New Relic | Hosted Graphite |
|---|---|---|
| プラットフォームの範囲 | フルスタックのオブザーバビリティ（インフラ、APM、ログ、トレース、シンセティック監視） | メトリクス中心のモニタリング＋Lokiベースのログ（オプション） |
| インテグレーションモデル | エージェントベースのサービス検出とエンティティモデルを備えた豊富なインテグレーションカタログ | スタック前提なしの柔軟なデータ取り込み（Graphite、StatsD） |
| ダッシュボード | 組み込みダッシュボードとテレメトリービュー；NRQLクエリによるカスタムダッシュボード | Hosted Grafana＋Graphiteネイティブダッシュボード |
| アラート手法 | 事前構成されたゴールデンシグナル、異常検知、NRQLベースのアラート条件 | 明示的なメトリクスベースのアラートルールと透明性の高いしきい値ロジック |
| クエリ言語 | NRQL（SQLライクでメトリクス・イベント・ログを横断） | Graphite関数とメトリクスパスクエリ；Prometheus互換クエリ |
| 抽象化レベル | 高い（サービス全体で統一されたテレメトリとエンティティモデル） | 低い（時系列データの直接操作と明示的なメトリクス構造） |
| オンボーディングスタイル | 意図されたデフォルトと自動検出サービスによるガイド付きセットアップ | メトリクス定義を完全に制御できる、意図的な設定主導のセットアップ |
| 料金モデル | データ取り込み量、ユーザー数、テレメトリタイプに基づく従量課金 | メトリクス量と保持期間に基づく予測しやすいプラン型料金 |
| コスト予測性 | データ取り込みやテレメトリ拡張により変動する可能性あり | スケールしても比較的シンプルで予測しやすい |
| 最適な用途 | エコシステムの広さやクロススタックの相関分析を求めるチーム | 明確さ、コントロール、コスト予測性、メトリクス単位の精度を重視するチーム |
まとめ
New RelicとHosted Graphiteを比較する際、機能数に注目したくなるのは自然なことです。しかし、機能の多さだけでは運用への適合性は決まりません。より重要なのは、チームがどのようにテレメトリーと向き合いたいかという点です。多くの場合、これはアーキテクチャのレイヤリングに関する問いになります。つまり、テレメトリーをより高次の運用的な概念に抽象化するプラットフォームを好むのか、それとも生の時系列データのプリミティブをそのまま扱い、そこから積み上げていくアプローチを好むのか、ということです。
- 広範なインテグレーション対応、テレメトリー横断の相関分析、そしてガイド付きのモニタリングパターンを重視するのであれば、New Relicのようなフルスタックプラットフォームがワークフローに適しているかもしれません。複数のオブザーバビリティレイヤーを一元化し、セットアップを加速するための意図された構造を提供します。
- 一方で、メトリクス構造の直接的なコントロール、明示的なアラートロジック、そしてより小さな概念的フットプリントを重視するのであれば、Hosted Graphiteのようなメトリクスファーストのシステムは、よりクリーンで長期的に扱いやすい体験を提供する可能性があります。抽象化を減らし、モニタリングモデルを定義したデータと密接に結びつけます。
オブザーバビリティツールは単にシグナルを収集するだけでなく、チームが信頼性についてどのように考えるかを形作ります。エコシステムの広さを選ぶか、フォーカスされた明確さを選ぶかは、どのプラットフォームがより多くの機能を持っているかではなく、生のテレメトリーと運用上の意思決定の間にどれだけの抽象化を置きたいかに大きく依存します。どちらのアプローチも非常に有効に機能し得ますが、重要なのは本番環境でのモニタリングに対するチームの考え方に合った思想を選ぶことです。
