DEVOPS

Splunkを活用し、オブザーバビリティでのメトリクス、トレースなどの分析を実現

皆様の中ではSplunkはログを分析するためのソリューションというイメージをお持ちの方も多いかと思います。確かにSplunkはログの分析では非常に多くの認知を得ていましたが、今のSplunkはそれだけにとどまらず、統合的なオブザーバビリティプラットフォームを提供しています。オブザーバビリティプラットフォームであるSplunk Observability Cloudでは「ログ」に加えて「メトリクス」「トレース」「イベント」を活用し、例えばシステム内の処理の流れを可視化し問題発生箇所をグラフィカルに表現したり、RUMSyntheticsのデータから俯瞰的にユーザーエクスペリエンスの状況を分析することも可能です。またSplunkではすべてのトレースを取得できるため、あるタイミングでのひとつのセッションだけにフォーカスした分析ができます。

このような統合されたパワフルなオブザーバビリティプラットフォームですが、業界標準のオープンフレームワークであるOpenTelemetryをベースにすべて実現されています。そのためSplunk Observability Cloudを選ぶことは、お客様の長期的な投資保護の観点でも非常に有益な選択肢であると言えます。

以下「Splunk Beyond Logs: Getting to Observability」の抄訳になりますが、今後さらにCX向上を見据えてクラウド環境を活用するためには、高いオブザーバビリティは必須です。それを実現するための第一歩がSplunk Observability Cloudであることがご理解いただけると思います。


私を含め、ある程度の年齢の方は、かつて「IBMを買ってクビになった者はいない」と言われていたことをご存知でしょう。Splunkは幸運なことに、ログ分析とセキュリティの世界で「Splunkを買ってクビになる者はいない」と言ってもらえるまでの地位を確立しました。その成功のおかげで、Splunkがどのような製品を提供し、何ができるのか、よく知られるようになりました。しかし残念ながら、その認識が十分でない場合がほとんどです。コーディングやシステム運用を仕事にしている人に「Splunkとは何か」を尋ねると、おそらく「ログ分析プラットフォーム」という答えが返ってくるでしょう。それは間違いではありませんが、実はSplunkが持つ能力のほんの一部にすぎません。Splunk製品でできることはほかにもたくさんあります。このブログでは、ログ分析以外にもメトリクス、トレース、イベント分析におけるSplunkの活用についてご紹介します。

ログ分析後のSplunkの活用

ご存知のとおり、Splunkでは大量のログを分析してインサイトを導出できます。ただし、ログは最新のアプリケーションが生成するデータのごく一部にすぎません。複数のクラウド環境に分散して展開されるマイクロサービスベースの最新アプリケーションでは、ログ以外にメトリクス、トレース、エンドユーザーイベントも生成されます。これらのデータは、アプリケーション自体はもちろん、ビジネスの健全性とパフォーマンスを把握するためにも重要な役割を果たします。そして、ビジネスの状態を理解することは、オブザーバビリティを実現するための組織レベルの取り組みにおいて経営幹部の関心とサポートを引き出すためにも役立ちます。Splunkのオブザーバビリティ製品では、メトリクス、トレース、イベントの3種類のデータを分析して、ログ分析以上のインサイトを導出できます。この3つのデータソースには以下の特徴があります。

  • メトリクス:アプリケーションが出力する数値データで、容量は小さく、分析と追跡を容易に実行できます。
  • トレース:最新アプリケーションを円滑に運用するための切り札と言えるデータで、各ユーザーのリクエストがどのような流れで処理され、下流の各依存サービスでどのように処理されているかを特定できます。
  • イベント:実際のユーザーのブラウザ(またはシミュレーションされたブラウザ)で何が起きているかを示すデータで、エンドユーザーエクスペリエンスを検証して改善に役立てることができます。
     

Splunk EnterpriseSplunk Cloud Platformを使用しているお客様の多くは、これらのデータソースをまだ活用していませんが、どちらのプラットフォームでもこれらのデータソースの分析が可能です。そこからオブザーバビリティを実現し、Splunk Application Performance Monitoringのような高度なツールを活用すれば、さらなる能力とインサイトを手に入れることができます。その具体的なメリットをご紹介しましょう。

