大規模環境で優れたオブザーバビリティを提供するのはSplunkだけ

ログ分析

メトリクスと完全忠実なトレースをログと適切に相関付けることで、問題のすばやい特定と解決を実現します。企業のデータセットに幅広く対応する実績のあるインデックス化およびサーチ機能により、必要な情報を必要なタイミングで迅速に入手できます。

ログファイルの相関付けが最小限であり、レポート用のサーチも低速で非効率であるため、ログデータに対するクエリーやトラブルシューティングが困難です。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に関しては、製品間の切り替え時の操作が手間で連携もしていません。

Splunkは、ネイティブのテレメトリ収集メカニズムとしてOpenTelemetry Collectorを採用しており、このプロジェクトに大きく貢献しています。ユーザーは、例外やOpenTelemetry固有の制約を気にすることなく、OpenTelemetryデータの収集、処理、変換、可視化、アラート生成を確実に行えます。コミュニティに直接寄与するとともに、自社にとってのOpenTelemetryのビジネス価値を最大限に高めることができます。

New Relicは、Cloud Native Computing Foundation (CNCF)の加盟企業であり、OpenTelemetryエージェントを提供しています。しかし、このエージェントではデータの可視化やエクスポートに手間がかかり、OpenTelemetryがもたらすビジネス上のメリットを最大限に活用する機会を十分に生かせません。