Splunk Observabilityイベントを使って他のSplunk製品にコンテキストを渡す

IT運用やセキュリティの問題が内製のソフトウェアに影響を及ぼしているときに、それを開発チームにどのように伝えていますか？いまだに電子メールに頼って、十分なコンテキストを伝えられず、さらには大量のメールに埋もれてエンジニアに気づかれすらしないなんてことはないでしょうか？サイロ化したツールやチーム間で情報をやり取りするのは容易ではありません。IT運用、セキュリティ、レガシープロセス、ビジネスに関する通知を、開発チームがよく使うツールに直接送ることができれば手っ取り早いと思いませんか？それができるようになったのです！

以下のSplunk製品からSplunk Observabilityにイベントを送信できます。

• Splunk Cloud / Splunk Enterprise
• Splunk ITSI
• Splunk Enterprise Security
• Splunk SOAR

組織では、開発チーム、セキュリティチーム、IT運用チームがこれらのSplunkツールを監視やアラートの基盤として使用する一方で、各ツールへのアクセスはそれを使用するチームのみに制限されていることがよくあります。その場合に各ツールを連携する手段の1つとして、アラートを関連フィールドデータとともにイベントとしてSplunk Observabilityに送信するためのインテグレーションが登場しました！開発チームが問題のトラブルシューティング時に最初にチェックすることの多いSplunk Observabilityダッシュボードを使って、これらのイベントを簡単に確認できます。

開発チームの管理下にない外部要因によって問題やサービス障害が発生した場合、トラブルシューティングや修正に必要以上に時間がかかることがあります。DDoS攻撃、ネットワークの問題、またはデータセンター周辺に放たれた牛など既知の原因であっても、そこにたどり着くまでに時間を取られがちです。しかし、Splunk Observabilityイベントのコンテキストを補強できれば、時間の無駄を省くだけでなく、影響の開始時点と終息時点を明確にして履歴に基づく監査や事後レビューに役立てることができます。

だとしたら、Splunk Observabilityイベントを活用してチーム間でコンテキストをやり取りしない手はないでしょう！でも、その方法がわからない？ぜひ続きをお読みください。

^{図1：Google Cloudデータセンター周辺に牛が放牧されたことを開発者に知らせたり、牛が放たれてから収容されるまでの間にどのような影響があったかを突き止めたりする際にも活用できるイベントマーカーの例}

または、Splunk Cloudでログに記録されたデータの中からCI/CDに関するイベントやフィールドだけをSplunk Observabilityに送ることもできます。これにより、デプロイの開始時刻、終了時刻、結果、ビルド番号などのデータを簡単に可視化して、監視ダッシュボードで確認できます。SPLでサーチできる情報なら何でも、一致したデータのフィールドを含めてSplunk Observabilityに送信できます。

運用チームと開発チームにコンテキストを！

開発者の多くは好奇心旺盛です。自身が開発したソフトウェアに問題が見つかれば、調査せずにはいられません。しかし、問題の原因が、開発チームの管理下にない外部要因である場合もあります。

ごく一部ですが、その例をご紹介しましょう。

• 外部からの攻撃：Splunk Enterprise SecurityでDDoS攻撃が検出された場合、どうやって開発者にそれを知らせればよいでしょうか？電子メールでは見落とされてしまうかもしれません。
• ビジネスプロセス：Splunk ITSIで追跡している在庫管理で問題が発生した場合、開発者は気づくでしょうか？気づいたとして、在庫数を問い合わせるリクエストが失敗した理由を特定できるでしょうか？
• セキュリティスキャンと修復：マイクロサービスの設定に脆弱性が見つかり、Splunk SOARによって自動修復された場合、開発者はそれに気づくでしょうか？最新のデプロイが「消えた」原因を探し続けることにならないでしょうか？
• CI/CD：他のチームがデプロイしたコードに問題があり、ダウンストリームのすべてのサービスに影響が及んだとき、Splunkでログに記録されたこれらのデプロイイベントをダウンストリームの担当チームの監視ツールで簡単に特定できるでしょうか？