オブザーバビリティがもたらす価値

メトリクス、トレース、イベントの3つのデータソースをSplunkのオブザーバビリティプラットフォームに取り込めば、ログ分析以上の価値をすばやく実現できます。たとえばトレースを取り込めば、リクエストの処理の流れと問題の発生箇所を示す動的なサービスマップを生成できます。ユーザーに最も近いサービスから500エラーが報告されるだけで、あとは手動でログを調べて問題のある下流サービスを探し出さなければならないといった状況を改善し、リクエストの流れとともに問題のあるサービスを一目で特定できます。下の図のサービスマップでは、赤い丸が緊急を要するエラー箇所を示しています。

エラーを示すサービスマップ

エラーを示すサービスマップのほかに、データにタグを付けるシステムによってトレースを詳しく分析し、問題の原因をすばやく究明することもできます。また、データをタグで分類することで、リクエストで問題が多く発生しているユーザータイプ、地域、アプリケーションバージョンなどを特定できます。これを可能にするのが次の図に示すTag Spotlightです。Tag Spotlightを使用すれば、環境やエラーコードなどによって問題を切り分けることができます(画像をクリックして拡大できます)。

Tag Spotlightのイメージ

イベント分析は、オブザーバビリティを実現するための最先端技術です。最新アプリケーションはサーバーと同じくらい(またはそれ以上に)ユーザーのブラウザ上で実行されることが多いため、ユーザーとアプリケーションのやり取りを可視化することがこれまで以上に重要になります。サードパーティのフレームワークやCDNなどを使用する機会も増えるため、アプリケーション全体の状況やユーザーエクスペリエンスを可視化するには、ユーザーのブラウザで何が起きているかを直接知る必要があります。RUM(リアルユーザーモニタリング)とSynthetics(外形監視)を導入すれば、ユーザーの視点で状況をリアルタイムで把握できるため、ユーザーが不満をツイートしたりビジネスに影響が及んだりする前に問題を解決できます。

RUMによるユーザー状況の把握

メトリクスやトレースなど、どの分析から着手するか?

上記の3つの要素は、オブザーバビリティがもたらす価値のほんの一部にすぎませんが、ROIを大幅に向上させ、問題のトラブルシューティング能力とユーザーエクスペリエンスを飛躍的に向上させます。ログ分析の先に進むか進まないかで、問題解決のスピードに大きな差が出ます。もちろん、ログもトラブルシューティングに欠かせない存在です。そのため、Splunk Enterpriseをすでに使用している場合は、Log Observer Connectを導入することでSplunkのオブザーバビリティプラットフォームにログを簡単に取り込むことができます。

Splunkのオブザーバビリティシステムの大きなメリットの1つは、すべてのオブザーバビリティソリューション(Application Performance MonitoringInfrastructure MonitoringReal-User MonitoringSynthetic MonitoringLog Observer)が、業界標準のオープンフレームワークであるOpenTelemetryをベースにしていることです。OpenTelemetryから始めることは、オブザーバビリティジャーニーで長期的な成功を収めるための第一歩です。アプリケーションのインストルメンテーションを一度行えば、あらゆる場所からデータを収集できるようになります。OpenTelemetryは、Splunkで使用していただくのが私たちの希望ですが、他の商用ベンダー、オープンソース、自社製のソリューションでも利用できます。お客様がデータを所有して活用できるようにすることはSplunkが掲げる基本原則の1つであり、OpenTelemetryの導入はその取り組みの一環です。

アプリケーションのインストルメンテーションが終われば、数分後にはSplunkのオブザーバビリティプラットフォームにデータがリアルタイムでストリーミングされます。ぜひ無料トライアルでSplunk Observability Cloudをお試しください。ログ分析を超えたオブザーバビリティの実現方法について詳しくは、Splunkの営業窓口までお問い合わせください。

関連記事:

CI/CDツールとDevOpsの関係とは?Jenkinsの導入まで解説します

SREとは:SREメトリクスと監視のゴールデンシグナル

----------------------------------------------------
Thanks!
加藤 教克

Splunk
Posted by

Splunk