はじめに

Splunk、AppDynamics、および Splunk Observability Cloud による監視とアラート

イントロダクションと概要

今日の複雑なIT環境において、アプリケーションとサービスのパフォーマンスと可用性を確保することは最も重要です。このワークショップでは、包括的な監視とアラート機能を提供するために連携する強力なツールの組み合わせ、すなわちSplunk、AppDynamics、Splunk Observability Cloud、およびSplunk IT Service Intelligence (ITSI) をご紹介します。

現代の監視における課題

現代のアプリケーションは、分散アーキテクチャ、マイクロサービス、クラウドインフラストラクチャに依存していることが多いです。この複雑さにより、パフォーマンス問題や障害の根本原因を特定することが困難になっています。従来の監視ツールは個々のコンポーネントに焦点を当てることが多く、サービス全体の健全性とパフォーマンスを理解する上でギャップが生じます。

ソリューション: 統合されたオブザーバビリティ

包括的なオブザーバビリティ戦略には、さまざまなソースからのデータを統合し、実用的なインサイトを得るために相関させることが必要です。このワークショップでは、Splunk、AppDynamics、Splunk Observability Cloud、およびITSIがどのように連携してこれを実現するかをデモンストレーションします:

• Splunk: ログ分析、セキュリティ情報およびイベント管理 (SIEM)、広範なデータ分析のための中央プラットフォームとして機能します。AppDynamics、Splunk Observability Cloud、およびその他のソースからデータを取り込み、強力な検索、可視化、相関機能を実現します。SplunkはIT環境の包括的なビューを提供します。

• Splunk Observability Cloud: インフラストラクチャメトリクス、分散トレース、ログを含むフルスタックオブザーバビリティを提供します。サーバーやコンテナからクラウドサービス、カスタムアプリケーションまで、インフラストラクチャ全体の健全性とパフォーマンスの統一ビューを提供します。Splunk Observability Cloudは、スタック全体にわたるパフォーマンス問題の相関に役立ちます。

• AppDynamics: 詳細なApplication Performance Monitoring (APM) を提供します。アプリケーションを計装して、トランザクショントレース、コードレベルの診断、ユーザーエクスペリエンスデータを含む詳細なパフォーマンスメトリクスをキャプチャします。AppDynamicsは、アプリケーション内部のパフォーマンスボトルネックの特定に優れています。

• Splunk IT Service Intelligence (ITSI): 他のすべてのプラットフォームからのデータを相関させることで、サービスインテリジェンスを提供します。ITSIを使用すると、サービスを定義し、依存関係をマッピングし、サービス全体の健全性とパフォーマンスを反映するKey Performance Indicators (KPIs) を監視できます。ITSIは、IT問題のビジネスへの影響を理解するために不可欠です。

データフローと統合

これらのプラットフォーム間でデータがどのように流れるかを理解することが重要な概念です:

1. Splunk Observability Cloud と AppDynamics がデータを収集: アプリケーションとインフラストラクチャを監視し、パフォーマンスメトリクスとトレースを収集します。

2. データが Splunk に送信される: AppDynamicsとSplunk Observability CloudはSplunkと統合され、Splunkに直接送信されるログとともに収集したデータを転送します。

3. Splunk がデータを分析およびインデックス化: Splunkはデータを処理して保存し、検索および分析可能にします。

4. ITSI が Splunk データを活用: ITSIはSplunk内のデータを使用してサービスを作成し、KPIを定義し、IT運用全体の健全性を監視します。

ワークショップの目標

このワークショップの終了時には、以下のことができるようになります:

• Splunk、AppDynamics、Splunk Observability Cloud、およびITSIの相互補完的な役割を理解する。
• Splunk、Observability Cloud、およびAppDynamicsで基本的なアラートを作成する。
• ITSIで新しいサービスとシンプルなKPIおよびアラートを設定する。
• ITSIにおけるエピソードの概念を理解する。

このワークショップは、堅牢なオブザーバビリティプラクティスを構築するための基盤を提供します。アラート設定のワークフローに焦点を当て、独自の環境でより高度な機能と設定を探索する準備を整えます。ITSIまたはアドオンのインストールと設定については扱いません。

事前設定された Splunk Enterprise Cloud インスタンスへのアクセス方法についてはこちらをご覧ください。

基本的なアラートの作成

Splunk Enterprise、AppDynamics、および Splunk Observability Cloud での基本的なアラートの設定