これらはいずれも、Splunk Enterprise Security、Splunk ITSI、Splunk SOAR、Splunk CloudからSplunk Observabilityイベントを送信して、開発チームや運用チームに重要なコンテキストデータを渡すことができれば解決する問題です。

多くのユースケースでは、影響の開始時点と終息時点を示すイベントマーカーが追加されるだけでも大きなメリットがあります。主要イベントの前後に何が起こっていたかをダッシュボードで簡単に可視化できれば、トラブルシューティングをすばやく行うだけでなく、サービスへの影響を突き止め、対応後またはインシデント後のレビューで関連する可能性のある問題を洗い出すことができます。

製品ごとの解決策をチェック！

Splunk製品では、大量のデータからコンテキストとインサイトが抽出されます。それらの情報は、運用やソフトウェア開発の健全性の維持に重要な役割を果たします。Splunk製品を使用するチーム間にあまり連携がなく、他のチームのツールにアクセスできないことはよくあります。しかし、以下の方法でSplunk Observability Cloudにコンテキストをすばやく取り込むことができます。方法の詳細については、それぞれのリンク先を参照してください。

Splunk Cloud / Splunk Enterprise：これらのSplunkプラットフォームで記録される組織全体に関するログは情報の宝庫です！しかし、セキュリティ上の理由や業務上の理由から、すべての従業員がすべてのデータにアクセスできるとは限りません。

• Splunk Observabilityイベントのアラートアクションを使えば、重要なアラートと関連フィールドをSplunk Observability Cloudに送信できます。

Splunk IT Service Intelligence (ITSI)：Splunk ITSIには、ビジネスサービスに関するインサイトやKPIに加えて、Splunk Observability Cloudを通じて開発者に伝えるべきインシデントデータが保存されています。

• アラートアクションを活用すると、ITSIのKPIアラートやITSIで管理しているサービスに関する情報をSplunk Observability Cloudに簡単に送信できます。

Splunk Enterprise Security (ES)：Splunk Enterprise Securityはソフトウェア開発者にとって最も馴染みのないSplunk製品かもしれませんが、ソフトウェア開発やソフトウェアインフラに関係する重要なセキュリティコンテキストが保存されています。

• Enterprise Securityのアダプティブレスポンスアクションを使えば、重要なイベントとフィールドをSplunk Observabilityに送信できます。

Splunk SOAR：Splunk SOARで実行している自動化が開発チームに関係する場合があります。修復、ビルドの失敗、その他の自動化アクティビティはすべてソフトウェアインフラに影響する可能性があります。それならば、Splunk Observability Cloudを通じて開発チームや運用チームにこれらのイベントを通知する作業も自動化してしまいましょう！

• Splunk Observability用SOAR App (SignalFx)を使えば、この通知を簡単に自動化できます。

いずれか1つの製品でもSplunk Observabilityにデータを送信できるようにすることで、運用、CI/CD、インフラ、ビジネスに関する大量のデータを活用できます。さらに、すべての製品のコンテキストを組み合わせれば、開発者やエンジニアがこれまで知りえなかった重要な詳細や履歴分析から状況を明確に把握することができます。

すべての情報を集約！

すべてのツールのコンテキストをSplunk Observability Cloudのような開発者に馴染みのあるインターフェイスに集約したら、どれだけのメリットがあるでしょうか？下の図に、前述の各SplunkツールからDDoSインシデントに関するコンテキストを送信する例を示します。


^{図2-1：Splunk ITSI、Enterprise Security、Splunk SOARからDDoS攻撃とその修復作業に関するコンテキストをSplunk Observabilityに送信する例}

• ITSIで、ビジネスサービスへの影響や異常な動作が検出され、イベントがSplunk Observabilityに送信されます。これが影響の開始時点を示します。

