Splunkは、ハイブリッドクラウドの複雑さに対応しながら変化するビジネスニーズに適応するうえで、Datadogよりも優れたスピード、拡張性、柔軟性の比較ができます。想定外のコストも発生しません。
Splunkがあるからこそ状況がすぐに把握でき、迅速な改善活動につながりました。メンバーにもこの危機感が素早く共有できるようになったことも大きなメリット
New Relic
検出に時間がかかる
Kubernetesのコンテナでは数秒の内にスケールアップやスケールダウンが行われるため、New Relicのバッチ処理によるテレメトリ収集では、断続的に発生する問題を把握して迅速に対応することが困難です。
Splunkの強み
Splunk Observability Cloudは、エフェメラル(一時的)なアプリケーションに適した設計であり、10秒未満でのデータの収集と可視化が可能です。コンテナ化されたアプリケーションにおけるイベントの発生と同時にインサイトを取得することで、MTTRを短縮し、会社の評判を守るとともにユーザーの満足度を維持することができます。
New Relic
柔軟性に欠けるデータストレージ
SaaSとオンプレミスにデプロイされた、地理的に離れた場所で運用される複雑なアプリケーションをトラブルシューティングするには、環境全体の可視化が鍵となります。New Relicのデータベースは時系列データ向けに設計され、ログ機能がアップデートされましたが、データソースの幅広さとカーディナリティへの対応は、企業の複雑な課題を解決するうえで十分ではありません。
Splunkの強み
Splunkでは、人間が読める形式のあらゆるファイルを取り込み、保存し、サーチできます。データセットをビジネスコンテキストで補強することにより、問題の可視化と相関付けを行い、解決につなげられるようになります。データ量やソースに制約を受けることなく、テレメトリを可視化して実際のイベントに相関付けるため、あらゆる場所で生じる問題を予測して防ぐことが可能です。
New Relic
OpenTelemetryソリューションとして不完全
New Relicでは、独自のエージェントとOpenTelemetry Collectorから取得したデータを同一のグラフで表示することができません。その結果、ユーザーはNew Relic独自のエージェントを使用せざるを得ず、ベンダーロックインに悩み続けることになります。
Splunkの強み
Splunkは、OpenTelemetryをネイティブで全面的に実装しています。他のエージェントを同時に実行したり、人が操作したりすることなく、OpenTelemetryデータを収集、処理、変換、可視化、エクスポートできます。あらゆるフォーマットのデータの収集をサポートし、データポータビリティの向上、切り替えに伴うコストの低減、テレメトリに対するユニバーサルアクセスの確保を実現しながら、業界でのOpenTelemetryの普及を牽引しています。
Splunk | New Relic | |
---|---|---|
ログ分析 | メトリクスと完全忠実なトレースをログと適切に相関付けることで、問題のすばやい特定と解決を実現します。企業のデータセットに幅広く対応する実績のあるインデックス化およびサーチ機能により、必要な情報を必要なタイミングで迅速に入手できます。 | ログファイルの相関付けが最小限であり、レポート用のサーチも低速で非効率であるため、ログデータに対するクエリーやトラブルシューティングが困難です。New Relicでは、ログファイルの種類によっては取り込みが行われず、ログファイルの分析に関連コンテンツが使用されないこともあります。非構造化データについてはフィールドのタグ付けが自動で行われないため、手動で指定しない限りログの活用が制限されます。 |
検出とアラート生成 | Splunkでは、リアルタイムのストリーミングアーキテクチャを通じて、データを1秒間隔で収集して10秒未満でレポートが作成されます。そのため、状況の変化に対する可視化、分析、アラート生成を数秒以内に行って、クラウドネイティブのアプリケーションとインフラの問題をすばやく特定して修正することができます。 | New Relicのエージェントは、詳細なデータを収集することができます。しかし、バッチ処理を使用してテレメトリデータをポーリングし、レポート作成は通常1分間隔で行われるため、あらゆる問題で検出やアラート生成の遅れにつながります。 |
データの保持と統合 | Splunkでは、すべての時系列メトリクス、トレース、ログ、イベントがコードの行単位まで収集、可視化、分析されるため、重要な兆候を決して見逃しません。さらに、Metrics Pipeline Managementを使用して取り込み時にメトリクスの量を調整できるため、オブザーバビリティに伴うコストを最適化できます。 | New Relicのトレーシングでは、Webブラウザおよびモバイルアプリからすべてのトレースデータを収集できますが、バックエンドのトレースに関してはサンプリングされます。そのため、スパンを全体的に把握することができず、重複して収集することになり、トラブルシューティングの遅れやコストの拡大を招き、問題の特定に支障をきたします。 |
トラブルシューティング環境 | Splunk Observability Cloudでは、全体的に連携されたトラブルシューティングワークフローにより、エンジニアはユーザー、サービス、アプリケーション、インフラの任意のレベルから調査を始めて、何が影響を受けたかを判断し、問題の発生箇所をすばやく簡単に特定することが可能です。IT運用チームはSplunk IT Service Intelligenceを活用することで、ITサービスの健全性とビジネスへの影響を迅速に関連付け、収益の損失を追跡し、ユーザー対応の優先順位を判断するとともに、全社規模でのコミュニケーションを促進することができます。 | 製品および機能が孤立し、連携されておらず、ユーザーはどこから着手してよいかわかりません。機能やビルトインのAPMおよびインフラ監視ダッシュボードが重複しており、特にNew Relic Explorer、Lookout、Navigator、Timewarp、Workloadsに関しては、製品間の切り替え時の操作が手間で連携もしていません。 |
OpenTelemetryのサポート | Splunkは、ネイティブのテレメトリ収集メカニズムとしてOpenTelemetry Collectorを採用しており、このプロジェクトに大きく貢献しています。ユーザーは、例外やOpenTelemetry固有の制約を気にすることなく、OpenTelemetryデータの収集、処理、変換、可視化、アラート生成を確実に行えます。コミュニティに直接寄与するとともに、自社にとってのOpenTelemetryのビジネス価値を最大限に高めることができます。 | New Relicは、Cloud Native Computing Foundation (CNCF)の加盟企業であり、OpenTelemetryエージェントを提供しています。しかし、このエージェントではデータの可視化やエクスポートに手間がかかり、OpenTelemetryがもたらすビジネス上のメリットを最大限に活用する機会を十分に生かせません。 |