このセクションでは、Splunk Enterprise、AppDynamics、およびSplunk Observability Cloudでの基本的なアラートの作成について説明します。これらの例は、シンプルさと核となる概念のデモンストレーションに焦点を当てています。実際のアラートシナリオでは、より複雑な設定としきい値が必要になることが多いことを覚えておいてください。

1. Splunk Enterprise アラート

Splunkアラートは、特定の条件に一致する検索結果によってトリガーされます。特定の条件が満たされたときに通知するリアルタイムアラートを作成します。

シナリオ: 過去5分間に “main” インデックス内の “Invalid user” イベントの数が100を超えた場合にアラートを発生させます。

手順:

1. 検索を作成: アラートを発生させたいイベントを特定するSplunk検索を作成することから始めます。例えば:

   index=main "Invalid user"

   タイムピッカーを使用して “Last 15 minutes” を選択します。

2. アラートを設定:

   • Save As をクリックし、Alert を選択します。
   • アラートにわかりやすい名前を付けます（例: “Numerous Invalid User Logins Attempted”）。
   • Alert type:
     • Scheduled: 設定されたスケジュールで検索を評価するには Scheduled を選択します。Scheduledの下に頻度を選択するボタンがあるので、Run on Cron Schedule を選択します。
     • Cron Expression: /15 ** *
     • Triggered when: Number of results is greater than 100 を選択します。
     • Time Range: “15 minutes” に設定します。
   • Trigger Actions:
     • この基本的な例では、Add to Triggered Alerts を選択します。実際のシナリオでは、メール通知、Slack統合、またはその他のアクションを設定することになります。
   • Save: アラートを保存します。

説明: このアラートは15分ごとに検索を実行し、検索結果が100件を超えるとトリガーされます。Add to Triggered Alerts アクションは、単にSplunkのTriggered Alertsリストにアラートを追加します。

時間範囲と頻度: Splunkコアのすべては検索であるため、検索の期間と頻度を考慮する必要があります。これにより、a) 期間の重複により同じデータを複数回検索すること、b) 期間と頻度のギャップによりイベントを見逃すこと、c) 頻繁に実行しすぎてオーバーヘッドが増加すること、d) 実行頻度が低すぎてアラートに遅延が発生すること、を防ぐことができます。

2. Splunk Observability Cloud アラート (Detectors)

Detector を作成:

• 左側のメニューで Detectors & SLOs をクリックします
• Create Detector -> Custom Detector をクリックします
• Detectorにわかりやすい名前を付けます（例: “High CPU Utilization Alert - INITIALS”）。
• Signal:
  • 監視したいメトリクスを選択します (“cpu.utilization”)。
  • ホストを指定するために必要なフィルターを追加します (service.name:otelshop-loadgenerator)。
  • Proceed to Alert Condition をクリックします
• Condition:
  • Static Thresholdを選択します
  • しきい値を設定します: is above 90
• Notifications:
  • この例では、シンプルな通知方法を選択します（例: テスト用のWebhook）。実際のシナリオでは、PagerDuty、Slack、またはその他の通知システムとの統合を設定することになります。
• Save: Detectorを保存します。

説明: このDetectorは、指定されたサービスのCPU使用率メトリクスを監視します。CPU使用率が設定された “for” 期間にわたって90% を超えると、Detectorがアラートをトリガーして通知を送信します。

すべてのプラットフォームに関する重要な考慮事項:

• しきい値: アラートに設定するしきい値を慎重に検討してください。しきい値が敏感すぎるとアラート疲れにつながる可能性があり、しきい値が高すぎると重大な問題を見逃す可能性があります。
• 通知チャネル: アラートシステムを適切な通知チャネル（メール、SMS、Slack、PagerDuty）と統合して、アラートが適切な人に適切なタイミングで配信されるようにしてください。
• アラートのグループ化と相関: 複雑なシステムでは、ノイズを減らし、実用的なインサイトに焦点を当てるために、アラートのグループ化と相関を実装してください。ITSIはこれにおいて重要な役割を果たします。
• ドキュメント: アラートをトリガーする条件と適切な対応手順を含め、アラートを明確に文書化してください。

これらの例は、基本的なアラートを作成するための出発点を提供します。これらのプラットフォームに慣れてきたら、特定の監視ニーズに合わせて、より高度なアラート機能と設定を探索することができます。

ITSI でのサービスの作成

エンティティタイプに基づく依存関係を持つ ITSI でのサービスの作成

このワークショップでは、既存のエンティティを使用してSplunk IT Service Intelligence (ITSI) でサービスを作成し、エンティティのタイプに基づいて依存関係を確立する方法について説明します。Splunk Observability Cloudからのビジネスワークフローを表すエンティティと、AppDynamics Business Transactionsを表すエンティティを区別します。