• Enterprise Security (ES)で、Splunk内のデータが相関付けられ、DDoS攻撃による影響であることが判明します。

              ○  DDoS発生を知らせるイベントが開発者に送られ、その影響でサービスに問題が発生していることが通知されます。 

              ○  Splunk SOARのランブックが実行され、ネットワークエンジニアに通知が送られて、DDoSの影響を修復するためのSOARプレイブックが実行されます。 

• SOARで修復ランブックが完了すると、修復の実行を知らせるイベントが送信されます。修復で問題が収まれば、このイベントが影響の終息を示します。

• 開発者は、これらのイベントを通じて、インシデント全体の状況とその影響範囲を、影響の開始時点、実行された修復内容、影響の終息時点とともに1つの画面で確認できます。

開発者は、各製品からSplunk Observability Cloudに送られたイベントに基づいて、自身が管理するインフラやソフトウェアの外部で起きた問題の状況をただちに把握できます。どのような問題が起きているかの調査に時間をかける必要はありません。また、これらのイベントを取り込めば、履歴に基づく監査やインシデント後のレビューと根本原因分析を効率的に行うこともできます。イベントから、インシデントの開始と終息時点などの重要な詳細だけでなく、実行された対応の詳細もわかります。特にインシデント管理を担当するチームにとっては、情報源やインシデントの流れを示すデータとしてこれらのイベントが重宝するでしょう。

Splunk Observabilityでのイベント集約例：
^{図2-2：Splunk ITSI、Enterprise Security、Splunk SOARからDDoS攻撃とその修復作業に関するコンテキストをSplunk Observabilityに送信する例}

1.  9:37頃からリクエスト数が増加し、遅延のスパイクが発生し始めています。ここが開始時点と考えられます。
2.  リクエスト数が急増し、遅延が大きくなってサービスに影響し始めます。ITSIから、決済プロセスでのビジネスへの影響が検出され、アラートがSplunk Observabilityにイベントとして送信されます。
   • MTTD：上記のデータからMTTD (平均検出時間)を計算できます：約9:50 - 約9:37 = 約13分
3.  Enterprise Securityで、外部のエンドポイントでDDoSが発生していることが検知され、Splunk Observabilityにイベントが送信されるとともに、修復のためのSOARランブックが実行されます。
   • この時点で開発者はこれ以上調査を続ける必要がなくなります。
4.  9:59頃にSOARランブックの実行が完了し、それを知らせるイベントがSplunk Observabilityに送信されます。DDoSトラフィックが減少し始め、問題が終息に向かいます。
   • MTTR：上記のデータからMTTR (平均修復時間)を計算できます：約9:59 - 約9:37 = 約22分

イベントは、あらゆるオブザーバビリティ戦略に重要な要素であり、インシデント全体の流れとビジネスへの影響を理解するのに役立ちます。どのような問題がいつどこで生じたかを知らせるイベントがなければ、ソフトウェア環境のどこが正常でどこで異常が発生しており、外部からどのような影響を受け、ビジネスプロセスにどのような影響を与えているかといった基本的な状況把握すら難しくなるでしょう。また、イベントを通じて、チームが問題にどのように対応したかを測定し、MTTDやMTTRなど、改善の指標となるメトリクスを収集することもできます。

次のステップ

すべてのツールのコンテキストを集約しましょう。Splunk Observabilityイベントを活用すれば、ダッシュボードやインシデント対応に重要な情報を簡単に追加できます。しかも無料です！これまで以上に監視データが充実します！

ぜひSplunkBaseからSplunk Observability Events Appをダウンロードしてインストールし、Splunk SOARにプリインストールされているSignalFX SOAR Connector AppでSplunk Observabilityイベントアクションを試してみてください。

SplunkユーザーでSplunk Observabilityをまだお使いでない場合は、Splunk Observability Cloud製品スイートの無料トライアルをぜひお試しください。

このブログ記事はSplunkのスタッフオブザーバビリティフィールドソリューションエンジニアであるJeremy Hicksが執筆しました。

このブログはこちらの英語ブログの翻訳、山村 悟史によるレビューです。