統合型のオブザーバビリティおよびログ管理をお求めですか？Splunkは、New Relicよりも迅速な対応を可能にし、柔軟性が高く将来を見据えた、コンテナ対応の最新ソリューションの比較が検討できます。
Splunkを使い始める前は、本番環境のシステムにログインしてログを分析し、スクリプトを実行するなど、個別の状況に合わせてさまざまな対応が必要でした。Splunkを導入してからは、簡単なクエリーでアプリケーションの実行履歴を確認できます
SplunkとDynatraceの比較
相互につながる何百ものサービスの中から根本原因を迅速に特定するには、柔軟なワークフローと、盲点のない包括的なデータが必要です。Dynatraceでは、インストルメンテーション(計装)時のリソースの負荷が高く、ソリューションが高額で、デバッグワークフローの柔軟性が低いため、クラウドネイティブのワークロードにおいて盲点が生じます。
Dynatrace
エフェメラル(一時的)なインフラに対する処理スピードの欠如
Kubernetesのマイクロサービスでは、水平方向への拡張や縮小が数秒で実行されます。一方で、Dynatraceのバッチ処理ではテレメトリの収集と可視化に時間がかかるため、重要な問題を特定して迅速に対応することができません。
Splunkの強み
Splunk Observability Cloudは、クラウドネイティブアプリケーション向けに構築されています。10秒もあればデータを収集して可視化できるので、コンテナ化されたアプリケーションでのイベントの発生と同時にインサイトを得られます。そのため、デジタル環境を基盤とする企業はMTTRを短縮してユーザーの不満を低減するとともに、会社の評判を守り、損失を抑えることが可能です。
Dynatrace
性能不足のロギングソリューション
Dynatrace Grailは、大企業に必要なレベルのトランザクションとサーチをサポートしていません。クエリー実行時にインデックスが作成されるため、特に複数の処理が同時に実行されるときは、クエリーのパフォーマンスが著しく低下します。Grailは製品として未成熟であり、サポートコミュニティの規模が小さく、クエリーへのアプローチも3種類のクエリー言語に基づく複雑なものであるなど、欠点がいくつかあります。そのため、Grailは使いやすいツールとはいえません。メトリクスやトレースでコンテキストを補強したログを使用できる堅牢なロギングソリューションではないため、トラブルシューティングに時間と手間がかかります。
Splunkの強み
2003年以来、Splunkはエンタープライズ向けデータアーキテクチャの最前線を走り続けてきました。Splunkでは、きわめて大規模なデータセットの取り込み、インデックス化、保存、サーチを比較的簡単に行えます。テレメトリデータは取り込み時にすべてインデックス化されるため、根本原因の調査が容易です。また、統合型のデータ分析で、ログ、メトリクス、トレースを相関付けできます。世界トップレベルの統合型のサーチ機能も相まって、Splunkは並列処理でも優れたパフォーマンスを実現し、MTTRを短縮します。
さらに、Splunkには大規模かつ精力的なサポートコミュニティと認定制度があり、有能な技術担当者がお客様をサポートする仕組みが整っています。
Dynatrace
わかりづらく高額な価格設定
ホストのメモリー容量に基づいて決まるライセンスなど、一目で理解できない複数の基準が使われる価格設定は高額なだけでなく複雑で、見積もりに多大な時間と労力がかかるため、Dynatraceのコストにユーザーは不満を抱えています。
Splunkの強み
Splunkでは、監視対象のホスト数だけを基準とする、シンプルでとてもわかりやすい価格設定で、オブザーバビリティソリューションをすべて活用できます。ソリューションには、インフラ監視、アプリケーションパフォーマンス監視、AlwaysOn Profiling、ログ調査、リアルユーザー監視、セッションリプレイ、外形監視が含まれます。ホストの数はメモリー容量の影響を受けず、月々の平均使用数に基づいて計算されるため、トラフィックの急増について心配せずに済みます。しかも、セッションリプレイの追加料金は発生しません。Splunkなら、投資からビジネス価値を容易に引き出すことが可能です。
| Splunk | Dynatrace | |
|---|---|---|
ビジネスアナリティクス | Splunk ITSIでは、内製アプリケーションでもサードパーティ製アプリケーションでも、ソースを問わず、人間が読める形式のあらゆるファイルを取り込み、インデックス化し、保存できます。取り込んだデータをメトリクスおよびトレースと組み合わせて、非常に柔軟にカスタマイズできるグラステーブルに表示できるため、いかなるビジネスプロセスも追跡してトラブルシューティングできます。 | Dynatraceでは可視性のギャップにより、ビジネスプロセスを包括的に把握することが困難です。また、ホストベースの高額なライセンスが原因で、テレメトリデータを捉えきれないケースが多々あります。独自のエージェントはリソースへの負荷が高く、特にクラウドネイティブの環境において、広範なデプロイの妨げになっています。 Dynatraceではビジネスを可視化するのに使えるデータが限られており、柔軟性にも欠けるため、エンジニアリングおよびIT運用チームによる問題の特定と解決に支障をきたします。 |
検出とアラート生成 | Splunkは、1秒単位の詳細なメトリクスをほぼリアルタイムでストリーミングし、数秒で可視化します。すべてのトレースを収集することで、いかなる問題も見逃さず、トラブルシューティングに必要な情報を問題の発生と同時に取得することが可能です。Splunkのアーキテクチャでは、MTTDとMTTRが短縮されるため、カスタマーエクスペリエンスが向上し、エンジニアとIT運用チームの負担が軽減します。 | Dynatraceのメトリクス収集アーキテクチャはパフォーマンスが低く、MTTDが長くなりユーザーエクスペリエンスが低下します。また、サンプリングアルゴリズムの実行に時間がかかり、なかなか問題を把握できず、エンジニアが満足に業務をこなせません。 |
データ保持とデータパイプライン管理 | Splunkはデフォルトで、ほとんどのデータをDynatraceよりも長期にわたり高精度で保持します1。そのため、より多くの情報と過去のコンテキストに基づいて複雑な問題の解決に臨めます。 Splunkのログとメトリクスのパイプラインにはエッジ処理およびデータエクスポート機能が備わっており、データの転送、変換、難読化、除外が可能なため、テレメトリを必要に応じて保持または破棄できます。 | Dynatraceが詳細なメトリクスを保存するのは短時間であり2、その後は精度が低下するため、問題の発生から時間が経つにつれて、エンジニアが利用できる情報は減少します。 現在、DynatraceはSplunkに匹敵する機能を備えた製品を提供していませんが、2024年5月までにパイプラインツールをリリースする意向を示しています3。 |
トラブルシューティング環境 | Splunk Observability Cloudのトラブルシューティングワークフローではビジネスコンテキストに基づいて、調査すべき場所、問題の発生原因、ビジネスへの影響を把握するとともに、提案された修正方法を確認できます。ログはすべてインデックス化されており、これを基に豊富なコンテキストが示されるため、ユーザーは必要な情報を迅速に得られます。エンジニアはユーザー、サービス、アプリケーション、インフラの任意のレベルから調査を始めて、何が影響を受けたかを判断し、問題の発生箇所をすばやく簡単に特定できます。 | 予期せぬ問題やDavisでは特定不可能な問題の根本原因を突き止めることは難しく、時間を要します。Dynatraceでは、タグ付け、ビジネスワークフロー、調査用の関連コンテンツなどの操作をスムーズに行えません。Dynatrace Grailのロギングプラットフォームではインデックスがクエリー実行時に作成されるため、サーチが低速で体系的に実行できず、十分なコンテキストが得られません。ユーザーは最終的には答えにたどり着けるかもしれませんが、時間がかかります。その結果、DynatraceではDavisの支援の下でも、MTTRが長くなる可能性があります。 |
OpenTelemetryのサポート | あらゆるフォーマットのデータを収集することができ、OpenTelemetryを標準の収集アプローチとして採用しているのはSplunkだけです。制約を受けることも独自のエージェントをデプロイすることもなく、OpenTelemetryデータを収集、処理、変換、可視化してアラートを生成できます。OpenTelemetryの実装に関して継続的なプロファイリングと商用サポート4を提供しているベンダーは、Splunk以外にありません。Splunkのお客様は、コミュニティに直接寄与するとともに、自社にとってのOpenTelemetryのビジネス価値を最大限に高めることができます。 | DynatraceのOpenTelemetryに対するサポートは手薄で、企業にとって十分ではありません。同社はコミュニティに大きく貢献していますが、OpenTelemetryデータに基づく分析とインサイトを明らかにする力は限定的です。また、Dynatrace独自のエージェントとOpenTelemetry Collectorを同時に実行しなければなりません。両方のコレクターからバックエンドへテレメトリが送信され、別々に保存されるため、クエリーを実行してインサイトを取得するうえでの障壁となっています。同社が推奨するディストリビューションにおいて、継続的なプロファイリングはサポートされていません。 |
1エンタープライズ監視のMetricSetsおよびリアルユーザー監視のデータは、1秒の取得間隔で3カ月間、1分の取得間隔で13カ月間デフォルトで保管されます。Splunkはトレーシングでサンプリングせず、トレースデータをすべてデフォルトで保管します。インデックス化されたログ、トレース、外形監視のデータは30日間保管され、S3との連携を通じてこの期間を延長することが可能です。
2Dynatraceのサービスメトリクスは、30秒間隔で1時間、1分間隔で35日間デフォルトで保管されます。分散トレーシング(メトリクスの時系列を1分間に1000回超サンプリング)およびRUMのアクションデータは、10日間保管され、35日間は集約されたデータを利用可能です。また、ログを保持するためのバケットを宣言しなければなりません。
3https://www.dynatrace.com/news/blog/dynatrace-openpipeline-converging-observability-security-and-business-data-at-massive-scale-for-unmatched-analytics-in-context/
4商用サポートでは、Splunkが推奨するOpenTelemetry Receiver/Collectorを使用、拡張、修正するためのサポートを電話やオンラインで提供します。
Splunkを導入している世界中の主要な企業