シナリオ:

2つの既存サービスがあります: “Online-Boutique-US”（Kubernetesで実行され、Splunk Observability Cloudによって監視されているアプリケーションを表す）と “AD.ECommerce”（AppDynamicsによって監視されているアプリケーションを表す）。新しいサービスを作成し、これらのサービスの1つの依存関係として追加したいと思います。このワークショップの最初の実行時に両方のサービスを作成する必要はないので、まずは興味のある方を選択してください。

Splunk 環境に戻り、Apps から IT Service Intelligence を選択してください

Default Analyzerでフィルターを “Buttercup Business Health” に更新してください

ITSI でのアラートの作成

Splunk ITSI での基本的なアラートの設定

このセクションでは、Splunk IT Service Intelligence (ITSI) で基本的なアラートを設定する方法を説明します。以前作成したサービスがKPIのしきい値を超えたときにトリガーされるアラートを設定します。

作成したサービスに応じて、このアラートに使用する KPI が変わります。以下の手順では、Service Name と KPI を適切に置き換えてください

• PaymentService2: Business Workflow Error Rate
• AD-Ecommerce2: Availability

手順:

1. KPI に移動:

   • ITSIで Configuration -> Correlation Searches に移動します
   • Create New Search をクリックします

2. 新しい検索を設定:

   • Search Title: Service Name KPI Critical
   • Description: Service Name KPI Critical
   • Search:

   index=itsi_summary kpi="*KPI*" alert_severity=critical

   • Time Range: Last 15 minutes
   • Service: Service Name
   • Entity Lookup Field: itsi_service_id
   • Run Every: minutes
   • Notable Event Title: Service Name KPI Critical
   • Severity: Critical
   • Notable Event Identified Fields: source

アラート作成後:

• アラートが実行されるまで5〜10分待つ必要があります
• アラートはITSIの Alerts and Episodes ペインにリストされます。

重要な考慮事項:

• アラート疲れ: アラートを多く設定しすぎたり、しきい値が敏感すぎるアラートを設定したりしないようにしてください。これはアラート疲れにつながり、人々がアラートに鈍感になって重大な問題を見逃す可能性があります。

ITSI でのエピソードの作成

Splunk ITSI での Aggregation Policy の作成

このセクションでは、先ほど設定したアラートに一致するSplunk ITSIでのAggregation Policyを作成する手順について説明します。このポリシーは関連するアラートをグループ化し、ノイズを減らしてインシデント管理を改善します。

作成したアラートに応じて、このアラートに使用するタイトルが変わります。以下の手順では、AlertName を使用した Service Name に置き換えてください

• PaymentService2 または
• AD-Ecommerce2

手順

1. Notable Event Aggregation Policies に移動: Splunkで Configuration -> Notable Event Aggregation Policies に移動します。

2. 新しいポリシーを作成: 右上隅にある緑色の Create Notable Event Aggregation Policy ボタンをクリックします。

3. フィルタリング条件: これが最も重要な部分です。このポリシーによってグループ化されるアラートの条件を定義します。Add Rule (OR) をクリックします

   • Field: ドロップダウンメニューから title を選択します。
   • Operator: matches を選択します。
   • Value: “Service Name*” という文字列を入力します（* を含めることを忘れないでください）。

4. イベントの分割: デフォルトで提供されている “hosts” フィールドを削除し、“service” フィールドを使用するように更新します。これにより、見つかった各サービスごとに新しいエピソードが生成されます。この例では、1つだけになるはずです。

5. 終了条件: エピソードがどのように終了するかを設定します。デフォルトの “If an event occurs for which severity = Normal” のままにします。右側のPreviewをクリックして、アラートが正しく検出されていることを確認します

6. Next をクリック

7. アクション（オプション）: 集約されたアラートに対して実行するアクションを定義します。例えば、ServiceNowでチケットを自動作成したり、メール通知を送信したりできます。この部分はスキップします。

8. Next をクリック

9. ポリシーのタイトルと説明:

   • Policy Title: Service Name Alert Grouping
   • Description: Grouping Service Name alerts together.

10. ポリシーを保存: Next ボタンをクリックしてAggregation Policyを作成します。

確認

ポリシーを保存した後、Go to Episode Review ページに移動し、過去15分間のアラートをフィルタリングし、status=Newのフィルターを追加して、検索ボックスでService Nameを検索します。

特定のアラートの名前が付いたエピソードがすでに存在する場合は、それを閉じて、新しいタイトルで新しいエピソードが生成されるのを待ちます。

ITSI での Observability Cloud Detectors の使用

パート 2: Splunk Observability Cloud から Splunk ITSI へのアラート送信

先ほど設定したSplunk Observability CloudのDetectorがあるため、次のステップは、アラートがトリガーされたときに、そのアラートがSplunk IT Service Intelligence (ITSI) に送信されるようにすることです。この統合により、ITSIはこれらのアラートをNotable Eventとして取り込み、他のイベントと相関させてサービスヘルススコアに貢献させることができます。これを実現する最も一般的な方法は、Splunk Observability CloudのWebhookを使用して、Splunk ITSIで設定されたHTTP Event Collector (HEC) エンドポイントにアラートデータを送信することです。

ステップ 1: Splunk (ITSI) で HTTP Event Collector (HEC) を設定

Splunk Observability CloudがITSIにアラートを送信する前に、それらを受信するためにSplunkインスタンス（ITSIが実行されている場所）にHECエンドポイントが必要です。

1. ITSIをホストしているSplunk EnterpriseまたはSplunk Cloudインスタンスにログインします。
2. Settings > Data Inputs に移動します。
3. HTTP Event Collector をクリックします。
4. Global Settings をクリックします。HECが有効になっていることを確認します。有効になっていない場合は、有効にしてデフォルトポート（例: 8088、ただしSplunk Cloudでは異なる管理方法の場合があります）を指定します。
5. New Token をクリックします。
6. HECトークンにわかりやすい名前を付けます。例: o11y_alerts_for_itsi。
7. Source name override については、オプションでsourcetypeを指定するか、空白のままにしてObservability Cloudで指定するか、デフォルトを使用できます。
8. Default Index については、ITSIがこれらのイベントにアクセスできる適切なインデックスを選択します。多くの場合、ITSIイベント専用のインデックスがあるか、main や itsi_event_management などの一般的なイベントインデックスを使用することがあります。
9. トークンが有効になっていることを確認し、Submit をクリックします。
10. 生成された Token Value をコピーします。これはSplunk Observability CloudでのWebhook設定に必要です。

ステップ 2: Splunk Observability Cloud で Webhook 統合を設定

次に、Splunk Observability Cloudに戻り、作成したHECトークンを使用するWebhookを設定します。

1. Splunk Observability Cloudで Data Management > Available Integrations に移動します。
2. 新しい Splunk platform を追加するオプションを探します。
3. 統合に名前を付けます。例: Splunk ITSI HEC。
4. URL フィールドに、SplunkインスタンスのHECエンドポイントURIを入力します。通常、https://<your-splunk-hec-host-or-ip>:<hec-port>/services/collector/event の形式になります。
5. 先ほど作成した HEC token を追加する必要があります。
6. Payload については、ITSIが理解できるJSONペイロードを構築する必要があります。Splunk Observability Cloudは、ITSIイベント相関に必要なフィールドを含むように設定された、すぐに使えるペイロードを提供しています。
7. 統合を確認し、Save をクリックします

ステップ 3: Webhook を使用するように Detector を更新

次に、パート1で作成したDetectorに戻り、新しく設定したWebhookを使用するように通知設定を更新します。

1. Splunk Observability Cloudで Detectors & SLOs に移動します。
2. EC2 CPU使用率用に作成したDetectorを見つけて編集します。
3. 先ほど作成したAlert ruleをクリックします
4. Alert Recipients セクションに移動します。
5. Add recipient > Splunk platform をクリックし、設定した統合（Splunk ITSI HEC）を目的のアラート重大度（例: Critical、Warning）に対して選択します。
6. Detectorへの変更を保存します。

ステップ 4: 検証

統合をテストするには、本物のアラートがトリガーされるのを待つか、Detectorの設定で許可されている場合は、テストアラートを手動でトリガーするか、しきい値を一時的に下げてアラートを強制的に発生させることができます。Splunk Observability Cloudでアラートがトリガーされると、Webhookを介してSplunk HECエンドポイントにペイロードが送信されるはずです。

Splunkでターゲットインデックスを検索して確認します（例: index=itsi_event_management sourcetype=o11y:itsi:alert host=<your-ec2-instance-id>）。Splunk Observability Cloudからのイベントデータが到着していることが確認できるはずです。

これらの手順により、Splunk Observability CloudのDetectorからのアラートがSplunk ITSIに送信されるようになりました。イベントの相関とNotableの生成は、このワークショップで先ほど説明したのとまったく同じように機能します。