diff --git a/content/ja/_index.md b/content/ja/_index.md index 3936a2d6e7..eedc6b8cf4 100644 --- a/content/ja/_index.md +++ b/content/ja/_index.md @@ -1,30 +1,36 @@ ---- -archetype: home -title: Splunk Observability Workshops -linkTitle: Splunk Observability Workshops -description: Splunk を使用したオブザーバビリティソリューションの構築方法をご紹介します。 -weight: 1 -isCJKLanguage: true ---- - -## Splunk Observabilityワークショップへようこそ - -Splunk Observability Cloudの監視、分析、対応ツールを使用して、アプリケーションとインフラストラクチャをリアルタイムで把握することができます。 - -このワークショップでは、メトリクス、トレース、ログを取り込み、監視し、可視化し、分析するためのクラス最高のオブザーバビリティ（可観測性）プラットフォームについて説明します。 - -![gif](images/observability-hero-dashboard.gif) - -{{% notice title="OpenTelemetry" color="#4f62ad" icon="fab fa-wpexplorer" %}} -このワークショップで[OpenTelemetry](https://opentelemetry.io)をアプリケーションやインフラの分析に役立つテレメトリデータ（メトリクス、トレース、ログ）の計装、生成、収集、エクスポートに使用します。 -{{% /notice %}} - -{{% notice title="GitHub" color="#4078c0" icon="fab fa-github" %}} -このドキュメントには、issueやpull requestで [貢献](https://github.com/splunk/observability-workshop) することができます。より良いワークショップにするために、是非ご協力ください。 -{{% /notice %}} - -{{% notice title="Twitter" color="#1DA1F2" icon="fab fa-twitter" %}} -[Splunk](https://twitter.com/splunk)のTwitterチャンネルでは、アップデート情報や興味深い読み物を紹介しています。 -{{% /notice %}} - -{{%children type="card" description="true" %}} ++++ +title = "Observability *Workshops*." +description = "Splunk を使ったオブザーバビリティソリューションの構築方法を学ぶ" +weight = "1" +noautocards = true +images = ["../images/featured-resources.png"] + +[[cta]] +label = "Rookies を見る" +href = "/splunk4rookies/" +style = "primary" + +[[cta]] +label = "Ninjas を見る" +href = "/ninja-workshops/" +style = "ghost" ++++ + +{{< lead >}} +Splunk Observability Cloud のモニタリング、分析、レスポンスツールを活用して、アプリケーションとインフラストラクチャのインサイトをリアルタイムで取得しましょう。 +これらのワークショップでは、メトリクス、トレース、ログの取り込み、モニタリング、可視化、分析のための最高クラスのオブザーバビリティプラットフォームについて学びます。 +{{< /lead>}} + +{{< divider >}} + +{{< cards >}} +{{< card title="リソース" href="/resources/" icon="book" >}} +Splunk Observability Cloud を最大限に活用するためのリソースです。 +{{< /card >}} +{{< card title="シナリオ" href="/scenarios/" icon="rocket" >}} +Splunk Observability Cloud の価値をご自身で体験するためのガイド付きワークショップです。 +{{< /card >}} +{{< card title="Unsupported Field Workshops" href="/unsupported-field-workshops/" icon="users" >}} +Unsupported Field Workshops は、Splunk Observability Cloud を最大限に活用するために設計されています。 +{{< /card >}} +{{< /cards >}} diff --git a/content/ja/ninja-workshops/10-using-ai-in-o11y/_index.md b/content/ja/ninja-workshops/10-using-ai-in-o11y/_index.md index d0d8ae7ca8..0c03313c87 100644 --- a/content/ja/ninja-workshops/10-using-ai-in-o11y/_index.md +++ b/content/ja/ninja-workshops/10-using-ai-in-o11y/_index.md @@ -5,32 +5,25 @@ weight: 10 archetype: chapter time: 90 minutes authors: ["Pieter Hagen"] -description: Splunk Observability Cloud に組み込まれた人工知能と機械学習の機能を活用して、トラブルシューティングを加速し、異常を検出し、アプリケーションとインフラストラクチャのパフォーマンスに関するより深いインサイトを得る方法を学びます。 +description: Splunk Observability Cloud に組み込まれた人工知能と機械学習の機能を活用して、トラブルシューティングの迅速化、異常検知、アプリケーションとインフラストラクチャのパフォーマンスに関するより深いインサイトの取得方法を学びます。 draft: true hidden: false --- -**Splunk Observability Cloud** は、プラットフォーム全体に高度なAIと機械学習の機能を統合しており、よりスマートに、より速く、より効率的に作業することができます。これらのAI搭載機能により、問題をより迅速に特定し、関係性をより深く理解し、データに基づいた意思決定を自信を持って行うことができます。 +**Splunk Observability Cloud** は、プラットフォーム全体に高度な AI と機械学習の機能を統合しており、よりスマートに、より迅速に、より効率的に作業できるよう支援します。これらの AI 搭載機能により、問題の迅速な特定、関係性のより深い理解、そしてデータに基づいた確信のある意思決定が可能になります。 -このワークショップでは、Splunk Observability Cloudで利用可能なさまざまなAIとMLの機能をハンズオン形式で体験します。以下の内容が含まれます： +このワークショップでは、Splunk Observability Cloud で利用可能なさまざまな AI および ML 機能のハンズオン体験を提供します。以下の内容が含まれます -* **Related Content**: オブザーバビリティデータをナビゲートする際に、AIがどのようにコンテキストに関連するダッシュボード、アラート、リソースを表示するかを学びます。 -* **AutoDetect**: 機械学習が環境固有のパターンと動作に適応するインテリジェントなディテクターを自動的に作成する方法を学びます。 -* **Tag Spotlight**: AIを活用した分析が、タグとメタデータ全体のパターンを分析することで、パフォーマンス問題の根本原因を迅速に特定する方法を探ります。 -* **Log Observer AI**: AIがインテリジェントなパターン検出、異常識別、自然言語によるインサイトでログ分析をどのように強化するかを確認します。 -* **APM AI Assistant**: アプリケーションパフォーマンスの問題のトラブルシューティングと複雑なトレースの理解に対するAI駆動のガイダンスを体験します。 -* **Predictive Analytics**: MLモデルが将来のトレンドを予測し、ユーザーに影響を与える前に潜在的な問題に事前に対処する方法を理解します。 +* **Related Content**: オブザーバビリティデータを閲覧する際に、AI がコンテキストに関連するダッシュボード、アラート、リソースをどのように表示するかを学びます。 +* **AutoDetect**: 機械学習がお客様の環境固有のパターンや動作に適応するインテリジェントなディテクターを自動的に作成する仕組みを学びます。 +* **Tag Spotlight**: AI を活用した分析が、タグやメタデータ全体のパターンを分析することで、パフォーマンス問題の根本原因を迅速に特定する方法を探ります。 +* **Log Observer AI**: AI がインテリジェントなパターン検出、異常の特定、自然言語によるインサイトでログ分析をどのように強化するかを確認します。 +* **APM AI Assistant**: アプリケーションのパフォーマンス問題のトラブルシューティングや複雑なトレースの理解に対する AI 駆動のガイダンスを体験します。 +* **Predictive Analytics**: ML モデルが将来のトレンドを予測し、ユーザーに影響が出る前に潜在的な問題にプロアクティブに対処する方法を理解します。 -このワークショップを終えると、Splunk Observability CloudのAI機能を効果的に使用して以下を実現する方法を理解できます： +このワークショップを終了すると、Splunk Observability Cloud の AI 機能を効果的に活用して以下を実現する方法を理解できます -* 平均検出時間（MTTD）と平均復旧時間（MTTR）の短縮 +* 平均検知時間（MTTD）と平均復旧時間（MTTR）の短縮 * 異常や通常とは異なるパターンの自動検出 * サービス、インフラストラクチャ、ログ間の複雑な関係性のナビゲーション -* AIによるインサイトに基づいた情報に基づく意思決定 - -{{% notice title="ヒント" style="primary" icon="lightbulb" %}} -このワークショップを進める最も簡単な方法は以下を使用することです： - -* このページの右上にある左右の矢印（**<** | **>**） -* キーボードの左（◀️）と右（▶️）のカーソルキー -{{% /notice %}} +* AI を活用したインサイトに基づく情報に裏付けられた意思決定 diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/_index.md b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/_index.md index 1bedf9d4a8..389b8b8aad 100644 --- a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/_index.md +++ b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/_index.md @@ -4,41 +4,33 @@ linkTitle: Ingest Processor for Observability Cloud weight: 11 archetype: chapter authors: ["Tim Hard"] -description: Splunk Ingest Processor を使用してログをメトリクスに変換し、オブザーバビリティコストを最適化し、MTTD を改善する方法を、Splunk Observability Cloud でのハンズオン演習を通じて学びます。 +description: Splunk Ingest Processor を使用してログをメトリクスに変換し、オブザーバビリティのコストを最適化し MTTD を改善する方法を、Splunk Observability Cloud でのハンズオン演習を通じて学びます。 --- -インフラストラクチャとアプリケーション環境がますます複雑になるにつれて、それらが生成するデータ量は大幅に増加し続けています。このデータ量と種類の増加により、実用的なインサイトを得ることが困難になり、問題の特定やトラブルシューティングの効率に影響を与える可能性があります。さらに、このデータを保存してアクセスするコストは急上昇する可能性があります。多くのデータソース、特にログとイベントは、システム運用への重要な可視性を提供します。しかし、ほとんどの場合、効果的な監視とアラートに実際に必要なのは、これらの膨大なログからのわずかな詳細情報のみです。 +インフラストラクチャとアプリケーション環境がますます複雑になるにつれて、それらが生成するデータの量は大幅に増加し続けています。このデータ量と種類の増加により、実用的なインサイトを得ることが困難になり、問題の特定やトラブルシューティングの効率に影響を与える可能性があります。さらに、このデータの保存とアクセスにかかるコストは急騰する可能性があります。多くのデータソース、特にログやイベントは、システム運用に対する重要な可視性を提供します。しかし、ほとんどの場合、効果的な監視とアラートに実際に必要なのは、これらの膨大なログからのわずかな詳細情報のみです。 **一般的な課題:** -* インフラストラクチャとアプリケーション環境の複雑性の増加 -* これらの環境から生成されるデータ量の大幅な増加 -* 大量のデータから実用的なインサイトを得ることの困難さ -* 膨大なデータの保存とアクセスに関連する高いコスト -* ログとイベントは重要な可視性を提供するが、多くの場合、必要な詳細情報はわずか +* インフラストラクチャとアプリケーション環境の複雑さの増大。 +* これらの環境が生成するデータ量の大幅な増加。 +* 大量のデータから実用的なインサイトを得ることの困難さ。 +* 膨大なデータの保存とアクセスに関連する高コスト。 +* ログとイベントは重要な可視性を提供するが、実際に必要な詳細情報はわずかであること。 -これらの課題に対処するために、Splunk Ingest Processorは強力な新機能を提供します：ログイベントをメトリクスに変換する機能です。メトリクスは保存と処理がより効率的であり、問題の迅速な特定を可能にし、それによって平均検出時間（MTTD）を短縮します。元のログやイベントを保持する必要がある場合は、S3などの安価なストレージソリューションに保存できるため、データ取り込みと検索に必要な計算の全体的なコストを削減できます。 +これらの課題に対処するため、Splunk Ingest Processor はログイベントをメトリクスに変換する強力な新機能を提供します。メトリクスは保存と処理がより効率的であり、問題のより迅速な特定を可能にし、平均検出時間（MTTD）を短縮します。元のログやイベントの保持が必要な場合は、S3 などのより安価なストレージソリューションに保存することで、データ取り込みの全体的なコストと検索に必要な計算コストを削減できます。 **ソリューション:** -* 可能な場合はログイベントをメトリクスに変換する -* 必要に応じて元のログまたはイベントを安価なストレージソリューションに保持する -* 保持されたログへのアクセスと分析にフェデレーテッド検索を活用する +* 可能な場合、ログイベントをメトリクスに変換します。 +* 必要に応じて、元のログやイベントをより安価なストレージソリューションに保持します。 +* フェデレーテッドサーチを利用して、保持されたログにアクセスし分析します。 **成果:** -* メトリクスはより効率的に保存および処理される -* 問題のより迅速な特定により、平均検出時間（MTTD）を短縮 -* データ取り込みと計算の全体的なコストの削減 -* 監視効率とリソース最適化の向上 -* 運用コストを削減しながらシステム運用への高い可視性を維持 +* メトリクスは保存と処理がより効率的です。 +* 問題のより迅速な特定により、平均検出時間（MTTD）が短縮されます。 +* データ取り込みと計算の全体的なコストが削減されます。 +* 監視効率とリソース最適化が向上します。 +* 運用コストを削減しながら、システム運用への高い可視性を維持できます。 -このワークショップでは、Ingest ProcessorとSplunk Observability Cloudを使用して、上記で説明した課題にどのように対処できるかを実際に体験する機会があります。 - -{{% notice title="Tip" style="primary" icon="lightbulb" %}} -このワークショップを進める最も簡単な方法は以下を使用することです： - -* このページの右上にある左右の矢印（**<** | **>**） -* キーボードの左（◀️）および右（▶️）カーソルキー - {{% /notice %}} - \ No newline at end of file +このワークショップでは、Ingest Processor と Splunk Observability Cloud を実際に操作し、上記で概説した課題にどのように対処できるかを確認する機会があります。 diff --git a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/_index.md b/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/_index.md index 9316bd7803..c67237fe7f 100644 --- a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/_index.md +++ b/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/_index.md @@ -1,52 +1,45 @@ --- -title: Splunk IT Service Intelligence によるアラートと監視 -linkTitle: Splunk IT Service Intelligence によるアラートと監視 +title: Splunk IT Service Intelligence によるアラートとモニタリング +linkTitle: Splunk IT Service Intelligence によるアラートとモニタリング weight: 12 archetype: chapter authors: ["Doug Erkkila"] -description: シナリオの説明 +time: 90 minutes +description: Splunk Enterprise、AppDynamics、Observability Cloud、ITSI を組み合わせて、基本的なアラートからディテクター駆動の ITSI エピソードまで、エンドツーエンドのアラートとサービスレベルモニタリングを実現します。 hidden: false --- -# ワークショップ: Splunk IT Service Intelligence による監視とアラート +## ワークショップ: Splunk IT Service Intelligence によるモニタリングとアラート -このハンズオンワークショップは、Splunk Enterprise、AppDynamics、Splunk Observability Cloud、およびSplunk IT Service Intelligence (ITSI) の統合されたパワーを効果的にデモンストレーションし、ポジショニングしたい方を対象に設計されています。参加者は、潜在的なクライアントに響く実世界のシナリオとユースケースに焦点を当てながら、これらのプラットフォームを統合する実践的な経験を得ることができます。このワークショップは、技術的な機能をビジネス価値に変換することを重視し、ソリューションアーキテクトが重要な顧客課題にどのように対応するかを自信を持ってデモンストレーションできるようにします。 +このハンズオンワークショップは、Splunk Enterprise、AppDynamics、Splunk Observability Cloud、Splunk IT Service Intelligence (ITSI) の統合された機能を効果的にデモンストレーションし、ポジショニングしたいすべての方を対象に設計されています。参加者は、潜在的なクライアントに響く実際のシナリオやユースケースに焦点を当てながら、これらのプラットフォームを統合する実践的な経験を得ることができます。このワークショップでは、技術的な機能をビジネス価値に変換することに重点を置き、ソリューションアーキテクトがこれらのソリューションが重要な顧客の課題にどのように対応するかを自信を持って紹介できるようにします。 -## イントロダクションと概要 +### イントロダクションと概要 -今日の複雑なIT環境において、アプリケーションとサービスのパフォーマンスと可用性を確保することは最も重要です。このワークショップでは、包括的な監視とアラート機能を提供するために連携する強力なツールの組み合わせ、すなわちSplunk、AppDynamics、Splunk Observability Cloud、およびSplunk IT Service Intelligence (ITSI) をご紹介します。 +今日の複雑な IT 環境において、アプリケーションとサービスのパフォーマンスと可用性を確保することは最も重要です。このワークショップでは、包括的なモニタリングとアラート機能を提供するために連携して動作する強力なツールの組み合わせ – Splunk、AppDynamics、Splunk Observability Cloud、Splunk IT Service Intelligence (ITSI) – を紹介します。 -### 現代の監視における課題 +### 現代のモニタリングの課題 -現代のアプリケーションは、分散アーキテクチャ、マイクロサービス、クラウドインフラストラクチャに依存していることが多いです。この複雑さにより、パフォーマンス問題や障害の根本原因を特定することが困難になっています。従来の監視ツールは個々のコンポーネントに焦点を当てることが多く、サービス全体の健全性とパフォーマンスを理解する上でギャップが生じます。 +現代のアプリケーションは、分散アーキテクチャ、マイクロサービス、クラウドインフラストラクチャに依存していることが多くあります。この複雑さにより、パフォーマンスの問題や障害の根本原因を特定することが困難になっています。従来のモニタリングツールは個々のコンポーネントに焦点を当てることが多く、サービス全体の健全性とパフォーマンスの理解にギャップが生じます。 -### ソリューション: 統合されたオブザーバビリティ +### ソリューション: 統合オブザーバビリティ -包括的なオブザーバビリティ戦略には、さまざまなソースからのデータを統合し、実用的なインサイトを得るために相関させることが必要です。このワークショップでは、Splunk、AppDynamics、Splunk Observability Cloud、およびITSIがどのように連携してこれを実現するかをデモンストレーションします: +包括的なオブザーバビリティ戦略には、さまざまなソースからのデータを統合し、実用的なインサイトを得るために相関させることが必要です。このワークショップでは、Splunk、AppDynamics、Splunk Observability Cloud、ITSI がどのように連携してこれを実現するかをデモンストレーションします: -* **AppDynamics:** 詳細なApplication Performance Monitoring (APM) を提供します。アプリケーションを計装して、トランザクショントレース、コードレベルの診断、ユーザーエクスペリエンスデータを含む詳細なパフォーマンスメトリクスをキャプチャします。AppDynamicsは、アプリケーション*内部*のパフォーマンスボトルネックの特定に優れています。 +* **AppDynamics:** 深いアプリケーションパフォーマンスモニタリング (APM) を提供します。アプリケーションを計装して、トランザクショントレース、コードレベルの診断、ユーザーエクスペリエンスデータなどの詳細なパフォーマンスメトリクスをキャプチャします。AppDynamics は、アプリケーション*内部*のパフォーマンスボトルネックの特定に優れています。 -* **Splunk Observability Cloud:** インフラストラクチャメトリクス、分散トレース、ログを含むフルスタックオブザーバビリティを提供します。サーバーやコンテナからクラウドサービス、カスタムアプリケーションまで、インフラストラクチャ全体の健全性とパフォーマンスの統一ビューを提供します。Splunk Observability Cloudは、スタック全体にわたるパフォーマンス問題の相関に役立ちます。 +* **Splunk Observability Cloud:** インフラストラクチャメトリクス、分散トレース、ログを含むフルスタックオブザーバビリティを提供します。サーバーやコンテナからクラウドサービスやカスタムアプリケーションまで、インフラストラクチャ全体の健全性とパフォーマンスの統合ビューを提供します。Splunk Observability Cloud は、スタック全体のパフォーマンスの問題を相関させるのに役立ちます。 -* **Splunk:** ログ分析、セキュリティ情報およびイベント管理 (SIEM)、広範なデータ分析のための中央プラットフォームとして機能します。AppDynamics、Splunk Observability Cloud、およびその他のソースからデータを取り込み、強力な検索、可視化、相関機能を実現します。SplunkはIT環境の包括的なビューを提供します。 +* **Splunk:** ログ分析、セキュリティ情報およびイベント管理 (SIEM)、より広範なデータ分析のための中央プラットフォームとして機能します。AppDynamics、Splunk Observability Cloud、その他のソースからデータを取り込み、強力な検索、可視化、相関機能を提供します。Splunk は IT 環境の全体像を提供します。 -* **Splunk IT Service Intelligence (ITSI):** 他のすべてのプラットフォームからのデータを相関させることで、サービスインテリジェンスを提供します。ITSIを使用すると、サービスを定義し、依存関係をマッピングし、サービス全体の健全性とパフォーマンスを反映するKey Performance Indicators (KPIs) を監視できます。ITSIは、IT問題の*ビジネスへの影響*を理解するために不可欠です。 +* **Splunk IT Service Intelligence (ITSI):** すべての他のプラットフォームからのデータを相関させることでサービスインテリジェンスを提供します。ITSI を使用すると、サービスの定義、依存関係のマッピング、およびサービスの全体的な健全性とパフォーマンスを反映する重要業績評価指標 (KPI) のモニタリングが可能になります。ITSI は、IT の問題の*ビジネスへの影響*を理解するために不可欠です。 ## ワークショップの目標 このワークショップの終了時には、参加者は以下のことができるようになります: -* 包括的なオブザーバビリティ戦略におけるSplunk、AppDynamics、Splunk Observability Cloud、およびSplunk IT Service Intelligenceの相互補完的な価値提案を明確に説明する。 -* データフローと相関機能を強調しながら、これらのプラットフォーム間の統合ポイントを自信を持ってデモンストレーションする。 -* 実践的なアラートシナリオを紹介しながら、Splunk Enterprise、AppDynamics、およびSplunk Observability Cloudで基本的なアラートを作成および設定する。 -* サービス中心の監視を強調しながら、Splunk ITSIでのKey Performance Indicator (KPI) の作成とアラートの説得力のあるデモンストレーションを構築および提示する。 -* インシデント管理の改善とMTTRの短縮のためのSplunk ITSIにおけるエピソードの価値を説明およびデモンストレーションする。 -* ROIに焦点を当て、特定の顧客の課題に対処しながら、技術的な機能をビジネス成果に変換する。 - -{{% notice title="Tip" style="primary" icon="lightbulb" %}} -このワークショップを最も簡単にナビゲートする方法は以下の通りです: - -* このページの右上にある左右の矢印 (**<** | **>**) を使用する -* キーボードの左 (◀️) および右 (▶️) カーソルキーを使用する - {{% /notice %}} - \ No newline at end of file +* 包括的なオブザーバビリティ戦略における Splunk、AppDynamics、Splunk Observability Cloud、Splunk IT Service Intelligence の補完的な価値提案を明確に説明する。 +* これらのプラットフォーム間の統合ポイントを自信を持ってデモンストレーションし、データフローと相関機能を強調する。 +* Splunk Enterprise、AppDynamics、Splunk Observability Cloud で基本的なアラートを作成および設定し、実践的なアラートシナリオを紹介する。 +* Splunk ITSI での重要業績評価指標 (KPI) の作成とアラートの説得力のあるデモンストレーションを構築して提示し、サービス中心のモニタリングを強調する。 +* Splunk ITSI におけるエピソードのインシデント管理の改善と MTTR の短縮に対する価値を説明しデモンストレーションする。 +* 技術的な機能をビジネス成果に変換し、ROI に焦点を当て、特定の顧客のペインポイントに対処する。 diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/_index.md b/content/ja/ninja-workshops/14-cisco-ai-pods/_index.md index ee084dd783..ee516e2f9b 100644 --- a/content/ja/ninja-workshops/14-cisco-ai-pods/_index.md +++ b/content/ja/ninja-workshops/14-cisco-ai-pods/_index.md @@ -1,36 +1,29 @@ --- -title: Splunk Observability Cloud による Cisco AI Pods のモニタリング -linkTitle: Splunk Observability Cloud による Cisco AI Pods のモニタリング +title: Splunk Observability Cloud による Cisco AI Pods の監視 +linkTitle: Splunk Observability Cloud による Cisco AI Pods の監視 weight: 14 archetype: chapter time: 2 minutes authors: ["Derek Mitchell"] -description: This hands-on workshop demonstrates how to monitor Cisco AI Pods with Splunk Observability Cloud. Learn to deploy the OpenTelemetry Collector in Red Hat OpenShift, ingest infrastructure metrics using Prometheus receivers, and configure APM to monitor Python services that interact with Large Language Models (LLMs). +description: このハンズオンワークショップでは、Splunk Observability Cloud を使用して Cisco AI Pods を監視する方法を紹介します。Red Hat OpenShift に OpenTelemetry Collector をデプロイし、Prometheus レシーバーを使用してインフラストラクチャメトリクスを取り込み、Large Language Models (LLMs) と連携する Python サービスを監視するための APM の設定方法を学びます。 draft: false hidden: false --- -**Cisco の AI 対応 PODs** は、ハードウェアとソフトウェアの最高の技術を組み合わせ、多様なニーズに合わせた堅牢でスケーラブルかつ効率的な AI 対応インフラストラクチャを構築します。 +**Cisco の AI-ready PODs** は、ハードウェアとソフトウェアの最高の技術を組み合わせて、多様なニーズに合わせた堅牢でスケーラブルかつ効率的な AI 対応インフラストラクチャを構築します。 -**Splunk Observability Cloud** は、このインフラストラクチャ全体と、このスタック上で実行されるすべてのアプリケーションコンポーネントに対する包括的な可視性を提供します。 +**Splunk Observability Cloud** は、このインフラストラクチャ全体と、このスタック上で実行されているすべてのアプリケーションコンポーネントに対して包括的な可視性を提供します。 -Cisco AI POD 環境向けに Splunk Observability Cloud を構成する手順は完全に文書化されています（詳細は [こちら](https://github.com/signalfx/splunk-opentelemetry-examples/tree/main/collector/cisco-ai-ready-pods) を参照してください）。 +Cisco AI POD 環境向けに Splunk Observability Cloud を構成する手順は完全にドキュメント化されています（詳細は[こちら](https://github.com/signalfx/splunk-opentelemetry-examples/tree/main/collector/cisco-ai-ready-pods)を参照してください）。 -ただし、インストール手順を練習するために Cisco AI POD 環境にアクセスできるとは限りません。 +ただし、Cisco AI POD 環境にアクセスしてインストール手順を練習することが常に可能とは限りません。 -このワークショップでは、実際の Cisco AI POD にアクセスすることなく、Splunk Observability Cloud で Cisco AI PODs をモニタリングするために使用されるいくつかの技術をデプロイし、操作するハンズオン体験を提供します。以下の内容が含まれます： +このワークショップでは、実際の Cisco AI POD へのアクセスを必要とせずに、Splunk Observability Cloud で Cisco AI PODs を監視するために使用されるいくつかの技術をデプロイおよび操作するハンズオン体験を提供します。以下の内容が含まれます: -* Red Hat OpenShift クラスターへの **OpenTelemetry Collector** のデプロイを練習します。 -* インフラストラクチャメトリクスを取り込むために、コレクターに **Prometheus** receiverを追加する練習をします。 -* クラスターへの **Weaviate** ベクトルデータベースのデプロイを練習します。 -* 大規模言語モデル（LLM）と連携する Python サービスを **OpenTelemetry** でインストルメントする練習をします。 -* LLM と連携するアプリケーションのトレースで OpenTelemetry がキャプチャする詳細情報を理解します。 +* Red Hat OpenShift クラスターに **OpenTelemetry Collector** をデプロイする練習 +* コレクターに **Prometheus** レシーバーを追加してインフラストラクチャメトリクスを取り込む練習 +* クラスターに **Weaviate** ベクトルデータベースをデプロイする練習 +* Large Language Models (LLMs) と連携する Python サービスを **OpenTelemetry** で計装する練習 +* LLM と連携するアプリケーションのトレースで OpenTelemetry がキャプチャする詳細の理解 -> 注意：ワークショップセットアップセクションは、ワークショップ主催者のみが実行する必要があります - -{{% notice title="ヒント" style="primary" icon="lightbulb" %}} -このワークショップを最も簡単にナビゲートする方法は以下の通りです： - -* このページの右上にある左右の矢印（ **<** | **>** ）を使用する -* キーボードの左（◀️）および右（▶️）カーソルキーを使用する - {{% /notice %}} +> 注: ワークショップのセットアップセクションは、ワークショップの主催者のみが実行する必要があります diff --git a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/1-remote-installation/_index.md b/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/1-remote-installation/_index.md index 0767ad6422..a36d7da2b2 100644 --- a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/1-remote-installation/_index.md +++ b/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/1-remote-installation/_index.md @@ -1,13 +1,13 @@ --- -title: リモートインストール +title: Remote Installation weight: 1 time: 2 minutes -description: smartagentctl を使用して、複数のリモートホストに AppDynamics Smart Agent をインストールおよび管理する方法を学びます。 +description: smartagentctl を使用して複数のリモートホストに AppDynamics Smart Agent をインストールおよび管理する方法を学びます。 --- ## はじめに -このワークショップでは、**smartagentctl** コマンドラインツールを使用して、複数のリモートホストに同時に **AppDynamics Smart Agent** をインストールおよび管理する方法を紹介します。このアプローチは、JenkinsやGitHub Actionsなどの追加の自動化ツールを必要とせずに、SSHベースのリモート実行を使用してサーバーフリートにSmart Agentを迅速にデプロイするのに最適です。 +このワークショップでは、**smartagentctl** コマンドラインツールを使用して、複数のリモートホストに **AppDynamics Smart Agent** を同時にインストールおよび管理する方法を説明します。このアプローチは、Jenkins や GitHub Actions などの追加の自動化ツールを必要とせずに、SSH ベースのリモート実行を使用してサーバー群に Smart Agent を迅速にデプロイするのに最適です。 ![AppDynamics](https://img.shields.io/badge/AppDynamics-0078D4?style=flat) @@ -15,25 +15,25 @@ description: smartagentctl を使用して、複数のリモートホストに A このワークショップでは、以下の方法を学びます -- `remote.yaml` ファイルを使用した **リモートホストの構成** +- `remote.yaml` ファイルを使用した**リモートホストの設定** - `config.ini` を使用した **Smart Agent 設定の構成** -- SSH経由で複数のホストに同時に **Smart Agent をデプロイ** -- インフラストラクチャ全体でリモートから **エージェントの開始と停止** -- すべてのリモートホストでの **エージェントステータスの確認** -- 一般的なインストールと接続の問題の **トラブルシューティング** +- SSH 経由で複数のホストに同時に **Smart Agent をデプロイ**する方法 +- インフラストラクチャ全体でリモートから**エージェントの起動と停止**を行う方法 +- すべてのリモートホストで**エージェントのステータスを確認**する方法 +- 一般的なインストールおよび接続の問題の**トラブルシューティング** ## 主な機能 -- 🚀 **SSH による直接デプロイ** - 追加の自動化プラットフォームが不要 -- 🔄 **完全なライフサイクル管理** - エージェントのインストール、開始、停止、アンインストール -- 🏗️ **Configuration as Code** - YAMLおよびINIベースの構成ファイル -- 🔐 **セキュア** - SSHキーベースの認証 -- 📈 **同時実行** - 並列デプロイのための構成可能な同時実行性 -- 🎛️ **シンプルな CLI** - 使いやすいsmartagentctlコマンドラインインターフェース +- 🚀 **SSH 直接デプロイ** - 追加の自動化プラットフォームが不要 +- 🔄 **完全なライフサイクル管理** - エージェントのインストール、起動、停止、アンインストール +- 🏗️ **コードとしての設定** - YAML および INI ベースの設定ファイル +- 🔐 **セキュア** - SSH キーベースの認証 +- 📈 **並行実行** - 並列デプロイのための設定可能な並行性 +- 🎛️ **シンプルな CLI** - 使いやすい smartagentctl コマンドラインインターフェース ## アーキテクチャ概要 -```text +``` ┌─────────────────────────────────────────────────────────────────┐ │ Remote Installation Architecture │ ├─────────────────────────────────────────────────────────────────┤ @@ -54,35 +54,28 @@ description: smartagentctl を使用して、複数のリモートホストに A このワークショップには以下が含まれます 1. **前提条件** - 必要なアクセス、ツール、権限 -2. **構成** - `config.ini` と `remote.yaml` のセットアップ -3. **インストールと起動** - リモートホストへのSmart Agentのデプロイと起動 +2. **設定** - `config.ini` と `remote.yaml` のセットアップ +3. **インストールと起動** - リモートホストへの Smart Agent のデプロイと起動 4. **トラブルシューティング** - 一般的な問題と解決策 ## 前提条件 -- smartagentctlがインストールされたControl Node -- すべてのリモートホストへのSSHアクセス -- 認証用に構成されたSSH秘密鍵 -- Control Nodeでのsudo権限 -- SSHが有効になっているリモートホスト -- AppDynamicsアカウントの認証情報 +- smartagentctl がインストールされたコントロールノード +- すべてのリモートホストへの SSH アクセス +- 認証用に設定された SSH 秘密鍵 +- コントロールノードでの sudo 権限 +- SSH が有効化されたリモートホスト +- AppDynamics アカウントの認証情報 ## 利用可能なコマンド -`smartagentctl` ツールは、以下のリモート操作をサポートしています - -- `start --remote` - リモートホストにSmart Agentをインストールして起動 -- `stop --remote` - リモートホストのSmart Agentを停止 -- `status --remote` - リモートホストのSmart Agentステータスを確認 -- `install --remote` - 起動せずにSmart Agentをインストール -- `uninstall --remote` - リモートホストからSmart Agentを削除 -- `--service` フラグ - systemdサービスとしてインストール - -すべてのコマンドは、詳細なログのための `--verbose` フラグをサポートしています。 +`smartagentctl` ツールは以下のリモート操作をサポートしています -{{% notice title="Tip" style="primary" icon="lightbulb" %}} -このワークショップを進める最も簡単な方法は以下を使用することです +- `start --remote` - リモートホストに Smart Agent をインストールして起動 +- `stop --remote` - リモートホストの Smart Agent を停止 +- `status --remote` - リモートホストの Smart Agent のステータスを確認 +- `install --remote` - Smart Agent を起動せずにインストール +- `uninstall --remote` - リモートホストから Smart Agent を削除 +- `--service` フラグ - systemd サービスとしてインストール -- このページの右上にある左右の矢印（**<** | **>**） -- キーボードの左（◀️）と右（▶️）のカーソルキー -{{% /notice %}} +すべてのコマンドは、詳細なログ出力のための `--verbose` フラグをサポートしています。 diff --git a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/2-jenkins-automation/_index.md b/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/2-jenkins-automation/_index.md index fb64feaa51..d9d9ada07f 100644 --- a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/2-jenkins-automation/_index.md +++ b/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/2-jenkins-automation/_index.md @@ -1,5 +1,5 @@ --- -title: Jenkins 自動化 +title: Jenkins Automation weight: 2 time: 2 minutes description: Jenkins パイプラインを使用して、複数のホストにわたる AppDynamics Smart Agent のデプロイとライフサイクル管理を自動化する方法を学びます。 @@ -7,33 +7,33 @@ description: Jenkins パイプラインを使用して、複数のホストに ## はじめに -このワークショップでは、**Jenkins** を使用して複数のEC2インスタンスにわたる **AppDynamics Smart Agent** のデプロイとライフサイクル管理を自動化する方法を紹介します。10台のホストでも10,000台のホストでも、Jenkinsパイプラインを活用したスケーラブルで安全かつ再現性のあるSmart Agent運用方法を説明します。 +このワークショップでは、**Jenkins** を使用して複数の EC2 インスタンスにわたる **AppDynamics Smart Agent** のデプロイとライフサイクル管理を自動化する方法を説明します。10 台のホストでも 10,000 台のホストでも、Jenkins パイプラインを活用してスケーラブルで安全かつ再現可能な Smart Agent 運用を実現する方法を紹介します。 ![Jenkins and AppDynamics](https://img.shields.io/badge/Jenkins-D24939?style=flat&logo=jenkins&logoColor=white) ![AppDynamics](https://img.shields.io/badge/AppDynamics-0078D4?style=flat) ## 学習内容 -このワークショップでは、以下の内容を学びます: +このワークショップでは、以下の内容を学びます -- Jenkinsを使用して複数のホストに同時に **Smart Agent をデプロイ** する -- 安全なSSHおよびAppDynamicsアクセスのために **Jenkins 認証情報を設定** する -- 柔軟なデプロイシナリオのために **パラメータ化されたパイプラインを作成** する -- 数千台のホストに対応するために **バッチ処理を実装** する -- インストール、設定、停止、クリーンアップを含む **エージェントの完全なライフサイクルを管理** する -- 自動エラー追跡とレポートにより **障害を適切に処理** する +- Jenkins を使用して複数のホストに同時に **Smart Agent をデプロイ**する +- 安全な SSH および AppDynamics アクセスのための **Jenkins 認証情報を設定**する +- 柔軟なデプロイシナリオのための**パラメータ化されたパイプラインを作成**する +- 数千台のホストにスケールするための**バッチ処理を実装**する +- インストール、設定、停止、クリーンアップなど**エージェントの完全なライフサイクルを管理**する +- 自動エラー追跡とレポートによる**障害のグレースフルハンドリング**を行う ## 主な機能 -- **並列デプロイ** - 複数のホストに同時にデプロイ -- **完全なライフサイクル管理** - エージェントのインストール、アンインストール、停止、クリーンアップ -- **Infrastructure as Code** - すべてのパイプラインをバージョン管理 -- **セキュア** - Jenkins認証情報によるSSH鍵ベースの認証 -- **大規模スケーラブル** - 自動バッチ処理により数千台のホストにデプロイ -- **Jenkins Agent** - AWS VPC内で実行 +- 🚀 **並列デプロイ** - 複数のホストに同時にデプロイ +- 🔄 **完全なライフサイクル管理** - エージェントのインストール、アンインストール、停止、クリーンアップ +- 🏗️ **Infrastructure as Code** - すべてのパイプラインをバージョン管理 +- 🔐 **セキュア** - Jenkins 認証情報による SSH キーベース認証 +- 📈 **大規模スケーラブル** - 自動バッチ処理で数千台のホストにデプロイ +- 🎛️ **Jenkins Agent** - AWS VPC 内で実行 ## アーキテクチャ概要 -```text +``` ┌─────────────────────────────────────────────────────────────────┐ │ Jenkins-based Deployment │ ├─────────────────────────────────────────────────────────────────┤ @@ -51,37 +51,30 @@ description: Jenkins パイプラインを使用して、複数のホストに ## ワークショップの構成 -このワークショップには以下の内容が含まれます: +このワークショップには以下が含まれます 1. **アーキテクチャと設計** - システム設計とネットワークトポロジーの理解 2. **Jenkins セットアップ** - Jenkins、認証情報、エージェントの設定 -3. **パイプライン作成** - デプロイパイプラインの作成と設定 +3. **パイプラインの作成** - デプロイパイプラインの作成と設定 4. **デプロイワークフロー** - デプロイの実行とインストールの検証 ## 前提条件 -- Jenkinsサーバー（2.300以降）とPipelineプラグイン -- ターゲットEC2インスタンスと同じVPC内のJenkinsエージェント -- 認証用のSSHキーペア -- AppDynamics Smart Agentパッケージ -- SSHアクセス可能なターゲットUbuntu EC2インスタンス +- Pipeline プラグインを備えた Jenkins サーバー (2.300+) +- ターゲット EC2 インスタンスと同じ VPC 内の Jenkins エージェント +- 認証用の SSH キーペア +- AppDynamics Smart Agent パッケージ +- SSH アクセスが可能なターゲット Ubuntu EC2 インスタンス ## GitHub リポジトリ -すべてのパイプラインコードと設定ファイルはGitHubリポジトリで公開されています: +すべてのパイプラインコードと設定ファイルは GitHub リポジトリで利用できます **[https://github.com/chambear2809/sm-jenkins](https://github.com/chambear2809/sm-jenkins)** -リポジトリには以下が含まれます: +リポジトリには以下が含まれます -- 完全なJenkinsfileパイプライン定義 +- 完全な Jenkinsfile パイプライン定義 - 詳細なセットアップドキュメント - 設定例 - トラブルシューティングガイド - -{{% notice title="ヒント" style="primary" icon="lightbulb" %}} -このワークショップを最も簡単にナビゲートするには、以下を使用します: - -- このページの右上にある左右の矢印（**<** | **>**） -- キーボードの左（◀️）および右（▶️）カーソルキー -{{% /notice %}} diff --git a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/3-github-actions/_index.md b/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/3-github-actions/_index.md index b851e8b1b7..c573126403 100644 --- a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/3-github-actions/_index.md +++ b/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/3-github-actions/_index.md @@ -2,38 +2,38 @@ title: GitHub Actions による自動化 weight: 3 time: 2 minutes -description: セルフホストランナーを使用した GitHub Actions による AppDynamics Smart Agent デプロイの自動化方法を学びます。 +description: GitHub Actions とセルフホストランナーを使用して AppDynamics Smart Agent のデプロイを自動化する方法を学びます。 --- ## はじめに -このワークショップでは、セルフホストランナーを使用した **GitHub Actions** で、複数のEC2インスタンスにわたる **AppDynamics Smart Agent** のデプロイとライフサイクル管理を自動化する方法を紹介します。10台のホストでも10,000台のホストでも、このガイドではスケーラブルで安全かつ再現可能なSmart Agent運用のためにGitHub Actionsワークフローを活用する方法を説明します。 +このワークショップでは、**GitHub Actions** とセルフホストランナーを使用して、複数の EC2 インスタンスにわたる **AppDynamics Smart Agent** のデプロイとライフサイクル管理を自動化する方法を説明します。10 台のホストでも 10,000 台のホストでも、このガイドでは GitHub Actions ワークフローを活用してスケーラブルで安全かつ再現可能な Smart Agent 運用を実現する方法を紹介します。 ![GitHub Actions and AppDynamics](https://img.shields.io/badge/GitHub%20Actions-2088FF?style=flat&logo=github-actions&logoColor=white) ![AppDynamics](https://img.shields.io/badge/AppDynamics-0078D4?style=flat) ## 学習内容 -このワークショップでは、以下の内容を学びます: +このワークショップでは、以下の方法を学びます -- GitHub Actionsワークフローを使用して複数のホストに **Smart Agent をデプロイ** する -- 安全な認証情報管理のために **GitHub Secrets と Variables を設定** する -- AWS VPC内に **セルフホストランナーをセットアップ** する -- 数千台のホストにスケールするための **自動バッチ処理を実装** する -- インストール、アンインストール、停止、クリーンアップなど **エージェントの完全なライフサイクルを管理** する -- **ワークフローの実行を監視** し、問題をトラブルシューティングする +- GitHub Actions ワークフローを使用して複数のホストに **Smart Agent をデプロイ**する +- セキュアな認証情報管理のために **GitHub secrets と variables を設定**する +- AWS VPC に**セルフホストランナーをセットアップ**する +- 数千台のホストに対応するために**自動バッチ処理を実装**する +- インストール、アンインストール、停止、クリーンアップなど**エージェントの完全なライフサイクルを管理**する +- **ワークフローの実行を監視**し、問題をトラブルシューティングする ## 主な機能 -- **並列デプロイ** - 複数のホストに同時にデプロイ -- **完全なライフサイクル管理** - エージェントのすべての操作をカバーする11のワークフロー -- **Infrastructure as Code** - すべてのワークフローをGitHubでバージョン管理 -- **セキュア** - SSH鍵はGitHub Secretsに保存、プライベートVPCネットワーキング -- **大規模スケーラブル** - 自動バッチ処理で数千台のホストにデプロイ -- **セルフホストランナー** - AWS VPC内で実行 +- 🚀 **並列デプロイ** - 複数のホストに同時にデプロイ +- 🔄 **完全なライフサイクル管理** - すべてのエージェント操作をカバーする 11 のワークフロー +- 🏗️ **Infrastructure as Code** - すべてのワークフローを GitHub でバージョン管理 +- 🔐 **セキュア** - SSH 鍵を GitHub secrets に保存、プライベート VPC ネットワーキング +- 📈 **大規模スケーラビリティ** - 自動バッチ処理で数千台のホストにデプロイ +- 🎛️ **セルフホストランナー** - AWS VPC 内で実行 ## アーキテクチャ概要 -```text +``` ┌─────────────────────────────────────────────────────────────────┐ │ GitHub Actions-based Deployment │ ├─────────────────────────────────────────────────────────────────┤ @@ -51,50 +51,43 @@ description: セルフホストランナーを使用した GitHub Actions によ ## ワークショップの構成 -このワークショップは以下の内容で構成されています: +このワークショップには以下が含まれます -1. **アーキテクチャと設計** - GitHub Actionsワークフローアーキテクチャの理解 -2. **GitHub のセットアップ** - Secrets、Variables、セルフホストランナーの設定 -3. **ワークフローの作成** - 11の利用可能なワークフローの理解と使用 +1. **アーキテクチャと設計** - GitHub Actions ワークフローアーキテクチャの理解 +2. **GitHub のセットアップ** - secrets、variables、セルフホストランナーの設定 +3. **ワークフローの作成** - 11 の利用可能なワークフローの理解と使用 4. **デプロイの実行** - ワークフローの実行とインストールの検証 ## 利用可能なワークフロー -このソリューションには、Smart Agentの完全なライフサイクル管理のための **11のワークフロー** が含まれています: +このソリューションには、Smart Agent の完全なライフサイクル管理のための **11 のワークフロー**が含まれています | カテゴリ | ワークフロー数 | 説明 | -| --- | --- | --- | +|----------|-----------|-------------| | **デプロイ** | 1 | Smart Agent のデプロイと起動 | | **エージェントのインストール** | 4 | Node、Machine、DB、Java エージェントのインストール | | **エージェントのアンインストール** | 4 | 特定のエージェントタイプのアンインストール | -| **エージェント管理** | 2 | 停止/クリーンおよび完全なクリーンアップ | +| **エージェント管理** | 2 | 停止/クリーンおよび完全クリーンアップ | -すべてのワークフローはスケーラビリティのための自動バッチ処理をサポートしています。 +すべてのワークフローはスケーラビリティのための自動バッチ処理をサポートしています！ ## 前提条件 -- リポジトリアクセス権を持つGitHubアカウント -- Ubuntu EC2インスタンスを持つAWS VPC -- 同じVPC内のセルフホストGitHub Actionsランナー -- 認証用のSSHキーペア -- AppDynamics Smart Agentパッケージ +- リポジトリアクセス権を持つ GitHub アカウント +- Ubuntu EC2 インスタンスを含む AWS VPC +- 同じ VPC 内のセルフホスト GitHub Actions ランナー +- 認証用の SSH キーペア +- AppDynamics Smart Agent パッケージ ## GitHub リポジトリ -すべてのワークフローコードと設定ファイルはGitHubリポジトリで利用できます: +すべてのワークフローコードと設定ファイルは GitHub リポジトリで入手できます **[https://github.com/chambear2809/github-actions-lab](https://github.com/chambear2809/github-actions-lab)** -リポジトリには以下が含まれています: +リポジトリには以下が含まれます -- 11の完全なワークフロー YAMLファイル +- 11 の完全なワークフロー YAML ファイル - 詳細なセットアップドキュメント - アーキテクチャ図 - トラブルシューティングガイド - -{{% notice title="ヒント" style="primary" icon="lightbulb" %}} -このワークショップを最も簡単にナビゲートするには、以下を使用します: - -- このページの右上にある左右の矢印（**<** | **>**） -- キーボードの左（◀️）および右（▶️）カーソルキー -{{% /notice %}} diff --git a/content/ja/ninja-workshops/16-obi-ebpf/_index.md b/content/ja/ninja-workshops/16-obi-ebpf/_index.md index 5c7042b45f..5e1f0e2f3a 100644 --- a/content/ja/ninja-workshops/16-obi-ebpf/_index.md +++ b/content/ja/ninja-workshops/16-obi-ebpf/_index.md @@ -1,23 +1,23 @@ --- draft: false hidden: false -title: Zero-Code APM with OBI and eBPF -linkTitle: Zero-Code APM with OBI +title: OBI と eBPF によるゼロコード APM +linkTitle: OBI によるゼロコード APM weight: 16 archetype: chapter time: 90 minutes authors: ["Jeremy Hicks"] -description: OpenTelemetry eBPF Instrumentation (OBI) がコードを一切変更せずにアプリケーションへ完全な分散トレーシングを追加し、Splunk Observability Cloud にテレメトリを送信する方法を体験するハンズオンワークショップです。 +description: OpenTelemetry eBPF Instrumentation (OBI) がコードを一行も変更せずにアプリケーションへ完全な分散トレーシングを追加し、Splunk Observability Cloud にテレメトリを送信する方法を体験するハンズオンワークショップです。 --- -このワークショップでは、**OpenTelemetry eBPF Instrumentation (OBI)** のパワーを体験します。OBI は、Linux カーネルから直接サービスを計装する、コード変更不要のアプリケーションパフォーマンスモニタリング手法です。 +このワークショップでは、**OpenTelemetry eBPF Instrumentation (OBI)** のパワーを体験します。OBI は Linux カーネルから直接サービスを計装する、ゼロコードのアプリケーションパフォーマンス監視アプローチです。 -3つのフェーズを順に進めていきます。各フェーズは前のフェーズを基に構築されています: +3つのフェーズを順番に進めていきます。各フェーズは前のフェーズの上に構築されます: -- **Phase 0 -- Python ウォームアップ**: ホスト上で素の Python アプリを実行します。OBI バイナリを使用してカーネルから APM トレーシングを追加します -- SDK もコード変更も不要です。 +- **Phase 0 -- Python ウォームアップ**: ホスト上で素の Python アプリを実行します。OBI バイナリを使用してカーネルから APM トレーシングを追加します。SDK もコード変更も不要です。 - **Phase 1 -- Docker (OBI 導入前)**: 3つのポリグロットマイクロサービス (Node.js + Go + Go) を Docker Compose でデプロイします。APM が空であることを確認します。 - **Phase 2 -- Docker (マジック)**: OBI コンテナを1つ追加します。3つのサービスすべてにわたる完全な分散トレースが Splunk APM に表示されます。コード変更はゼロです。 -- **Phase 3 -- Kubernetes**: 同じサービスを K8s にデプロイし、Splunk OTel Collector Helm chart を使用します。1つのフラグで OBI を有効化します。同じコード変更不要のトレーシングを、エンタープライズグレードのオーケストレーションで実現します。 +- **Phase 3 -- Kubernetes**: 同じサービスを Splunk OTel Collector Helm chart を使用して K8s にデプロイします。1つのフラグで OBI を有効にします。同じゼロコードトレーシングを、エンタープライズグレードのオーケストレーションで実現します。 ```text Phase 0: Python (:5150) ──── instrumented by OBI binary on host @@ -31,10 +31,3 @@ Phase 2: Same three services + one OBI container Phase 3: Same services on Kubernetes + Splunk OTel Collector Helm chart + obi.enabled=true ↑ same tracing, scales to any cluster ``` - -{{% notice title="Tip" style="primary" icon="lightbulb" %}} -このワークショップを進める最も簡単な方法は以下を使用することです: - -- このページの右上にある左右の矢印 (**<** | **>**) -- キーボードの左右カーソルキー -{{% /notice %}} diff --git a/content/ja/ninja-workshops/18-agentic-ai/_index.md b/content/ja/ninja-workshops/18-agentic-ai/_index.md index 8bb4a35c07..deee8ae347 100644 --- a/content/ja/ninja-workshops/18-agentic-ai/_index.md +++ b/content/ja/ninja-workshops/18-agentic-ai/_index.md @@ -1,35 +1,29 @@ --- -title: Splunk Observability Cloud によるエージェント型 AI アプリケーションの監視 -linkTitle: Splunk Observability Cloud によるエージェント型 AI アプリケーションの監視 +title: Monitoring Agentic AI Applications with Splunk Observability Cloud +linkTitle: Monitoring Agentic AI Applications with Splunk Observability Cloud weight: 18 archetype: chapter time: 2 minutes authors: ["Derek Mitchell"] -description: このハンズオンワークショップでは、Splunk Observability Cloud を使用してエージェント型 AI アプリケーションを監視する方法を紹介します。OpenTelemetry Collector のデプロイ、LangChain を使用した Python アプリケーションの計装、品質の問題やセキュリティリスクを特定するための LLM インタラクションの評価設定について学びます。 +description: このハンズオンワークショップでは、Splunk Observability Cloud を使用して Agentic AI アプリケーションを監視する方法を学びます。OpenTelemetry Collector のデプロイ、LangChain を使用した Python アプリケーションのインストルメンテーション、品質の問題やセキュリティリスクを特定するための LLM インタラクションの評価設定について学びます。 draft: false hidden: false --- **Splunk Observability for AI** は、AI アプリケーションスタックのパフォーマンス、品質、セキュリティ、 -コストを監視します。以下の機能が含まれます +およびコストを監視します。以下の機能が含まれます: -* **AI Agent Monitoring** - LLM およびエージェント型アプリケーションのパフォーマンス、品質、セキュリティ、コストを監視します。 -* **AI Infrastructure Monitoring** - AI インフラストラクチャの健全性、可用性、消費量（使用量）を監視します。 +* **AI Agent Monitoring** - LLM およびエージェントアプリケーションのパフォーマンス、品質、セキュリティ、コストを監視します。 +* **AI Infrastructure Monitoring** - AI インフラストラクチャの正常性、可用性、消費量（使用量）を監視します。 -このワークショップでは、Splunk Observability Cloud でこれらの機能をデプロイし、活用するためのハンズオン体験を提供します。以下の内容が含まれます +このワークショップでは、Splunk Observability Cloud でこれらの機能をデプロイし、 +操作するハンズオン体験を提供します。具体的には以下の内容が含まれます: * **Azure** アカウントを **Splunk Observability Cloud** に接続して、AI インフラストラクチャ関連のメトリクスを取得する方法を理解します。 * AI インフラストラクチャに関連するすぐに使える**ダッシュボード**と**ナビゲーター**を探索します。 -* **LangChain** と **LangGraph** で構築されたエージェント型 AI アプリケーションの**アーキテクチャ**を確認します。 -* エージェント型 AI アプリケーションをデプロイし、**OpenTelemetry** で**計装**する練習をします。 -* Splunk Observability Cloud で**メトリクス、トレース、ログ**を使用してエージェントのパフォーマンスを理解する方法を探索します。 -* エージェント型 AI アプリケーションを変更して**ツールコール**と**エージェント**を使用する練習をします。 -* アプリケーションに**品質の問題**を追加し、**セマンティック品質評価**を使用して Splunk Observability Cloud で検出する練習をします。 -* アプリケーションに **AI Defense の計装**と**セキュリティリスク**を追加し、Splunk Observability Cloud で検出する練習をします。 - -{{% notice title="Tip" style="primary" icon="lightbulb" %}} -このワークショップを最も簡単にナビゲートする方法は以下のとおりです - -* このページの右上にある左右の矢印（**<** | **>**）を使用する -* キーボードの左（◀️）と右（▶️）カーソルキーを使用する - {{% /notice %}} +* **LangChain** と **LangGraph** で構築された Agentic AI アプリケーションの**アーキテクチャ**を確認します。 +* Agentic AI アプリケーションをデプロイし、**OpenTelemetry** で**インストルメンテーション**する演習を行います。 +* Splunk Observability Cloud で**メトリクス、トレース、ログ**を使用してエージェントのパフォーマンスを把握する方法を探索します。 +* Agentic AI アプリケーションを変更して**ツールコール**と**エージェント**を使用する演習を行います。 +* アプリケーションに**品質の問題**を追加し、**セマンティック品質評価**を使用して Splunk Observability Cloud で検出する演習を行います。 +* アプリケーションに **AI Defense インストルメンテーション**と**セキュリティリスク**を追加し、Splunk Observability Cloud で検出する演習を行います。 diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/_index.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/_index.md index 8b1a9dccd0..9398e51523 100644 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/_index.md +++ b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/_index.md @@ -1,6 +1,8 @@ --- title: OpenTelemetry Collector ワークショップ weight: 3 +time: 2 hours 15 minutes +description: OpenTelemetry Collector を深く学ぶ2部構成のワークショップです。レシーバー、プロセッサー、エクスポーターの基礎から始め、実践的なシナリオを通じてエージェントおよびゲートウェイの設定をゼロから構築します。 --- {{% children type="card" depth="1" description="true" %}} diff --git a/content/ja/ninja-workshops/8-docker-k8s-otel/_index.md b/content/ja/ninja-workshops/8-docker-k8s-otel/_index.md index 59cf5aeee3..c09a15a67d 100644 --- a/content/ja/ninja-workshops/8-docker-k8s-otel/_index.md +++ b/content/ja/ninja-workshops/8-docker-k8s-otel/_index.md @@ -1,24 +1,19 @@ --- -title: OpenTelemetry、Docker、K8sを実践で学ぶ -linkTitle: OpenTelemetry、Docker、K8sを実践で学ぶ +title: Hands-On OpenTelemetry, Docker, and K8s +linkTitle: Hands-On OpenTelemetry, Docker, and K8s weight: 8 archetype: chapter time: 2 minutes authors: ["Derek Mitchell"] -description: このワークショップでは、これらの概念を説明するためにシンプルな.NETアプリケーションを使用します。さあ、始めましょう！ワークショップの終わりまでに、OpenTelemetryを使用した.NETアプリケーションの計装の実践経験を積み、そのアプリケーションのDocker化およびKubernetesへのデプロイを行います。また、Helmを使用したOpenTelemetryコレクターのデプロイ、コレクター設定のカスタマイズ、コレクター設定の問題のトラブルシューティングの経験も得られます。 +description: このハンズオンワークショップでは、OpenTelemetry を使用した .NET アプリケーションの計装、Docker によるコンテナ化、Kubernetes へのデプロイについて学びます。Helm を使用した OpenTelemetry Collector のデプロイと設定、および一般的な設定問題のトラブルシューティングを習得します。 draft: false hidden: false --- -このワークショップでは、以下の項目について実践経験を積むことができます +このワークショップでは、以下の内容をハンズオンで体験します: -- LinuxおよびKubernetes環境で、SplunkディストリビューションのOpenTelemetry .NETを使用してコレクターのデプロイと.NETアプリケーションの計装を実践します。 -- .NETアプリケーションの「Docker化」、Dockerでの実行、そしてSplunk OpenTelemetry計装の追加を実践します。 -- Helmを使用したK8s環境でのSplunkディストロのコレクターのデプロイを実践します。その後、コレクター設定をカスタマイズし、問題のトラブルシューティングを行います。 +* Linux および Kubernetes 環境で、Splunk distribution of OpenTelemetry .NET を使用した Collector のデプロイと .NET アプリケーションの計装を実践します。 +* .NET アプリケーションの「Docker 化」、Docker での実行、そして Splunk OpenTelemetry 計装の追加を実践します。 +* Helm を使用して K8s 環境に Splunk distro of the Collector をデプロイする方法を実践します。その後、Collector の設定をカスタマイズし、問題のトラブルシューティングを行います。 -{{% notice title="Tip" style="primary" icon="lightbulb" %}} -このワークショップを最も簡単にナビゲートする方法は以下を使用することです - -- このページの右上にある左右の矢印（**<** | **>**） -- キーボードの左（◀️）と右（▶️）のカーソルキー - {{% /notice %}} +このワークショップでは、シンプルな .NET アプリケーションを使用してこれらの概念を説明します。それでは始めましょう！ diff --git a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/_index.md b/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/_index.md index e0e123b6d2..c8e9efee16 100644 --- a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/_index.md +++ b/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/_index.md @@ -1,28 +1,21 @@ --- -title: O11y Cloud で問題を解決する -linkTitle: O11y Cloud で問題を解決する +title: Solving Problems with O11y Cloud +linkTitle: Solving Problems with O11y Cloud weight: 9 archetype: chapter time: 2 minutes authors: ["Derek Mitchell"] -description: OpenTelemetry Collector のデプロイと設定、OpenTelemetry によるアプリケーションの計装、Troubleshooting MetricSets と Tag Spotlight を活用した Splunk Observability Cloud でのパフォーマンス問題の特定と解決方法を学びます。 +description: OpenTelemetry Collector のデプロイと設定、OpenTelemetry によるアプリケーションのインストルメンテーション、Troubleshooting MetricSets と Tag Spotlight を活用した Splunk Observability Cloud でのパフォーマンス問題の特定と解決方法を学びます。 draft: false hidden: false --- -このワークショップでは、以下の内容をハンズオン形式で体験します： +このワークショップでは、以下の内容をハンズオン形式で体験します -* **OpenTelemetry Collector** をデプロイし、Collectorの設定をカスタマイズする -* アプリケーションをデプロイし、**OpenTelemetry** で計装する -* **OpenTelemetry SDK** を使用してタグがどのようにキャプチャされるかを確認する -* **Troubleshooting MetricSet** を作成する -* **Tag Spotlight** を使用して問題をトラブルシューティングし、根本原因を特定する +* **OpenTelemetry Collector** のデプロイとコレクター設定のカスタマイズ +* アプリケーションのデプロイと **OpenTelemetry** によるインストルメンテーション +* **OpenTelemetry SDK** を使用したタグのキャプチャ方法の確認 +* **Troubleshooting MetricSet** の作成 +* **Tag Spotlight** を使用した問題のトラブルシューティングと根本原因の特定 それでは始めましょう！ - -{{% notice title="Tip" style="primary" icon="lightbulb" %}} -このワークショップを最も簡単にナビゲートする方法は以下の通りです： - -* このページの右上にある左右の矢印（**<** | **>**）を使用する -* キーボードの左（◀️）および右（▶️）カーソルキーを使用する - {{% /notice %}} diff --git a/content/ja/ninja-workshops/_index.md b/content/ja/ninja-workshops/_index.md index 03da7aee00..f9bb4b8760 100644 --- a/content/ja/ninja-workshops/_index.md +++ b/content/ja/ninja-workshops/_index.md @@ -1,8 +1,11 @@ --- -title: Splunk4Ninjas Workshops +title: Splunk4*Ninjas*. menuPost: " " weight: 2 -description: The following workshops require Ninja skills, wax on, wax off. +description: Splunk Observability Cloud に慣れている方向けの上級ワークショップです。自動検出、AI 支援によるトラブルシューティング、OpenTelemetry の内部構造、インジェスト処理について深く学びます。 +params: + images: + - images/s4n-featured.png --- -{{% children type="card" depth="1" description="true" %}} +{{% children depth="1" type="card" description="true" %}} diff --git a/content/ja/resources/_index.md b/content/ja/resources/_index.md index 3946812afd..025cdca1bb 100644 --- a/content/ja/resources/_index.md +++ b/content/ja/resources/_index.md @@ -1,6 +1,10 @@ --- title: リソース -weight: 20 +weight: 4 +description: Splunk Observability Cloud をより活用するためのコンセプト、規約、およびFAQです。 +params: + images: + - ../images/featured-resources.png --- -{{%children type="card" description="true" %}} +{{% children type="card" description="true" %}} diff --git a/content/ja/resources/local-hosting/multipass.md b/content/ja/resources/local-hosting/multipass.md new file mode 100644 index 0000000000..6ddafd59fc --- /dev/null +++ b/content/ja/resources/local-hosting/multipass.md @@ -0,0 +1,164 @@ +--- +title: Multipass +weight: 1 +description: Multipass を使用したローカルホスティング環境の作成方法 - Windows/Linux/Mac(Intel) +--- + +お使いのオペレーティングシステムに [Multipass](https://multipass.run/) と Terraform をインストールします。Mac (Intel) では、[Homebrew](https://brew.sh/) を使用してインストールすることもできます。例 + +```text +brew install multipass terraform jq +``` + +ワークショップリポジトリをクローンします + +```bash +git clone https://github.com/splunk/observability-workshop +``` + +Multipass ディレクトリに移動します + +```bash +cd observability-workshop/local-hosting/multipass +``` + +Log Observer Connect: + +独自の Splunk Observability Cloud Suite Org や Splunk インスタンスを使用する場合は、新しい **Log Observer Connect** 接続を作成する必要があります。 +[Splunk Cloud](https://docs.splunk.com/observability/en/logs/scp.html#logs-scp) または [Splunk Enterprize](https://docs.splunk.com/observability/en/logs/set-up-logconnect.html) の[ドキュメント](https://docs.splunk.com/observability/en/logs/lo-connect-landing.html)に記載されている手順に従ってください。 + +独自の **Log Observer Connect** 接続を実行するための追加要件は以下のとおりです + +- **splunk4rookies-workshop** というインデックスを作成します +- **Log Observer Connect** 接続で使用されるサービスアカウントユーザーが **splunk4rookies-workshop** インデックスにアクセスできることを確認します（すべてのワークショップログデータはこのインデックスに送信されるため、他のすべてのインデックスを削除できます）。 + +Terraform を初期化します + +{{< tabs >}} +{{% tab title="Command" %}} + +```bash +terraform init -upgrade +``` + +{{< /tab >}} +{{< tab title="Example Output" >}} + +```text +Initializing the backend... + +Initializing provider plugins... +- Finding latest version of hashicorp/random... +- Finding latest version of hashicorp/local... +- Finding larstobi/multipass versions matching "~> 1.4.1"... +- Installing hashicorp/random v3.5.1... +- Installed hashicorp/random v3.5.1 (signed by HashiCorp) +- Installing hashicorp/local v2.4.0... +- Installed hashicorp/local v2.4.0 (signed by HashiCorp) +- Installing larstobi/multipass v1.4.2... +- Installed larstobi/multipass v1.4.2 (self-signed, key ID 797707331BF3549C) +``` + +{{< /tab >}} +{{< /tabs >}} + +Terraform 変数ファイルを作成します。変数はファイル `terrform.tfvars` に保存されます。テンプレート `terraform.tfvars.template` が提供されているので、コピーして編集します + +```bash +cp terraform.tfvars.template terraform.tfvars +``` + +以下の Terraform 変数が必要です + +- `swipe_id`: インスタンスの [SWiPE ID](https://swipe.splunk.com/) +- `splunk_index`: ログの送信先の Splunk Index。デフォルトは `splunk4rookies-workshop` です。 + +インスタンスタイプ変数 + +- `splunk_presetup`: 事前設定済みのインスタンスを提供します（OTel Collector と Online Boutique が RUM 有効でデプロイされます）。デフォルトは `false` です。 +- `splunk_diab`: Demo-in-a-Box をインストールして実行します。デフォルトは `false` です。 +- `tagging_workshop`: Tagging Workshop をインストールして設定します。デフォルトは `false` です。 +- `otel_demo` : OpenTelemetry Astronomy Shop Demo をインストールして設定します。これには `splunk_presetup` が `false` に設定されている必要があります。デフォルトは `false` です。 + +オプションの詳細変数 + +- `wsversion`: ワークショップの開発作業中の場合は `main` に設定します。それ以外の場合は省略できます。 +- `architecture`: 正しいアーキテクチャ（`arm64` または `amd64`）に設定します。デフォルトは Apple Silicon に適した `arm64` です。 + +`terraform plan` を実行してすべての設定が正しいことを確認します。問題がなければ `terraform apply` を実行してインスタンスを作成します。 + +{{< tabs >}} +{{% tab title="Command" %}} + +```bash +terraform apply +``` + +{{< /tab >}} +{{% tab title="Example Output" %}} + +``` text +random_string.hostname: Creating... +random_string.hostname: Creation complete after 0s [id=cynu] +local_file.user_data: Creating... +local_file.user_data: Creation complete after 0s [id=46a5c50e396a1a7820c3999c131a09214db903dd] +multipass_instance.ubuntu: Creating... +multipass_instance.ubuntu: Still creating... [10s elapsed] +multipass_instance.ubuntu: Still creating... [20s elapsed] +... +multipass_instance.ubuntu: Still creating... [1m30s elapsed] +multipass_instance.ubuntu: Creation complete after 1m38s [name=cynu] +data.multipass_instance.ubuntu: Reading... +data.multipass_instance.ubuntu: Read complete after 1s [name=cynu] + +Apply complete! Resources: 3 added, 0 changed, 0 destroyed. + +Outputs: + +instance_details = [ + { + "image" = "Ubuntu 22.04.2 LTS" + "image_hash" = "345fbbb6ec82 (Ubuntu 22.04 LTS)" + "ipv4" = "192.168.205.185" + "name" = "cynu" + "state" = "Running" + }, +] +``` + +{{% /tab %}} +{{< /tabs >}} + +インスタンスが正常に作成されたら（数分かかる場合があります）、上記の出力に表示された `name` を使用してインスタンスに `exec` で接続します。Multipass インスタンスのパスワードは `Splunk123!` です。 + +{{< tabs >}} +{{% tab title="Command" %}} + +```bash +multipass exec cynu -- su -l splunk +``` + +{{< /tab >}} +{{% tab title="Example Output" %}} + +```text +$ multipass exec kdhl -- su -l splunk +Password: +Waiting for cloud-init status... +Your instance is ready! +``` + +{{% /tab %}} +{{< /tabs >}} + +インスタンスを検証します + +```bash +kubectl version --output=yaml +``` + +インスタンスを削除するには、まずインスタンスから退出し、次のコマンドを実行します + +```bash +terraform destroy +``` diff --git a/content/ja/resources/local-hosting/orbstack.md b/content/ja/resources/local-hosting/orbstack.md new file mode 100644 index 0000000000..09105cb58f --- /dev/null +++ b/content/ja/resources/local-hosting/orbstack.md @@ -0,0 +1,53 @@ +--- +title: OrbStack +weight: 2 +description: OrbStack を使用してローカルホスティング環境を作成する方法 - Mac (Apple Silicon) +--- + +OrbStack と jq をインストールします: + +``` bash +brew install orbstack jq +``` + +ワークショップリポジトリをクローンします: + +``` bash +git clone https://github.com/splunk/observability-workshop +``` + +OrbStack ディレクトリに移動します: + +```bash +cd observability-workshop/local-hosting/orbstack +``` + +スクリプトを実行し、インスタンス名と [SWiPE ID](https://swipe.splunk.show) を指定します（例）: + +``` bash +./start.sh my-instance 12345678 +``` + +インスタンスが正常に作成されると（数分かかる場合があります）、自動的にインスタンスにログインされます。終了した場合は、以下のコマンドで SSH 接続できます（`` をインスタンス名に置き換えてください）: + +```bash +ssh splunk@@orb +``` + +シェルに入ったら、以下のコマンドを実行してインスタンスの準備ができていることを確認できます: + +```bash +kubectl version --output=yaml +``` + +インスタンスの IP アドレスを取得するには、以下のコマンドを実行します: + +```bash +ifconfig eth0 +``` + +インスタンスを削除するには、以下のコマンドを実行します: + +```bash +orb delete my-instance +``` diff --git a/content/ja/resources/local-hosting/proxmox.md b/content/ja/resources/local-hosting/proxmox.md new file mode 100644 index 0000000000..a71bbb1d36 --- /dev/null +++ b/content/ja/resources/local-hosting/proxmox.md @@ -0,0 +1,140 @@ +--- +title: Proxmox +weight: 3 +description: Proxmox VE でローカルホスティング環境を作成する方法を学びます +--- + +## Proxmox ワークショップインスタンスのセットアップ + +### 概要 + +`ubuntu-cloud-k3d.sh` スクリプトは、Proxmox VE 上に Splunk Observability Workshop VM の作成を自動化します。必要なツールと設定がすべてプリインストールされた、Ubuntu 24.04 cloud-init ベースの完全な VM を作成します。 + +#### 前提条件 + +- 管理者アクセス権を持つ Proxmox VE クラスター +- クラウドイメージとパッケージのダウンロードに必要なインターネット接続 +- 使用可能な VM ID 範囲とストレージ容量 +- ワークショップアクセス用の有効な SWiPE ID +- **ローカルストレージで Snippets が有効であること** - cloud-init 設定ファイルに必要です。有効にするには + 1. Proxmox Web UI で **Datacenter → Storage → local** に移動します + 2. **Edit** をクリックします + 3. **Content** で、リストに **Snippets** を追加します + 4. **OK** をクリックします + +#### クイックスタート + +Proxmox ホストでスクリプトを直接実行します + +`k3d` スクリプト + +```bash +bash -c "$(curl -fsSL https://raw.githubusercontent.com/splunk/observability-workshop/refs/heads/main/local-hosting/proxmox/ubuntu-cloud-k3d.sh)" +``` + +`k3s` スクリプト（**レガシー**） + +```bash +bash -c "$(curl -fsSL https://raw.githubusercontent.com/splunk/observability-workshop/refs/heads/main/local-hosting/proxmox/ubuntu-cloud-k3s.sh)" +``` + +### スクリプトの動作 + +#### 1. 初期セットアップ + +- パッケージリポジトリを更新し、必要なツール（`jq`、`curl`）をインストールします +- ユーザー確認と SWiPE ID 入力のためのインタラクティブなプロンプトを表示します + +#### 2. 認証と設定 + +- Splunk ワークショップ API に対して SWiPE ID を検証します +- ワークショップトークンと設定（REALM、RUM_TOKEN、INGEST_TOKEN など）を取得します +- 一意の VM ID とホスト名を生成します + +#### 3. VM の作成 + +- Ubuntu 24.04 Noble クラウドイメージをダウンロードします +- ディスクを 40GB にリサイズします +- 以下の仕様で Proxmox VM を作成します + - **メモリ**: 16GB RAM + - **CPU**: 4 コア（ホスト CPU タイプ） + - **ストレージ**: `local-lvm` ストレージを使用 + - **ネットワーク**: DHCP で `vmbr0` にブリッジ接続 + - **ブート**: cloud-init サポート付き UEFI + +#### 4. ソフトウェアのインストール + +cloud-init 設定により、以下が自動的にインストールされます + +- **コンテナツール**: Docker, Docker Compose +- **Kubernetes**: K3s, kubectl, Helm, K9s +- **開発ツール**: OpenJDK 17, Maven, Python3, Git +- **インフラストラクチャ**: Terraform, Ansible +- **モニタリング**: Chaos Mesh + +#### 5. ワークショップコンテンツ + +- Splunk Observability Workshop の資料をダウンロードします +- ワークショップトークンを使用して Kubernetes シークレットを設定します +- プライベートコンテナレジストリを設定します +- デモアプリケーションとコンテンツを準備します + +### VM の仕様 + +- **OS**: Ubuntu 24.04 LTS (Noble) +- **メモリ**: 16GB RAM +- **CPU**: 4 コア +- **ディスク**: 40GB（拡張可能） +- **ユーザー**: `splunk` / `Splunk123!` +- **SSH**: パスワード認証が有効 + +### 環境変数 + +スクリプトは VM 内で以下の環境変数を設定します + +- `RUM_TOKEN`: Real User Monitoring トークン +- `ACCESS_TOKEN`: データ取り込みトークン +- `API_TOKEN`: Splunk API トークン +- `HEC_TOKEN`: HTTP Event Collector トークン +- `HEC_URL`: HEC エンドポイント URL +- `REALM`: Splunk レルム +- `INSTANCE`: 一意のホスト名 +- `CLUSTER_NAME`: Kubernetes クラスター名 + +### VM へのアクセス + +1. VM の作成と起動が完了するまで待ちます（5〜10 分） +2. Proxmox コンソールまたは DHCP ログで VM の IP アドレスを確認します +3. VM に SSH 接続します + + ```bash + ssh splunk@ + # Password: Splunk123! + ``` + +### VM 内で便利なコマンド + +```bash +# Check Kubernetes status +kubectl get nodes + +# Access Kubernetes dashboard +k9s + +# View workshop materials +ls ~/workshop/ + +# Check environment variables +env | grep -E "(TOKEN|REALM)" +``` + +### トラブルシューティング + +- **無効な SWiPE ID**: ワークショップの登録と ID を確認してください +- **VM の作成に失敗**: Proxmox のストレージ容量と権限を確認してください +- **ネットワークの問題**: `vmbr0` ブリッジが正しく設定されていることを確認してください +- **デプロイが遅い**: cloud-init がすべてのインストールを完了するまで追加の時間を確保してください + +### タグ + +作成された VM には次のタグが付与されます: `o11y-workshop`, `noble`, `k3d` diff --git a/content/ja/scenarios/_index.md b/content/ja/scenarios/_index.md new file mode 100644 index 0000000000..9fc94ff971 --- /dev/null +++ b/content/ja/scenarios/_index.md @@ -0,0 +1,9 @@ +--- +title: シナリオ +weight: 3 +hidden: false +description: Splunk Observability Cloud を具体的なユースケースに対応させた実践的なシナリオ — マイクロサービスのデバッグ、クラウド監視の最適化、エンドユーザーエクスペリエンスの改善、ネットワークイベントの相関分析。 +params: + images: + - ../images/featured-scenarios.jpg +--- diff --git a/content/ja/scenarios/debug-problems/_index.md b/content/ja/scenarios/debug-problems/_index.md new file mode 100644 index 0000000000..5527479c0e --- /dev/null +++ b/content/ja/scenarios/debug-problems/_index.md @@ -0,0 +1,9 @@ +--- +title: マイクロサービスの問題をデバッグする +linkTitle: マイクロサービスの問題をデバッグする +weight: 3 +description: 計画的または予期しない変更がマイクロサービスアプリケーションを壊した場合に、トレース、プロファイル、タグを使用して根本原因を特定します。 +time: 45 minutes +--- + +{{% children description="true" type="card" %}} diff --git a/content/ja/scenarios/debug-problems/profiling/_index.md b/content/ja/scenarios/debug-problems/profiling/_index.md new file mode 100644 index 0000000000..6ad2a7bae4 --- /dev/null +++ b/content/ja/scenarios/debug-problems/profiling/_index.md @@ -0,0 +1,29 @@ +--- +title: Profiling Workshop +linkTitle: Profiling Workshop +weight: 3 +archetype: chapter +time: 2 minutes +authors: ["Derek Mitchell"] +description: このワークショップでは、Database Query Performance と AlwaysOn Profiling を使用して、エンジニアがマイクロサービスの問題をデバッグするために必要な時間を短縮する方法を紹介します。 + +--- + +**Service Maps** と **Traces** は、問題がどのサービスに存在するかを特定する上で非常に有用です。また、関連するログデータは、そのサービスで問題が発生している理由について詳細な情報を提供します。 + +しかし、エンジニアは自分のサービスで発生している問題をデバッグするために、さらに深く掘り下げる必要がある場合があります。 + +ここで、Splunk の **AlwaysOn Profiling** や **Database Query Performance** などの機能が役立ちます。 + +**AlwaysOn Profiling** はスタックトレースを継続的に収集し、コードのどの行が最も多くの CPU とメモリを消費しているかを発見できるようにします。 + +また、**Database Query Performance** は、長時間実行されている、最適化されていない、または負荷の高いクエリを素早く特定し、それらが引き起こしている可能性のある問題を軽減できます。 + +このワークショップでは、以下の内容を学びます: + +* パフォーマンスの問題が複数あるアプリケーションをデバッグする方法。 +* **Database Query Performance** を使用して、アプリケーションのパフォーマンスに影響を与える低速なクエリを見つける方法。 +* **AlwaysOn Profiling** を有効にし、最も多くの CPU とメモリを消費しているコードを見つける方法。 +* **Splunk Observability Cloud** からの調査結果に基づいて修正を適用し、結果を検証する方法。 + +このワークショップでは、Kubernetes でホストされている `The Door Game` という Java ベースのアプリケーションを使用します。それでは始めましょう！ diff --git a/content/ja/scenarios/debug-problems/tagging/_index.md b/content/ja/scenarios/debug-problems/tagging/_index.md new file mode 100644 index 0000000000..292ed5db0e --- /dev/null +++ b/content/ja/scenarios/debug-problems/tagging/_index.md @@ -0,0 +1,24 @@ +--- +title: Tagging Workshop +linkTitle: Tagging Workshop +weight: 2 +archetype: chapter +time: 2 minutes +authors: ["Derek Mitchell"] +description: このワークショップでは、タグを使用して SRE がサービス間の問題を特定するために必要な時間を短縮し、どのチームに対応を依頼すべきかを把握し、エンジニアリングチームがデバッグを迅速に開始できるコンテキストを提供する方法を紹介します。 + +--- + +**Splunk Observability Cloud** には、SRE がサービス間の問題を特定するために必要な時間を大幅に短縮する強力な機能が含まれています。これにより、どのチームにトラブルシューティングを依頼すべきかを把握し、エンジニアリングチームがデバッグを迅速に開始できるコンテキストを提供できます。 + +これらの機能を活用するには、アプリケーションのトレースにタグを含める必要があります。しかし、どのタグが最も価値があるのか、そしてどのようにタグをキャプチャすればよいのでしょうか？ + +このワークショップでは、以下の内容を探ります + +* **タグ**とは何か、そしてなぜタグがアプリケーションのオブザーバビリティを実現する上で非常に重要な要素なのか。 +* [**OpenTelemetry**](https://opentelemetry.io) を使用して、アプリケーションから関心のあるタグをキャプチャする方法。 +* **Splunk Observability Cloud** でタグをインデックス化する方法、および **Troubleshooting MetricSets** と **Monitoring MetricSets** の違い。 +* **Splunk Observability Cloud** でタグを活用し、**Tag Spotlight** と **Dynamic Service Map** 機能を使って「未知の未知」を発見する方法。 +* アラートとダッシュボードにタグを活用する方法。 + +このワークショップでは、シンプルなマイクロサービスベースのアプリケーションを使用してこれらの概念を説明します。それでは始めましょう！ diff --git a/content/ja/scenarios/isovalent-cilium-integration/1-overview/_index.md b/content/ja/scenarios/isovalent-cilium-integration/1-overview/_index.md new file mode 100644 index 0000000000..e433fe257e --- /dev/null +++ b/content/ja/scenarios/isovalent-cilium-integration/1-overview/_index.md @@ -0,0 +1,89 @@ +--- +title: 概要 +weight: 1 +--- + +## Isovalent Enterprise Platform とは？ + +Isovalent Enterprise Platform は、eBPF (Extended Berkeley Packet Filter) 技術に基づいて構築された3つのコアコンポーネントで構成されています + +### Cilium + +#### クラウドネイティブ CNI とネットワークセキュリティ + +- Kubernetes 向けの eBPF ベースのネットワーキングとセキュリティ +- kube-proxy を高性能な eBPF データパスに置き換え +- AWS ENI モードのネイティブサポート（Pod が VPC IP アドレスを取得） +- L3-L7 でのネットワークポリシーの適用 +- 透過的な暗号化とロードバランシング + +### Hubble + +#### ネットワークオブザーバビリティ + +- Cilium の eBPF 可視性の上に構築 +- リアルタイムのネットワークフロー監視 +- L7 プロトコルの可視性（HTTP、DNS、gRPC、Kafka） +- フローのエクスポートと履歴データストレージ（Timescape） +- ポート 9965 でメトリクスを公開 + +### Tetragon + +#### ランタイムセキュリティとオブザーバビリティ + +- eBPF ベースのランタイムセキュリティ +- プロセス実行の監視 +- システムコールのトレース +- ファイルアクセスの追跡 +- ポート 2112 でのセキュリティイベントメトリクス + +## アーキテクチャ + +{{< mermaid >}} +graph TB + subgraph AWS["Amazon Web Services"] + subgraph EKS["EKS Cluster"] + subgraph Node["Worker Node"] + CA["Cilium Agent:9962"] + CE["Cilium Envoy:9964"] + HA["Hubble:9965"] + TE["Tetragon:2112"] + OC["OTel Collector"] + end + CO["Cilium Operator:9963"] + HR["Hubble Relay"] + end + end + subgraph Splunk["Splunk Observability Cloud"] + IM["Infrastructure Monitoring"] + DB["Dashboards"] + end + CA -.->|"Scrape"| OC + CE -.->|"Scrape"| OC + HA -.->|"Scrape"| OC + TE -.->|"Scrape"| OC + CO -.->|"Scrape"| OC + OC ==>|"OTLP/HTTP"| IM + IM --> DB +{{< /mermaid >}} + +## 主要コンポーネント + +| コンポーネント | サービス名 | ポート | 用途 | +| --------- | ------------ | ---- | ------- | +| Cilium Agent | cilium-agent | `9962` | CNI、ネットワークポリシー、eBPF プログラム | +| Cilium Envoy | cilium-envoy | `9964` | HTTP、gRPC 用の L7 プロキシ | +| Cilium Operator | cilium-operator | `9963` | クラスタ全体のオペレーション | +| Hubble | hubble-metrics | `9965` | ネットワークフローメトリクス | +| Tetragon | tetragon | `2112` | ランタイムセキュリティメトリクス | + +## eBPF のメリット + +- **高性能**: 最小限のオーバーヘッドで Linux カーネル内で実行されます +- **安全性**: ベリファイアがプログラムの安全な実行を保証します +- **柔軟性**: カーネルモジュールなしで動的なインストルメンテーションが可能です +- **可視性**: ネットワークとシステムの動作に対する深い洞察を提供します + +{{% notice title="注意" style="info" %}} +この統合により、従来の CNI プラグインでは不可能なレベルで Kubernetes ネットワーキングの可視性が提供されます。 +{{% /notice %}} diff --git a/content/ja/scenarios/isovalent-cilium-integration/2-prerequisites/_index.md b/content/ja/scenarios/isovalent-cilium-integration/2-prerequisites/_index.md new file mode 100644 index 0000000000..b186eea67f --- /dev/null +++ b/content/ja/scenarios/isovalent-cilium-integration/2-prerequisites/_index.md @@ -0,0 +1,97 @@ +--- +title: 前提条件 +weight: 2 +--- + +## 必要なツール + +このワークショップを開始する前に、以下のツールがインストールされていることを確認してください: + +### AWS CLI + +```bash +# Check installation +aws --version + +# Should output: aws-cli/2.x.x or higher +``` + +### kubectl + +```bash +# Check installation +kubectl version --client + +# Should output: Client Version: v1.28.0 or higher +``` + +### eksctl + +```bash +# Check installation +eksctl version + +# Should output: 0.150.0 or higher +``` + +### Helm + +```bash +# Check installation +helm version + +# Should output: version.BuildInfo{Version:"v3.x.x"} +``` + +## AWS の要件 + +- 以下を作成する権限を持つ AWS アカウント: + - EKS クラスター + - VPC とサブネット + - EC2 インスタンス + - IAM ロールとポリシー + - Elastic Network Interfaces +- 認証情報が設定された AWS CLI（`aws configure`） + +## Splunk Observability Cloud + +以下が必要です: + +- Splunk Observability Cloud アカウント +- インジェスト権限を持つ **Access Token** +- **Realm** 識別子（例: us1, us2, eu0） + +{{% notice title="Splunk 認証情報の取得" style="tip" %}} +Splunk Observability Cloud で: + +1. **Settings** → **Access Tokens** に移動します +2. **Ingest** 権限を持つ新しいトークンを作成します +3. URL からリアルムを確認します: `https://app..signalfx.com` +{{% /notice %}} + +## コストに関する考慮事項 + +### AWS コスト（概算） + +- **EKS Control Plane**: 約 $73/月 +- **EC2 Nodes (2x m5.xlarge)**: 約 $280/月 +- **Data Transfer**: 変動あり +- **EBS Volumes**: 約 $20/月 + +**推定合計**: ラボ環境で約 $380-400/月 + +### Splunk コスト + +- メトリクス量（DPM - Data Points per Minute）に基づきます +- テスト用の無料トライアルが利用可能です + +{{% notice title="警告" style="warning" %}} +継続的な課金を避けるため、ワークショップ完了後にリソースをクリーンアップすることを忘れないでください。 +{{% /notice %}} + +## 所要時間の目安 + +- **EKS クラスター作成**: 15〜20 分 +- **Cilium インストール**: 10〜15 分 +- **インテグレーション設定**: 10 分 +- **合計**: 約 90 分 diff --git a/content/ja/scenarios/isovalent-cilium-integration/3-eks-setup/_index.md b/content/ja/scenarios/isovalent-cilium-integration/3-eks-setup/_index.md new file mode 100644 index 0000000000..2c3b02375f --- /dev/null +++ b/content/ja/scenarios/isovalent-cilium-integration/3-eks-setup/_index.md @@ -0,0 +1,96 @@ +--- +title: EKS セットアップ +weight: 3 +--- + +## ステップ 1: Helm リポジトリの追加 + +必要な Helm リポジトリを追加します: + +```bash +# Add Isovalent Helm repository +helm repo add isovalent https://helm.isovalent.com + +# Add Splunk OpenTelemetry Collector Helm repository +helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart + +# Update Helm repositories +helm repo update +``` + +## ステップ 2: EKS クラスター構成の作成 + +`cluster.yaml` という名前のファイルを作成します: + +```yaml +apiVersion: eksctl.io/v1alpha5 +kind: ClusterConfig +metadata: + name: isovalent-demo + region: us-east-1 + version: "1.30" +iam: + withOIDC: true +addonsConfig: + disableDefaultAddons: true +addons: +- name: coredns +``` + +**主な構成の詳細:** + +- `disableDefaultAddons: true` - AWS VPC CNI と kube-proxy を無効にします（Cilium が両方を置き換えます） +- `withOIDC: true` - サービスアカウント用の IAM ロールを有効にします（Cilium が ENI を管理するために必要です） +- `coredns` アドオンは DNS 解決に必要なため保持されます + +{{% notice title="デフォルトアドオンを無効にする理由" style="info" %}} +Cilium は eBPF を使用した独自の CNI 実装を提供しており、デフォルトの AWS VPC CNI よりも高性能です。デフォルトを無効にすることで、競合を回避し、Cilium にすべてのネットワーキングを処理させることができます。 +{{% /notice %}} + +## ステップ 3: EKS クラスターの作成 + +クラスターを作成します（約 15〜20 分かかります）: + +```bash +eksctl create cluster -f cluster.yaml +``` + +クラスターが作成されたことを確認します: + +```bash +# Update kubeconfig +aws eks update-kubeconfig --name isovalent-demo --region us-east-1 + +# Check pods +kubectl get pods -n kube-system +``` + +**期待される出力:** + +- CoreDNS Pod は `Pending` 状態になります（これは正常です - CNI を待機しています） +- ワーカーノードはまだありません + +{{% notice title="注意" style="warning" %}} +CNI プラグインがない場合、Pod は IP アドレスやネットワーク接続を取得できません。CoreDNS は Cilium がインストールされるまで Pending のままになります。 +{{% /notice %}} + +## ステップ 4: Kubernetes API Server エンドポイントの取得 + +Cilium の構成に必要です: + +```bash +aws eks describe-cluster --name isovalent-demo --region us-east-1 \ + --query 'cluster.endpoint' --output text +``` + +このエンドポイントを保存してください - Cilium のインストール手順で使用します。 + +## ステップ 5: Prometheus CRD のインストール + +Cilium はメトリクスに Prometheus ServiceMonitor CRD を使用します: + +```bash +kubectl apply -f https://github.com/prometheus-operator/prometheus-operator/releases/download/v0.68.0/stripped-down-crds.yaml +``` + +{{< checkpoint "EKS クラスターが作成されたので、Cilium、Hubble、Tetragon をインストールする準備が整いました！" >}} diff --git a/content/ja/scenarios/isovalent-cilium-integration/4-cilium-installation/_index.md b/content/ja/scenarios/isovalent-cilium-integration/4-cilium-installation/_index.md index 0f61e8ec79..724d75914d 100644 --- a/content/ja/scenarios/isovalent-cilium-integration/4-cilium-installation/_index.md +++ b/content/ja/scenarios/isovalent-cilium-integration/4-cilium-installation/_index.md @@ -123,31 +123,31 @@ enterprise: ``` {{% notice title="ラベルコンテキストが重要な理由" style="info" %}} -各Hubbleメトリクスの `labelsContext` および `sourceContext`/`destinationContext` パラメータは、メトリクスをどのディメンションで分割するかを制御します。`labelsContext=source_namespace,destination_namespace` を設定すると、すべてのメトリクスにこれら2つのラベルが付与され、カーディナリティの爆発を起こすことなくSplunkでnamespaceによるフィルタリングが可能になります。`workload-name|reserved-identity` のフォールバックチェーンは、利用可能な場合はワークロード名を使用し、利用できない場合はセキュリティIDにフォールバックすることを意味します。 +各 Hubble メトリクスの `labelsContext` と `sourceContext`/`destinationContext` パラメータは、メトリクスがどのディメンションで分割されるかを制御します。`labelsContext=source_namespace,destination_namespace` を設定すると、すべてのメトリクスにこれら2つのラベルが付与され、カーディナリティの爆発なしに Splunk で Namespace によるフィルタリングが可能になります。`workload-name|reserved-identity` のフォールバックチェーンは、ワークロード名が利用可能な場合はそれを使用し、利用できない場合はセキュリティ ID にフォールバックすることを意味します。 {{% /notice %}} ## ステップ 2: Cilium Enterprise のインストール -新しいノードがEKSクラスターに参加すると、そのノードのkubeletはすぐにCNIプラグインを探してネットワーキングをセットアップします。`/etc/cni/net.d/` に存在するCNI設定を読み取り、それを使用してノードを初期化します。**ノードグループを先に作成すると、AWS VPC CNI が最初に到達します** — そして一度ノードが特定のCNIで初期化されると、別のCNIに切り替えるにはノードをドレインして再初期化する必要があります。 +新しいノードが EKS クラスターに参加すると、そのノードの kubelet はすぐにネットワークを設定する CNI プラグインを探し始めます。`/etc/cni/net.d/` にある CNI 設定を読み取り、それを使用してノードを初期化します。**ノードグループを先に作成すると、AWS VPC CNI が最初に配置されます** — 一度あるCNIでノードが初期化されると、別のCNIに切り替えるにはノードのドレインと再初期化が必要になります。 -ノードが存在する前にCiliumをインストールすることで、CiliumのCNI設定が `kube-system` に既に存在し、ノードが起動した瞬間にピックアップされる準備ができていることを保証します。EC2インスタンスが起動すると、CiliumのDaemonSet Podがすぐにスケジュールされ、eBPFプログラムがロードされ、ノードは最初の瞬間からCiliumの制御下で `Ready` 状態になります。 +ノードが存在する前に Cilium をインストールすることで、Cilium の CNI 設定が `kube-system` に既に存在し、ノードが起動した瞬間に使用される準備が整っていることを保証します。EC2 インスタンスが起動すると、Cilium の DaemonSet Pod がすぐにスケジュールされ、eBPF プログラムがロードされ、最初の瞬間から Cilium の制御下でノードが `Ready` 状態になります。 -これは、EKSセットアップのステップ3でクラスターが `disableDefaultAddons: true` で作成された理由でもあります — これがないと、AWS VPC CNIが自動的にインストールされ、Ciliumと競合することになります。 +これは、EKS セットアップのステップ 3 でクラスターを `disableDefaultAddons: true` で作成した理由でもあります — これがないと、AWS VPC CNI が自動的にインストールされ、Cilium と競合します。 -Helmを使用してCiliumをインストールします： +Helm を使用して Cilium をインストールします ```bash helm install cilium isovalent/cilium --version 1.18.4 \ --namespace kube-system -f cilium-enterprise-values.yaml ``` -{{% notice title="Pending状態のジョブは正常です" style="warning" %}} -インストール後、いくつかのジョブがPending状態になっているのが見えます — これは正常です。CiliumのHelmチャートにはHubble用のTLS証明書を生成するジョブが含まれており、そのジョブを実行するにはノードが必要です。次のステップでノードが利用可能になると、自動的に完了します。 +{{% notice title="Pending 状態のジョブは想定通りです" style="warning" %}} +インストール後、一部のジョブが Pending 状態になりますが、これは正常です。Cilium の Helm チャートには Hubble の TLS 証明書を生成するジョブが含まれており、そのジョブは実行するためにノードが必要です。次のステップでノードが利用可能になると自動的に完了します。 {{% /notice %}} ## ステップ 3: ノードグループの作成 -`nodegroup.yaml` という名前のファイルを作成します： +`nodegroup.yaml` という名前のファイルを作成します ```yaml apiVersion: eksctl.io/v1alpha5 @@ -162,7 +162,7 @@ managedNodeGroups: privateNetworking: true ``` -ノードグループを作成します（5〜10分かかります）： +ノードグループを作成します（5〜10分かかります） ```bash eksctl create nodegroup -f nodegroup.yaml @@ -170,7 +170,7 @@ eksctl create nodegroup -f nodegroup.yaml ## ステップ 4: Cilium インストールの確認 -ノードの準備ができたら、すべてのコンポーネントを確認します： +ノードの準備ができたら、すべてのコンポーネントを確認します ```bash # Check nodes @@ -183,18 +183,18 @@ kubectl get pods -n kube-system -l k8s-app=cilium kubectl get pods -n kube-system | grep -E "(cilium|hubble)" ``` -**期待される出力：** +**期待される出力** - 2つのノードが `Ready` 状態 -- Cilium Podが実行中（ノードごとに1つ） -- Hubble relayとtimescapeが実行中 -- Cilium operatorが実行中 +- Cilium Pod が実行中（ノードごとに1つ） +- Hubble relay と timescape が実行中 +- Cilium operator が実行中 ## ステップ 5: 拡張ネットワークオブザーバビリティを備えた Tetragon のインストール -Tetragonはそのままでもランタイムセキュリティとプロセスレベルの可視性を提供します。Splunkとの統合 — 特にNetwork Explorerダッシュボード — には、TCP/UDPソケット統計、RTT、接続イベント、DNSをカーネルレベルで追跡する拡張ネットワークオブザーバビリティモードも有効にする必要があります。 +Tetragon はデフォルトでランタイムセキュリティとプロセスレベルの可視性を提供します。Splunk との統合 — 特に Network Explorer ダッシュボード — には、TCP/UDP ソケット統計、RTT、接続イベント、DNS をカーネルレベルで追跡する拡張ネットワークオブザーバビリティモードも有効にする必要があります。 -`tetragon-network-values.yaml` という名前のファイルを作成します： +`tetragon-network-values.yaml` という名前のファイルを作成します ```yaml # Tetragon configuration with Enhanced Network Observability enabled @@ -255,7 +255,7 @@ tetragonOperator: enabled: true ``` -これらの値でTetragonをインストールします： +以下の values を使用して Tetragon をインストールします ```bash helm install tetragon isovalent/tetragon --version 1.18.0 \ @@ -263,23 +263,23 @@ helm install tetragon isovalent/tetragon --version 1.18.0 \ -f tetragon-network-values.yaml ``` -インストールを確認します： +インストールを確認します ```bash kubectl get pods -n tetragon ``` -**表示される内容：** TetragonはDaemonSet（ノードごとに1つのPod）とオペレーターとして実行されます。 +**表示される内容** Tetragon は DaemonSet（ノードごとに1つの Pod）と operator として実行されます。 {{% notice title="拡張ネットワークオブザーバビリティが追加するもの" style="info" %}} -`layer3.tcp.rtt.enabled: true` を設定すると、TetragonはカーネルのTCPソケット状態にフックし、ラウンドトリップタイム、再送回数、送受信バイト数、セグメント数を含む接続ごとのメトリクスを記録します。これらはSplunkのNetwork Explorerのレイテンシとスループットビューを動かす `tetragon_socket_stats_*` メトリクスに供給されます。これがないとイベントカウントのみが取得されますが、これがあると接続品質データが取得できます。 +`layer3.tcp.rtt.enabled: true` を設定すると、Tetragon はカーネルの TCP ソケット状態にフックし、ラウンドトリップタイム、再送回数、送受信バイト数、セグメント数などの接続ごとのメトリクスを記録します。これらは Splunk の Network Explorer のレイテンシーとスループットのビューを支える `tetragon_socket_stats_*` メトリクスに供給されます。これがないとイベントカウントしか取得できませんが、これがあれば接続品質データを取得できます。 -TracingPolicies（TCP接続追跡、HTTP可視性など）は、上記のHelm valuesで `tetragonOperator.tracingPolicy.enabled: true` が設定されている場合、Tetragon Operatorによって自動的に管理されます。 +TracingPolicy（TCP 接続追跡、HTTP 可視性など）は、上記の Helm values で `tetragonOperator.tracingPolicy.enabled: true` が設定されている場合、Tetragon Operator によって自動的に管理されます。 {{% /notice %}} ## ステップ 6: Cilium DNS Proxy HA のインストール -`cilium-dns-proxy-ha-values.yaml` という名前のファイルを作成します： +`cilium-dns-proxy-ha-values.yaml` という名前のファイルを作成します ```yaml enableCriticalPriorityClass: true @@ -288,19 +288,17 @@ metrics: enabled: true ``` -DNS Proxy HAをインストールします： +DNS Proxy HA をインストールします ```bash helm upgrade -i cilium-dnsproxy isovalent/cilium-dnsproxy --version 1.16.7 \ -n kube-system -f cilium-dns-proxy-ha-values.yaml ``` -確認します： +確認します ```bash kubectl rollout status -n kube-system ds/cilium-dnsproxy --watch ``` -{{% notice title="成功" style="success" %}} -これでCilium CNI、Hubbleオブザーバビリティ、Tetragonセキュリティを備えた完全に機能するEKSクラスターが完成しました！ -{{% /notice %}} +{{< checkpoint "Cilium CNI、Hubble オブザーバビリティ、Tetragon セキュリティを備えた完全に機能する EKS クラスターが完成しました！" >}} diff --git a/content/ja/scenarios/isovalent-cilium-integration/5-splunk-integration/_index.md b/content/ja/scenarios/isovalent-cilium-integration/5-splunk-integration/_index.md index a7c6aeafea..0c9efc1a3d 100644 --- a/content/ja/scenarios/isovalent-cilium-integration/5-splunk-integration/_index.md +++ b/content/ja/scenarios/isovalent-cilium-integration/5-splunk-integration/_index.md @@ -1,14 +1,14 @@ --- -title: Splunk Integration +title: Splunk インテグレーション weight: 5 --- ## 概要 -Splunk OpenTelemetry Collectorは、Prometheusレシーバーを使用してすべてのIsovalentコンポーネントからメトリクスをスクレイプします。各コンポーネントは異なるポートでメトリクスを公開しており、CiliumとHubbleは同じPodを共有しています（ポートが異なるだけです）。そのため、Podアノテーションに依存するのではなく、各コンポーネントに対して個別のレシーバーを設定します。 +Splunk OpenTelemetry Collector は、Prometheus レシーバーを使用してすべての Isovalent コンポーネントからメトリクスをスクレイピングします。各コンポーネントは異なるポートでメトリクスを公開しており、Cilium と Hubble は同じ Pod を共有しているため（ポートのみ異なる）、Pod アノテーションに依存するのではなく、それぞれに個別のレシーバーを設定します。 | コンポーネント | ポート | 提供する情報 | -|-----------|------|------------------| +| --------- | ---- | ---------------- | | Cilium Agent | 9962 | eBPF データパス、ポリシー適用、IPAM、BPF マップ統計 | | Cilium Envoy | 9964 | L7 プロキシメトリクス（HTTP、gRPC） | | Cilium Operator | 9963 | クラスター全体のアイデンティティとエンドポイント管理 | @@ -269,17 +269,17 @@ certmanager: enabled: true ``` -**重要:** 以下を置き換えてください: +**重要:** 以下のプレースホルダーを置き換えてください: -- `` をSplunk Observability Cloudのアクセストークンに -- `` をレルム（例: us1、us2、eu0）に +- `` を Splunk Observability Cloud のアクセストークンに置き換えます +- `` をご利用のリージョンに置き換えます（例: us1、us2、eu0） -{{% notice title="厳格なメトリクス許可リストを使用する理由" style="info" %}} -Ciliumは、ワークロード、名前空間、プロトコルの詳細に関するすべてのラベルの組み合わせを考慮すると、数千のユニークなメトリクスシリーズを出力する可能性があります。`filter/includemetrics` 許可リストがないと、負荷の高いクラスターでは50,000以上のアクティブシリーズが簡単に生成され、Splunkのインジェストに過負荷をかける可能性があります。上記のリストは、CiliumとHubbleのダッシュボードを動作させるために必要なメトリクスと、Network Explorerに必要なTetragonソケット統計を正確に含むようにキュレートされています。後で新しいダッシュボードを追加する場合は、このリストにメトリクスを追加できます。 +{{% notice title="厳密なメトリクス許可リストを使用する理由" style="info" %}} +Cilium は、ワークロード、名前空間、プロトコルの詳細に関するすべてのラベルの組み合わせを考慮すると、数千のユニークなメトリクスシリーズを生成する可能性があります。`filter/includemetrics` 許可リストがない場合、負荷の高いクラスターでは 50,000 以上のアクティブシリーズが容易に生成され、Splunk のインジェストを圧迫する可能性があります。上記のリストは、Cilium および Hubble ダッシュボードを動作させるメトリクスと、Network Explorer に必要な Tetragon ソケット統計を正確に含むように精選されています。新しいダッシュボードを追加する場合は、このリストにメトリクスを追加できます。 {{% /notice %}} -{{% notice title="Tetragonソケット統計で可能になること" style="info" %}} -`tetragon_socket_stats_*` メトリクスは、SplunkのNetwork Explorerで接続ごとのレイテンシとスループット分析を可能にするものです。`srtt_count`/`srtt_sum` は、ワークロードごとの平均TCPラウンドトリップタイムを提供します。`retransmitsegs_total` は、パケットロスと輻輳を表面化します。`txbytes`/`rxbytes` は、接続ごとの帯域幅を示します。これらはAPMや標準のインフラストラクチャメトリクスでは確認できません。 +{{% notice title="Tetragon ソケット統計で可能になること" style="info" %}} +`tetragon_socket_stats_*` メトリクスにより、Splunk の Network Explorer で接続ごとのレイテンシーとスループット分析が可能になります。`srtt_count`/`srtt_sum` はワークロードごとの平均 TCP ラウンドトリップタイムを提供します。`retransmitsegs_total` はパケットロスと輻輳を可視化します。`txbytes`/`rxbytes` は接続ごとの帯域幅を示します。これらの情報は APM や標準的なインフラストラクチャメトリクスでは確認できません。 {{% /notice %}} ## ステップ 2: Splunk OpenTelemetry Collector のインストール @@ -293,7 +293,7 @@ helm upgrade --install splunk-otel-collector \ -f splunk-otel-isovalent.yaml ``` -ロールアウトが完了するまで待ちます: +ロールアウトの完了を待ちます: ```bash kubectl rollout status daemonset/splunk-otel-collector-agent -n otel-splunk --timeout=60s @@ -301,14 +301,12 @@ kubectl rollout status daemonset/splunk-otel-collector-agent -n otel-splunk --ti ## ステップ 3: メトリクス収集の確認 -コレクターがメトリクスをスクレイプしていることを確認します: +コレクターがメトリクスをスクレイピングしていることを確認します: ```bash kubectl logs -n otel-splunk -l app=splunk-otel-collector --tail=100 | grep -i "cilium\|hubble\|tetragon" ``` -各コンポーネントのスクレイプが成功していることを示すログエントリが表示されるはずです。 +各コンポーネントのスクレイピングが正常に行われていることを示すログエントリが表示されるはずです。 -{{% notice title="次のステップ" style="success" %}} -メトリクスがSplunk Observability Cloudに送信されています！ダッシュボードを確認するには、検証に進んでください。 -{{% /notice %}} +{{< checkpoint "メトリクスが Splunk Observability Cloud に送信されています！ダッシュボードを確認するために検証に進んでください。" >}} diff --git a/content/ja/scenarios/isovalent-cilium-integration/6-verification/_index.md b/content/ja/scenarios/isovalent-cilium-integration/6-verification/_index.md new file mode 100644 index 0000000000..9de4abef43 --- /dev/null +++ b/content/ja/scenarios/isovalent-cilium-integration/6-verification/_index.md @@ -0,0 +1,191 @@ +--- +title: 検証 +weight: 6 +--- + +## すべてのコンポーネントの検証 + +すべてが正常に動作していることを確認するために、以下の包括的なチェックを実行します + +```bash +echo "=== Cluster Nodes ===" +kubectl get nodes + +echo -e "\n=== Cilium Components ===" +kubectl get pods -n kube-system -l k8s-app=cilium + +echo -e "\n=== Hubble Components ===" +kubectl get pods -n kube-system | grep hubble + +echo -e "\n=== Tetragon ===" +kubectl get pods -n tetragon + +echo -e "\n=== Splunk OTel Collector ===" +kubectl get pods -n otel-splunk +``` + +**期待される出力** + +- 2つのノードが `Ready` 状態であること +- Cilium Pod：2つが実行中（ノードごとに1つ） +- Hubble relay と timescape：実行中 +- Tetragon Pod：2つが実行中 + operator +- Splunk collector Pod：実行中 + +## メトリクスエンドポイントの検証 + +各コンポーネントからメトリクスにアクセスできることをテストします + +```bash +# Test Cilium metrics +kubectl exec -n kube-system ds/cilium -- curl -s localhost:9962/metrics | head -20 + +# Test Hubble metrics +kubectl exec -n kube-system ds/cilium -- curl -s localhost:9965/metrics | head -20 + +# Test Tetragon metrics +kubectl exec -n tetragon ds/tetragon -- curl -s localhost:2112/metrics | head -20 +``` + +各コマンドは Prometheus 形式のメトリクスを返すはずです。 + +## Splunk Observability Cloud での検証 + +### Infrastructure Navigator の確認 + +1. Splunk Observability Cloud アカウントにログインします +2. **Infrastructure** → **Kubernetes** に移動します +3. クラスターを見つけます`isovalent-demo` +4. クラスターがメトリクスを報告していることを確認します + +### Isovalent メトリクスの検索 + +**Metrics** に移動して以下を検索します + +- `cilium_*` - Cilium ネットワーキングメトリクス +- `hubble_*` - ネットワークフローメトリクス +- `tetragon_*` - ランタイムセキュリティメトリクス + +{{% notice title="ヒント" style="tip" %}} +インストール後、メトリクスが Splunk Observability Cloud に表示されるまで2〜3分かかる場合があります。 +{{% /notice %}} + +## ダッシュボードの表示 + +### カスタムダッシュボードの作成 + +1. **Dashboards** → **Create** に移動します +2. 主要なメトリクスのチャートを追加します + +**Cilium Endpoint State** + +```text +cilium_endpoint_state{cluster="isovalent-demo"} +``` + +**Hubble Flow Processing** + +```text +hubble_flows_processed_total{cluster="isovalent-demo"} +``` + +**Tetragon Events** + +```text +tetragon_dns_total{cluster="isovalent-demo"} +``` + +### クエリの例 + +**DNS Query Rate** + +```text +rate(hubble_dns_queries_total{cluster="isovalent-demo"}[1m]) +``` + +**Dropped Packets** + +```text +sum by (reason) (hubble_drop_total{cluster="isovalent-demo"}) +``` + +**Network Policy Enforcements** + +```text +rate(cilium_policy_l7_total{cluster="isovalent-demo"}[5m]) +``` + +## トラブルシューティング + +### Splunk にメトリクスが表示されない場合 + +メトリクスが表示されない場合 + +1. **コレクターのログを確認します** + + ```bash + kubectl logs -n otel-splunk -l app=splunk-otel-collector --tail=200 + ``` + +2. **スクレイプターゲットを確認します** + + ```bash + kubectl describe configmap -n otel-splunk splunk-otel-collector-otel-agent + ``` + +3. **ネットワーク接続を確認します** + + ```bash + kubectl exec -n otel-splunk -it deployment/splunk-otel-collector -- \ + curl -v https://ingest..signalfx.com + ``` + +### Pod が実行されていない場合 + +Cilium または Tetragon の Pod が実行されていない場合 + +1. **Pod のステータスを確認します** + + ```bash + kubectl describe pod -n kube-system + ``` + +2. **ログを確認します** + + ```bash + kubectl logs -n kube-system + ``` + +3. **ノードの準備状態を確認します** + + ```bash + kubectl get nodes -o wide + ``` + +## クリーンアップ + +すべてのリソースを削除して AWS の課金を回避するには + +```bash +# Delete the OpenTelemetry Collector +helm uninstall splunk-otel-collector -n otel-splunk + +# Delete the EKS cluster (this removes everything) +eksctl delete cluster --name isovalent-demo --region us-east-1 +``` + +{{% notice title="警告" style="warning" %}} +クリーンアップ処理には10〜15分かかります。課金を回避するために、すべてのリソースが削除されたことを確認してください。 +{{% /notice %}} + +## 次のステップ + +インテグレーションが正常に動作するようになったら + +- サンプルアプリケーションをデプロイしてネットワークトラフィックを生成します +- ネットワークポリシーを作成し、適用状況を監視します +- Splunk でドロップされたパケットやセキュリティイベントのアラートを設定します +- Hubble の L7 可視性を使用して HTTP/gRPC トラフィックを調査します +- Tetragon を使用してプロセスの実行とファイルアクセスを監視します + +{{< checkpoint "Isovalent Enterprise Platform と Splunk Observability Cloud のインテグレーションが正常に完了しました！" >}} diff --git a/content/ja/scenarios/isovalent-cilium-integration/7-demo/_index.md b/content/ja/scenarios/isovalent-cilium-integration/7-demo/_index.md index 1463cc2b53..50fe038a25 100644 --- a/content/ja/scenarios/isovalent-cilium-integration/7-demo/_index.md +++ b/content/ja/scenarios/isovalent-cilium-integration/7-demo/_index.md @@ -1,37 +1,37 @@ --- -title: デモ — Isovalent と Splunk を使用した DNS 問題の調査 +title: デモ — Isovalent と Splunk による DNS 問題の調査 linkTitle: デモスクリプト weight: 7 --- ## このデモで示すこと -このデモは、すべての運用チームやプラットフォームチームが経験したことのあるストーリーを語ります。何かが壊れていて、ユーザーが不満を訴えていて、どこから始めればよいかわからない状況です。調査は通常の最初のステップを経由します — APMは問題なさそう、インフラストラクチャも問題なさそう — そしてネットワーク層へとピボットします。そこでIsovalentのHubbleオブザーバビリティがSplunkに流れ込み、本当の問題を明らかにします。それは他のすべてのツールからは完全に見えなかったDNS過負荷です。 +このデモは、すべての運用チームやプラットフォームチームが経験したことのあるストーリーを伝えます。何かが壊れていて、ユーザーが不満を訴えていて、どこから手をつければよいかわからない状況です。調査は通常の最初のステップ — APM は問題なし、インフラも問題なし — を経て、ネットワークレイヤーへと切り替わります。そこで Isovalent の Hubble オブザーバビリティが Splunk に流れ込み、他のすべてのツールでは完全に見えなかった本当の問題、DNS の過負荷を明らかにします。 -アプリケーションは **jobs-app** で、`tenant-jobs` namespaceで実行されるシミュレートされたマルチサービスの採用プラットフォームです。フロントエンド（`recruiter`、`jobposting`）、中央API（`coreapi`）、バックグラウンドデータパイプライン（Kafka + `resumes` + `loader`）、および定期的にインターネットへHTTP呼び出しを行う `crawler` サービスがあります。このcrawlerがこのストーリーの悪役になります。 +アプリケーションは **jobs-app** で、`tenant-jobs` namespace で動作するシミュレートされたマルチサービスの採用プラットフォームです。フロントエンド（`recruiter`、`jobposting`）、中央 API（`coreapi`）、バックグラウンドデータパイプライン（Kafka + `resumes` + `loader`）、そして定期的にインターネットへ HTTP リクエストを行う `crawler` サービスがあります。この crawler がこのストーリーの犯人になります。 {{% notice title="重要なポイント" style="primary" icon="lightbulb" %}} -APMとインフラストラクチャのメトリクスは正常に見えます。根本原因であるDNS過負荷は、アプリケーション層より下に存在するため、SplunkのIsovalent Hubbleダッシュボードを通じてのみ見ることができます。 +APM とインフラメトリクスは正常に見えます。根本原因である DNS の過負荷は、アプリケーションレイヤーの下に存在するため、Splunk 内の Isovalent Hubble ダッシュボードを通じてのみ確認できます。 {{% /notice %}} --- ## 開始前の準備 -これは誰もいない状態で行ってください。デモが始まるときには、クリーンで正常なダッシュボードの前に座っていたいものです — 人々が見ている中でkubectlをいじっているのではなく。 +これは誰も部屋にいない間に行ってください。デモが始まるときには、クリーンで正常なダッシュボードの前に座っている状態にしたいのであって、参加者が見ている前で kubectl を操作している状態は避けたいです。 ### Jobs App のデプロイ -まだ行っていない場合は、[isovalent-demo-jobs-app](https://github.com/isovalent/demo-jobs-app) リポジトリからjobs-app Helm chartをデプロイします。 +まだデプロイしていない場合は、[isovalent-demo-jobs-app](https://github.com/isovalent/demo-jobs-app) リポジトリから jobs-app Helm チャートをデプロイします ```bash helm dependency build . helm upgrade --install jobs-app . --namespace tenant-jobs --create-namespace ``` -### すべてが実行中であることを確認 +### すべてが動作していることの確認 -デモ中に驚かないよう、これらのチェックを実行します。 +デモ中に驚かないよう、以下のチェックを実行します ```bash # Confirm your nodes are healthy @@ -48,12 +48,12 @@ kubectl get pods -n tenant-jobs ``` {{% notice title="重要" style="warning" %}} -続行する前に、すべてのPodが `Running` 状態である必要があります。OTel Collectorが起動していない場合、Splunkにメトリクスが表示されず、デモが成功しません。 +続行する前に、すべての Pod が `Running` 状態である必要があります。OTel Collector が起動していない場合、Splunk にメトリクスが表示されず、デモが成功しません。 {{% /notice %}} -### アプリを正常なベースラインにリセット +### アプリを正常なベースラインにリセットする -crawlerが穏やかで通常のペースで実行されていることを確認します — 1レプリカ、0.5から5秒ごとにクロール： +crawler が穏やかで通常のペースで動作していることを確認します — 1 レプリカ、0.5〜5 秒ごとにクロールします ```bash helm upgrade jobs-app . --namespace tenant-jobs --reuse-values \ @@ -63,11 +63,11 @@ helm upgrade jobs-app . --namespace tenant-jobs --reuse-values \ --set resumes.replicas=1 ``` -その後、**少なくとも 5 分待ちます**。Splunkがクリーンなベースラインを取り込む時間が必要で、これから作成するスパイクが視覚的に明らかになります。これをスキップすると、チャートが明確なストーリーを伝えません。 +その後、**少なくとも 5 分間待ちます**。Splunk がクリーンなベースラインを取り込むのに時間が必要で、これにより作成するスパイクが視覚的に明確になります。これを省略すると、チャートが明確なストーリーを伝えません。 -### 問題を注入 +### 問題の注入 -デモ開始の約5〜10分前（または効果を出すためにデモ中にライブで）、以下を実行します： +デモ開始の約 5〜10 分前（またはデモ中にライブで効果を出すために）、以下を実行します ```bash helm upgrade jobs-app . --namespace tenant-jobs --reuse-values \ @@ -77,110 +77,110 @@ helm upgrade jobs-app . --namespace tenant-jobs --reuse-values \ --set resumes.replicas=2 ``` -これによりcrawlerが1 Podから5にスケールアップし、クロール間隔が0.2〜0.3秒に短縮されます。各crawler Podは `api.github.com` にHTTPリクエストを行い、それらのリクエストごとに最初にDNSルックアップが必要です。5つのPodが毎秒複数回DNSを叩くと、約15〜25のDNSクエリが持続的に発生します — DNSプロキシを飽和させ、応答レイテンシを蓄積させるのに十分な量です。DNSに依存するnamespace内の他のサービスが断続的な障害を経験し始めます。これがまさにチケットに記載されている内容です。 +これにより crawler が 1 Pod から 5 Pod にスケールアップし、クロール間隔が 0.2〜0.3 秒に短縮されます。各 crawler Pod は `api.github.com` に HTTP リクエストを行い、そのリクエストのたびに DNS ルックアップが必要です。5 つの Pod が毎秒複数回 DNS を叩くと、持続的に約 15〜25 DNS クエリ/秒が生成されます。これは DNS プロキシを飽和させ、レスポンスレイテンシーの蓄積を引き起こすのに十分です。namespace 内の DNS に依存する他のサービスが断続的な障害を経験し始めます。これがまさにチケットに書かれている内容です。 --- -## Act 1 — チケットが届く +## Act 1 — チケットの到着 まず状況を描写します。まだ何もクリックする必要はありません — シーンを設定するだけです。 -> *「普通の午後で、ITSM チケットが届きました。jobs アプリケーションチームから、エンドユーザーが recruiter と job posting ページで断続的な 500 エラーを報告していて、過去 15 分ほどでロード時間が明らかに悪化したと言っています。P2 にエスカレートされました。調査しましょう。」* +> *「普通の午後で、ITSM チケットが入ってきます。jobs アプリケーションチームによると、エンドユーザーが recruiter と job posting のページで断続的な 500 エラーを報告しており、過去 15 分ほどでロード時間が著しく悪化しているとのことです。P2 にエスカレートされました。調査しましょう。」* | | | -|---|---| +| - | - | | **チケット** | INC-4072 | -| **優先度** | P2 — 高 | -| **概要** | jobs-app での断続的な障害と応答時間の遅延 | -| **説明** | Recruiter と job posting ページが断続的に 500 エラーを返しています。ユーザーは過去 15 分間でページロードが大幅に遅くなったと報告しています。エンジニアリングは最近のデプロイメントを行っていません。 | -| **報告者** | アプリケーションサポートチーム | +| **優先度** | P2 — High | +| **概要** | jobs-app で断続的な障害とレスポンスタイムの低下 | +| **説明** | Recruiter と job posting のページが断続的に 500 エラーを返しています。ユーザーは過去 15 分間でページロードが著しく遅くなったと報告しています。エンジニアリングチームは最近のデプロイを行っていません。 | +| **報告者** | Application Support Team | | **影響を受ける namespace** | tenant-jobs | -> *「最近のデプロイメントはない — これが実は興味深い点です。責めるべき明らかな変更イベントがありません。だから自分たちで何が変わったかを把握する必要があります。どこから始めましょう？APM です。」* +> *「最近のデプロイはなし — これが実は興味深い点です。原因として明確な変更イベントがありません。つまり、何が変わったかを自分たちで突き止める必要があります。まずどこから始めますか？ APM です。」* --- -## Act 2 — APM を確認（行き止まり） +## Act 2 — APM の確認（行き止まり） -ここはほとんどの人が最初に行くところで、それがポイントです。APMを表示し、役に立たないことを見つけ、それを使ってより深いものが必要であるケースを構築します。 +ここはほとんどの人が最初に見に行く場所であり、それがポイントです。APM を表示し、役に立たないことを確認し、より深い何かが必要であるという根拠を構築します。 -**移動先：** Splunk Observability Cloud → **APM** → **Service Map** +**移動先** Splunk Observability Cloud → **APM** → **Service Map** -`tenant-jobs` 環境のサービスマップはトポロジーを示します：`recruiter` と `jobposting` は両方とも `coreapi` を呼び出し、coreapiはElasticsearchに接続します。`resumes` と `loader` サービスはバックグラウンドでKafkaを介して通信します。 +`tenant-jobs` 環境のサービスマップはトポロジーを示します`recruiter` と `jobposting` はどちらも `coreapi` を呼び出し、coreapi は Elasticsearch に接続します。`resumes` と `loader` サービスはバックグラウンドで Kafka 経由で通信しています。 -> *「これがサービスマップです。すべてのサービスが点灯しています — すべて応答していて、すべて接続されています。数字が実際に何を示しているか見てみましょう。* +> *「こちらがサービスマップです。すべてのサービスが稼働しています — すべてレスポンスを返し、すべて接続されています。実際に数字が何を示しているか見てみましょう。* > -> *リクエストレートは正常に見えます。レイテンシはわずかに上昇しているかもしれませんが、ユーザー向けのエラーを説明するほどのものではありません。coreapi のエラーレートを見てください — 約 10% です。これが問題だと思うかもしれませんが、そうではありません。このアプリはセットアップの一部として設定可能なエラーレートが組み込まれています。10 パーセントはベースラインであり、リグレッションではありません。* +> *リクエストレートは正常に見えます。レイテンシーはわずかに上昇しているかもしれませんが、ユーザーに見えるエラーを説明するほどではありません。次に coreapi のエラーレートを見てください — 約 10% です。これが問題だと思うかもしれませんが、違います。このアプリにはセットアップの一部として設定可能なエラーレートが組み込まれています。10% はベースラインであり、リグレッションではありません。* > -> *つまり APM が教えてくれるのは：サービスは生きていて、トラフィックは流れていて、エラーレートは変化していないということです。アプリケーショントレースには根本原因を示すものがありません。インフラストラクチャを試してみましょう。」* +> *つまり APM が教えてくれているのは：サービスは生きている、トラフィックは流れている、エラーレートは変わっていない。アプリケーショントレースには根本原因を示すものがありません。インフラを見てみましょう。」* -{{% notice title="なぜAPMではこれが見えないのか" style="info" %}} -APMはアプリケーションコードを計装します — サービス内部で何が起こっているかを観察します。接続が確立される*前に*ネットワーク層で何が起こっているかは見えません。DNS解決、接続の切断、パケットレベルのイベントは、設計上APMからは見えません。 +{{% notice title="APM がこれを検知できない理由" style="info" %}} +APM はアプリケーションコードを計装します — サービスの内部で何が起きているかを観察します。接続が確立される*前に*ネットワークレイヤーで何が起きているかは見えません。DNS 解決、接続の切断、パケットレベルのイベントは設計上 APM からは見えません。 {{% /notice %}} --- -## Act 3 — インフラストラクチャを確認（行き止まり） +## Act 3 — インフラの確認（行き止まり） -インフラを表示し、クリーンであることを見つけ、聴衆にまだ答えがないフラストレーションを感じさせます。 +インフラを表示し、問題がないことを確認し、まだ答えがないフラストレーションを聴衆に感じてもらいます。 -**移動先：** Splunk Observability Cloud → **Infrastructure** → **Kubernetes** → Cluster: `isovalent-demo` +**移動先** Splunk Observability Cloud → **Infrastructure** → **Kubernetes** → Cluster: `isovalent-demo` -> *「クラスター自体を見てみましょう。何かリソースが制約されているかもしれません — ノードが高負荷、Pod が OOMKilled されている、そのようなことです。* +> *「クラスター自体を見てみましょう。リソース制約があるかもしれません — ノードが高負荷になっている、Pod が OOMKill されている、そういったことです。* > -> *両方のノードは正常に見えます。CPU とメモリは正常範囲内です。Pod を掘り下げると — すべて Running 状態で、再起動なし、退去もされていません。コンテナ自体もリソース制限に達していません。* +> *両方のノードは正常に見えます。CPU とメモリは十分に通常の範囲内です。Pod を掘り下げてみると — すべて Running 状態で、再起動なし、退避もされていません。コンテナ自体もリソースリミットに達していません。* > -> *これで少し不快な状況になりました。チケットにはユーザーがエラーを見ていると書いてあります。APM はアプリが実行中だと言っています。インフラストラクチャはクラスターが正常だと言っています。これでどうなりますか？* +> *ここで少し困った状況になります。チケットにはユーザーがエラーを見ていると書いてあります。APM はアプリが動いていると言っています。インフラはクラスターが正常だと言っています。さて、どうすればよいでしょうか？* > -> *これは実際に非常によくある状況です。アプリケーション層より下、インフラストラクチャ層より下に存在する問題のクラス全体があります — 従来のモニタリングツールでは単純に見えないネットワークレベルで起こっていること。DNS 障害、接続の切断、ポリシー拒否、トラフィックの非対称性。これらはトレースや Pod メトリクスには現れません。ネットワーク自体を観察できるものが必要です。そこで Isovalent の出番です。」* +> *これは実はとても一般的な状況です。アプリケーションレイヤーの下、インフラレイヤーの下に存在する問題のクラスがあります — ネットワークレベルで起きていることで、従来の監視ツールでは見えないものです。DNS 障害、接続の切断、ポリシー拒否、トラフィックの非対称。これらはトレースや Pod メトリクスには表示されません。ネットワーク自体を観察できるものが必要です。そこで Isovalent の出番です。」* --- ## Act 4 — ネットワークが真実を語る -これがデモの核心です。ここはゆっくり時間をかけてください。 +これがデモの核心です。ここはじっくり時間をかけてください。 -**移動先：** Splunk Observability Cloud → **Dashboards** → **Hubble by Isovalent** +**移動先** Splunk Observability Cloud → **Dashboards** → **Hubble by Isovalent** -> *「Cilium — 私たちの CNI、すべてのノードで実行されているネットワーキング層 — には Hubble という組み込みのオブザーバビリティコンポーネントがあります。Hubble は eBPF を使用してクラスター内のすべてのネットワークフローをリアルタイムで監視します。サンプリングではなく、近似でもなく — すべての接続、すべての DNS リクエスト、すべてのパケットドロップ。そして OpenTelemetry Collector がそれらの Hubble メトリクスをスクレイプして Splunk に転送するように設定しているので、APM やインフラストラクチャを見ていたのと同じプラットフォームでそれらすべてを見ることができます。* +> *「Cilium — すべてのノードで動作している CNI、ネットワーキングレイヤー — には Hubble というビルトインのオブザーバビリティコンポーネントがあります。Hubble は eBPF を使用して、クラスター内のすべてのネットワークフローをリアルタイムで監視します。サンプリングではなく、近似でもなく — すべての接続、すべての DNS リクエスト、すべてのパケットドロップを監視します。そして OpenTelemetry Collector がこれらの Hubble メトリクスをスクレイプして Splunk に転送するよう設定したので、先ほど APM やインフラを見ていたのと同じプラットフォーム上ですべてを確認できます。* > -> *Hubble ダッシュボードを表示しましょう。」* +> *Hubble ダッシュボードを開きましょう。」* ### DNS クエリが制御不能 **DNS Queries チャートを指し、次に DNS Overview タブに移動します。** -> *「ありました。DNS クエリ量を見てください — 約 15 分前に急激にスパイクしています。このタイムスタンプはチケットが開かれた時間とぴったり一致します。* +> *「ありました。DNS クエリ量を見てください — 約 15 分前に急激にスパイクしています。このタイムスタンプはチケットが作成された時刻と完全に一致します。* > -> *見ているのは `hubble_dns_queries_total` で、ソース namespace ごとに分類されています。スパイクは完全に `tenant-jobs` — アプリケーション namespace から来ています。アプリケーション内の何かが大量の DNS トラフィックを生成し始め、DNS プロキシが追いつくのに苦労し始めました。* +> *表示されているのは `hubble_dns_queries_total` で、ソース namespace ごとに分割されています。スパイクは完全に `tenant-jobs` — 私たちのアプリケーション namespace — から来ています。アプリケーション内の何かが大量の DNS トラフィックを生成し始め、DNS プロキシが処理に追いつけなくなりました。* > -> *しかし右下を見てください — Missing DNS Responses チャートです。これはアラートが発火しているものです。値が深くマイナスになっています。これは DNS クエリが送信されているのに、応答が一度も戻ってこないことを意味します。DNS プロキシが圧倒され、接続は静かにタイムアウトしています。これがユーザーの 500 エラーとして現れている波及効果です。」* +> *しかし右下を見てください — Missing DNS Responses チャートです。これはアラートが発火しているものです。値が大きくマイナスになっています。つまり DNS クエリが送信されているのにレスポンスが返ってきていないということです。DNS プロキシが圧倒されて、接続が静かにタイムアウトしています。これがユーザーに 500 エラーとして現れている波及効果です。」* ![Hubble DNS Overview showing Missing DNS Responses alert firing as values go deeply negative](images/Missing%20DNS%20Response.png) -### トップ DNS クエリが原因を明らかに +### Top DNS Queries が犯人を明らかにする **Top 10 DNS Queries チャートを指します。** -> *「これらすべての DNS リクエストを行っているものを特定しましょう。Top 10 DNS Queries チャートは最も頻繁にクエリされるドメインを分類しており、1 つの名前が圧倒的に目立っています：`api.github.com`。* +> *「では、これらすべての DNS リクエストを生成しているものを特定しましょう。Top 10 DNS Queries チャートは最も頻繁にクエリされるドメインを分類しており、1 つの名前が圧倒的に目立っています`api.github.com` です。* > -> *これはクラスター内部のサービスではありません — 外部エンドポイントです。そしてアプリ内で外部エンドポイントと通信するのは crawler サービスだけです。crawler はジョブシミュレーションの一部として外部 URL への HTTP 呼び出しを行います。その HTTP 呼び出しを行うたびに、最初に DNS を通じて `api.github.com` を解決する必要があります。* +> *これはクラスター内部のサービスではありません — 外部エンドポイントです。そしてアプリ内で外部エンドポイントと通信するのは crawler サービスだけです。crawler はジョブシミュレーションの一環として外部 URL に HTTP リクエストを行います。HTTP リクエストを行うたびに、まず DNS で `api.github.com` を解決する必要があります。* > -> *通常これは問題ありません。1 つの crawler Pod が数秒ごとにリクエストを行うのは完全に管理可能です。しかし、どれだけ積極的に実行されているかについて何かが明らかに変化しています。」* +> *通常これは問題ありません。1 つの crawler Pod が数秒ごとにリクエストを行うのは完全に管理可能です。しかし、どれほど積極的に動作しているかについて、明らかに何かが変わっています。」* -### ドロップされたフローが影響範囲を示す +### Dropped Flows が影響範囲を示す **Dropped Flows チャートを指します。** -> *「Dropped Flows チャートは別の注目すべきことを示しています。Hubble は成功した接続だけを追跡するのではありません — 拒否またはドロップされたすべての接続と、その理由コードをキャプチャします。DNS スパイクと全く同じ時間にドロップの増加が見られます。* +> *「Dropped Flows チャートは別の注目すべきことを示しています。Hubble は成功した接続を追跡するだけでなく、拒否またはドロップされたすべての接続と、その理由コードをキャプチャします。DNS スパイクとまったく同じ時間にドロップの増加が見られます。* > -> *これらのドロップは DNS 過負荷の下流の結果です。namespace 内のサービスが接続を試み、DNS が遅すぎるか失敗すると、それらの接続試行はタイムアウトしてドロップされます。これが APM がレイテンシの上昇として見ていたものです — しかし APM にはその下に DNS 問題があることは全くわかりませんでした。」* +> *これらのドロップは DNS 過負荷の下流の結果です。namespace 内のサービスが接続を試み、DNS が遅すぎるか失敗している場合、それらの接続試行はタイムアウトしてドロップされます。これが APM でレイテンシーの上昇として見えていたものです — しかし APM はその下に DNS の問題があることを知る由もありませんでした。」* -### ネットワークフロー量がパターンを確認 +### ネットワークフロー量がパターンを確認する **Metrics & Monitoring タブに移動します。** -> *「そして Metrics & Monitoring タブを見ると、全体像がさらに明確になります。ノードごとの処理フロー数が垂直に上昇しています — これは生のネットワークトラフィック量です。Forwarded vs Dropped チャートは、それらのフローのかなりの割合が転送されずにドロップされていることを示しています。そして Drop Reason の内訳は、TTL_EXCEEDED と DROP_REASON_UNKNOWN の混合であることを教えてくれます — DNS タイムアウトがカスケードし始めたときにまさに予想されるものです。特定の時点で何かが変わり、その時点以降のすべてがベースラインとは異なって見えます。」* +> *「Metrics & Monitoring タブを見ると、全体像がさらに明確になります。ノードあたりの処理フロー数が垂直に上昇しています — これは生のネットワークトラフィック量です。Forwarded vs Dropped チャートは、それらのフローのかなりの割合が転送されずにドロップされていることを示しています。Drop Reason の内訳は TTL_EXCEEDED と DROP_REASON_UNKNOWN の混合を示しています — DNS タイムアウトがカスケードしている場合にまさに予想されるものです。特定の時点で何かが変わり、その時点以降のすべてがベースラインと異なって見えます。」* ![Hubble Metrics & Monitoring showing flow spike, forwarded vs dropped, and drop reasons](images/Increase%20of%20Flows.png) @@ -188,9 +188,9 @@ APMはアプリケーションコードを計装します — サービス内部 **L7 HTTP Metrics タブに移動します。** -> *「L7 HTTP Metrics タブで指摘する価値のあることがあります。これは実際に APM が役に立たなかった理由を補強するからです。受信リクエスト量はゼロではありません — トラフィックはまだ流れています。成功率チャートはほとんど緑に見えます。HTTP レベルの可視性だけを見ていた場合、アプリは問題ないと結論づけるかもしれません。* +> *「L7 HTTP Metrics タブで指摘する価値のあるものがあります。これは実は APM が役に立たなかった理由を補強しています。受信リクエスト量はゼロではありません — トラフィックはまだ流れています。成功率チャートはほとんど緑に見えます。HTTP レベルの可視性だけを見ていた場合、アプリは問題ないと結論づけるかもしれません。* > -> *しかし Incoming Requests by Source チャートを見てください。crawler が不釣り合いなシェアのトラフィックを生成しています — 他のサービスから分離しているのが見えます。HTTP 呼び出しを成功させているので、APM はフラグを立てません。問題は 1 つ下の層、DNS で、HTTP 接続が確立される前に起こっています。」* +> *しかし Incoming Requests by Source チャートを見てください。crawler が不釣り合いに多くのトラフィックを生成しています — 他のサービスから分離しているのが見えます。HTTP リクエストは正常に行えています。だから APM はフラグを立てません。問題は 1 つ下のレイヤー、DNS で、HTTP 接続が確立される前に起きています。」* ![Hubble L7 HTTP Metrics showing crawler traffic spike with high request volume](images/Increase%20in%20Requests.png) @@ -200,9 +200,9 @@ APMはアプリケーションコードを計装します — サービス内部 ここで点と点をつなぎ、証明します。 -> *「これが全体像です：ある時点で、crawler サービスが 1 レプリカから 5 にスケールアップされ、クロール間隔が非常に積極的に設定されました — 0.2 から 0.3 秒ごと。これは 5 つの Pod が、それぞれ `api.github.com` を解決するために DNS ルックアップを毎秒複数回発火させています。合計すると、毎秒 15 から 25 の DNS クエリが持続的に発生します。DNS プロキシは単一のワークロードからそのような負荷を処理するようには作られていないので、キューイング、スローダウン、そして最終的にはリクエストのドロップを開始します。DNS 解決を必要とする namespace 内の他のすべてのサービスが巻き添えを食います。* +> *「全体像はこうです：ある時点で、crawler サービスが 1 レプリカから 5 にスケールアップされ、クロール間隔が非常に積極的に設定されました — 0.2〜0.3 秒ごとです。5 つの Pod がそれぞれ毎秒複数回 `api.github.com` を解決するために DNS ルックアップを実行しています。合計すると、持続的に毎秒 15〜25 の DNS クエリです。DNS プロキシは単一のワークロードからそのような負荷を処理するように設計されていないため、キューイング、スローダウン、そして最終的にリクエストのドロップを始めます。namespace 内で DNS 解決が必要なすべてのサービスが巻き添えになります。* > -> *それが何を見ているか確認しましょう。」* +> *確認してみましょう。」* ```bash # Confirm the current crawler replica count — you'll see 5 @@ -213,23 +213,23 @@ kubectl get deploy crawler -n tenant-jobs \ -o jsonpath='{.spec.template.spec.containers[0].env}' | jq . ``` -**オプションとして、Cilium by Isovalent dashboard → Policy: L7 Proxy タブに切り替えます。** +**オプションで、Cilium by Isovalent ダッシュボード → Policy: L7 Proxy タブに切り替えます。** -> *「Hubble 側ではなく Cilium 側からこれを見たい場合は、Cilium by Isovalent dashboard に切り替えて Policy: L7 Proxy タブを見てください。FQDN の L7 Request Processing Rate — これが DNS です — が 21,000 リクエストを超えています。これは分あたりではありません。DNS プロキシは非常に大量の FQDN ルックアップを処理しており、すべて受信されて転送されているため、バックアップし始めました。このビューは DNS Proxy Upstream Reply レイテンシも表示しており、プロキシが圧力下にあることを確認できます。」* +> *「Hubble 側ではなく Cilium 側からこれを見たい場合は、Cilium by Isovalent ダッシュボードに切り替えて Policy: L7 Proxy タブを見てください。FQDN — つまり DNS — の L7 Request Processing Rate が 21,000 リクエストを超えています。これは毎分ではありません。DNS プロキシが膨大な量の FQDN ルックアップを処理しており、すべてが受信され転送されているため、バックアップし始めたのです。このビューでは DNS Proxy Upstream Reply のレイテンシーも表示され、プロキシが圧力を受けていることを確認できます。」* ![Cilium Policy: L7 Proxy showing FQDN request processing rate spiking to 21k+](images/L7%20Procesing%20Rate%20Increase.png) -> *「ありました。5 レプリカ、0.2 から 0.3 秒ごとにクロール。* +> *「これです。5 レプリカ、0.2〜0.3 秒ごとにクロール。* > -> *APM ではこれが見えません。コードを計装しているのであって、DNS ではないからです。インフラストラクチャモニタリングでもこれは見えません。Pod は正常です — 設定されたとおりに正確に動作しています。これをキャッチできる唯一のツールは、eBPF レベルで動作し、すべてのパケット、すべての DNS リクエスト、すべての接続試行をリアルタイムで監視するものです。それが Hubble です。そして Splunk に接続しているので、他のすべてに使用しているのと同じダッシュボードでキャッチしました。」* +> *APM はこれを見ることができません。コードを計装しているのであって、DNS ではないからです。インフラ監視もこれを見ることができません。Pod は正常だからです — 設定通りに正確に動作しています。これを検知できる唯一のツールは、eBPF レベルで動作し、すべてのパケット、すべての DNS リクエスト、すべての接続試行をリアルタイムで監視するものです。それが Hubble です。そして Splunk に接続したので、他のすべてに使用しているのと同じダッシュボードで検知できました。」* --- -## Act 6 — ライブで修正 +## Act 6 — ライブで修正する -この部分は満足感があります。チャートがリアルタイムで回復するのを見ることができるからです。 +この部分はチャートがリアルタイムで回復するのを見られるので満足感があります。 -> *「修正は簡単です — crawler をスケールダウンして、通常のクロール間隔を復元します。」* +> *「修正は簡単です — crawler をスケールダウンして通常のクロール間隔に戻します。」* ```bash helm upgrade jobs-app . --namespace tenant-jobs --reuse-values \ @@ -239,37 +239,37 @@ helm upgrade jobs-app . --namespace tenant-jobs --reuse-values \ --set resumes.replicas=1 ``` -**Hubble by Isovalent** ダッシュボードに戻り、1分ほど待ちます。 +**Hubble by Isovalent** ダッシュボードに戻り、1 分間そのままにします。 -> *「DNS Queries チャートを見てください — ほぼ即座に下がってくるのが見えます。1〜2 分以内にベースラインに戻ります。ドロップされたフローはゼロになります。ネットワークフロー量は通常に戻ります。* +> *「DNS Queries チャートを見てください — ほぼ即座に下がっていくのが見えます。1〜2 分以内にベースラインに戻ります。Dropped flows はゼロになります。ネットワークフロー量は通常に戻ります。* > -> *そして今 APM に戻ると、レイテンシが正常化し、エラーレートが予想される 10% のベースラインに落ち着くのが見えるでしょう。* +> *そして今 APM に戻れば、レイテンシーが正常化し、エラーレートが期待される 10% のベースラインに落ち着いているのが見えるでしょう。* > -> *チケットをクローズできます。根本原因：crawler の設定ミスによる DNS 飽和。解決策：Helm を使用して crawler のレプリカ数とクロール間隔を元に戻す。解決までの時間：チケットが開かれてから約 15 分。」* +> *チケットをクローズできます。根本原因：crawler の設定ミスによる DNS 飽和。解決策：Helm 経由で crawler のレプリカ数とクロール間隔を元に戻しました。解決までの時間：チケットが作成されてから約 15 分。」* {{% notice title="修復完了" style="success" %}} -DNSクエリレートがベースラインに戻り、ドロップされたフローがクリアされ、アプリケーションの健全性が回復します — すべてHubbleダッシュボードでライブで確認できます。 +DNS クエリレートがベースラインに戻り、dropped flows がクリアされ、アプリケーションの正常性が回復します — すべて Hubble ダッシュボードでライブで確認できます。 {{% /notice %}} --- -## Act 7 — これが実際に意味すること +## Act 7 — これが本当に意味すること -ズームアウトして、価値のステートメントを具体的に感じさせて終わります。 +最後にズームアウトして、価値の訴求を具体的に感じてもらいます。 -> *「ここで何が起こったか考えてみましょう。本番スタイルの本当の問題がありました — エンドユーザーにとって何かが壊れていて — 標準的なプレイブックを経由しました。APM は何も問題ないと言いました。インフラストラクチャも何も問題ないと言いました。Hubble がなければ、次のステップはおそらく戦争部屋の通話、ログを見つめる人々、namespace 全体の再起動を期待して行うことだったでしょう。* +> *「ここで何が起きたか考えてみましょう。本番環境スタイルの本格的な問題がありました — エンドユーザーにとって何かが壊れている — そして標準的なプレイブックを実行しました。APM は問題ないと言いました。インフラも問題ないと言いました。Hubble なしでは、次のステップはおそらくウォールームの呼び出し、ログを見つめる人々、namespace を完全に再起動して問題が解消されることを祈ることだったでしょう。* > -> *代わりに、Hubble ダッシュボードを開いた瞬間から 3 分以内に見つけました。私たちが賢いからではなく、正しい層への可視性があったからです。* +> *代わりに、Hubble ダッシュボードを開いた瞬間から 3 分以内に発見できました。私たちが賢いからではなく、適切なレイヤーへの可視性があったからです。* > -> *これが機能する理由は eBPF です。Cilium の Hubble コンポーネントは Linux カーネルにフックし、ソースでネットワークイベントを観察します — アプリケーションコードに到達する前に、Pod ログに現れる前に、APM のトレースになる前に。そして OpenTelemetry Collector を通じてそれらのメトリクスを Splunk に送信することで、APM データやインフラストラクチャデータと同じプラットフォームに並んでいます。ツールを切り替えたり、5 つの異なるダッシュボード間でコンテキストスイッチする必要はありません。以前なかった可視性の層を追加し、チームがすでに知っているワークフローに保持します。* +> *これが機能する理由は eBPF です。Cilium の Hubble コンポーネントは Linux カーネルにフックし、ネットワークイベントをソースで観察します — アプリケーションコードに到達する前に、Pod ログに表示される前に、APM のトレースになる前に。そしてこれらのメトリクスを OpenTelemetry Collector を通じて Splunk に送信することで、APM データやインフラデータと同じプラットフォーム上に並びます。ツールを切り替えたり、5 つの異なるダッシュボード間でコンテキストスイッチする必要はありません。以前はなかった可視性のレイヤーを追加し、チームがすでに知っているワークフロー内に保持します。* > -> *これがストーリーです。ネットワークオブザーバビリティはニッチなニーズではありません — APM とインフラストラクチャモニタリングが残すギャップです。Isovalent がそのギャップを埋め、Splunk でそれを見ることができます。」* +> *これがこのストーリーです。ネットワークオブザーバビリティはニッチな需要ではありません — APM とインフラ監視が残すギャップです。Isovalent がそのギャップを埋め、Splunk がそれを可視化する場所です。」* --- ## クイックリファレンス -**問題を注入**（デモの約10分前に実行）： +**問題の注入**（デモの約 10 分前に実行） ```bash helm upgrade jobs-app . -n tenant-jobs --reuse-values \ @@ -279,7 +279,7 @@ helm upgrade jobs-app . -n tenant-jobs --reuse-values \ --set resumes.replicas=2 ``` -**修復**（Act 6でライブ実行）： +**修復**（Act 6 でライブ実行） ```bash helm upgrade jobs-app . -n tenant-jobs --reuse-values \ @@ -289,7 +289,7 @@ helm upgrade jobs-app . -n tenant-jobs --reuse-values \ --set resumes.replicas=1 ``` -**設定ミスを確認：** +**設定ミスの確認** ```bash kubectl get deploy crawler -n tenant-jobs @@ -297,18 +297,18 @@ kubectl get deploy crawler -n tenant-jobs \ -o jsonpath='{.spec.template.spec.containers[0].env}' | jq . ``` -**Splunk ナビゲーションパス：** -APM → Service Map → *（クリーンであることを表示）* → Infrastructure → Kubernetes → *（クリーンであることを表示）* → Dashboards → Hubble by Isovalent → *（DNS スパイクを表示）* +**Splunk ナビゲーションパス** +APM → Service Map → *（問題なしを表示）* → Infrastructure → Kubernetes → *（問題なしを表示）* → Dashboards → Hubble by Isovalent → *（DNS スパイクを表示）* ## タイミングガイド -| セクション | 概算時間 | -|---|---| +| セクション | おおよその時間 | +| ------- | ------------ | | Act 1 — チケット | 約 1 分 | | Act 2 — APM（行き止まり） | 約 2〜3 分 | -| Act 3 — インフラストラクチャ（行き止まり） | 約 1〜2 分 | +| Act 3 — インフラ（行き止まり） | 約 1〜2 分 | | Act 4 — Hubble ダッシュボード | 約 4〜5 分 | | Act 5 — 根本原因の確認 | 約 2 分 | -| Act 6 — ライブで修正 | 約 2 分 | +| Act 6 — ライブ修正 | 約 2 分 | | Act 7 — 価値のまとめ | 約 2 分 | | **合計** | **約 14〜17 分** | diff --git a/content/ja/scenarios/isovalent-cilium-integration/_index.md b/content/ja/scenarios/isovalent-cilium-integration/_index.md index ca7e29e6fd..6f41a26059 100644 --- a/content/ja/scenarios/isovalent-cilium-integration/_index.md +++ b/content/ja/scenarios/isovalent-cilium-integration/_index.md @@ -2,24 +2,23 @@ title: Isovalent Enterprise Platform と Splunk Observability Cloud の統合 linkTitle: Isovalent Splunk Observability 統合 weight: 6 -archetype: chapter authors: ["Alec Chamberlain"] time: 105 minutes -description: Amazon EKS 上に Isovalent Enterprise Platform（Cilium、Hubble、Tetragon）をデプロイし、Splunk Observability Cloud と統合して、eBPF ベースの包括的なモニタリングとオブザーバビリティを実現します。Hubble ダッシュボードを使用した DNS 問題調査のエンドツーエンドデモを含みます。 +description: EKS 上の Cilium、Hubble、Tetragon から eBPF ネットワークおよびランタイムシグナルを Splunk Observability Cloud にストリーミングします — Hubble を活用した DNS 調査を含みます。 --- -このワークショップでは、**Isovalent Enterprise Platform と Splunk Observability Cloud** を統合し、eBPF テクノロジーを使用して Kubernetes のネットワーキング、セキュリティ、およびランタイム動作に対する包括的な可視性を提供する方法を紹介します。 +このワークショップでは、**Isovalent Enterprise Platform と Splunk Observability Cloud** を統合し、eBPF テクノロジーを使用して Kubernetes のネットワーキング、セキュリティ、およびランタイム動作の包括的な可視性を提供する方法を実演します。 ## 学習内容 このワークショップを完了すると、以下のことができるようになります -- ENI モードで Cilium を CNI として使用する Amazon EKS のデプロイ -- L7 可視性を備えたネットワークオブザーバビリティのための Hubble の設定 -- ランタイムセキュリティモニタリングのための Tetragon のインストール -- OpenTelemetry を使用した eBPF ベースのメトリクスと Splunk Observability Cloud の統合 -- 統合ダッシュボードでのネットワークフロー、セキュリティイベント、インフラストラクチャメトリクスのモニタリング -- eBPF を活用したオブザーバビリティと kube-proxy の置き換えの理解 +- Amazon EKS に Cilium を CNI として ENI モードでデプロイする +- Hubble を L7 可視性を備えたネットワークオブザーバビリティ用に構成する +- Tetragon をランタイムセキュリティモニタリング用にインストールする +- eBPF ベースのメトリクスを OpenTelemetry を使用して Splunk Observability Cloud と統合する +- ネットワークフロー、セキュリティイベント、およびインフラストラクチャメトリクスを統合ダッシュボードで監視する +- eBPF を活用したオブザーバビリティと kube-proxy の置き換えを理解する ## セクション @@ -29,17 +28,17 @@ description: Amazon EKS 上に Isovalent Enterprise Platform（Cilium、Hubble - [Cilium インストール](./4-cilium-installation/_index.md) - Cilium、Hubble、Tetragon をデプロイする - [Splunk 統合](./5-splunk-integration/_index.md) - メトリクスを Splunk Observability Cloud に接続する - [検証](./6-verification/_index.md) - 統合を検証する -- [デモスクリプト](./7-demo/_index.md) - エンドツーエンドの DNS 調査シナリオを実施する +- [デモスクリプト](./7-demo/_index.md) - エンドツーエンドの DNS 調査シナリオを実行する -{{% notice title="ヒント" style="primary" icon="lightbulb" %}} -この統合では、Linux カーネル内で直接動作する高パフォーマンス・低オーバーヘッドのオブザーバビリティのために eBPF（Extended Berkeley Packet Filter）を活用しています。 +{{% notice title="Tip" style="primary" icon="lightbulb" %}} +この統合は、Linux カーネル内で直接高性能かつ低オーバーヘッドのオブザーバビリティを実現するために eBPF（Extended Berkeley Packet Filter）を活用しています。 {{% /notice %}} ## 前提条件 -- 適切な認証情報が設定された AWS CLI +- 適切な認証情報で構成された AWS CLI - kubectl、eksctl、および Helm 3.x がインストール済みであること -- EKS クラスター、VPC、EC2 インスタンスを作成する権限を持つ AWS アカウント +- EKS クラスター、VPC、および EC2 インスタンスを作成する権限を持つ AWS アカウント - アクセストークンを持つ Splunk Observability Cloud アカウント - 完全なセットアップに約90分 @@ -47,15 +46,15 @@ description: Amazon EKS 上に Isovalent Enterprise Platform（Cilium、Hubble Isovalent Enterprise Platform を Splunk Observability Cloud に接続することで、以下のメリットが得られます -- 🔍 **詳細な可視性**: ネットワークフロー、L7 プロトコル（HTTP、DNS、gRPC）、およびランタイムセキュリティイベント -- 🚀 **高パフォーマンス**: 最小限のオーバーヘッドによる eBPF ベースのオブザーバビリティ +- 🔍 **深い可視性**: ネットワークフロー、L7 プロトコル（HTTP、DNS、gRPC）、およびランタイムセキュリティイベント +- 🚀 **高パフォーマンス**: 最小限のオーバーヘッドで eBPF ベースのオブザーバビリティを実現 - 🔐 **セキュリティインサイト**: プロセスモニタリング、システムコールトレーシング、およびネットワークポリシーの適用 -- 📊 **統合ダッシュボード**: インフラストラクチャおよび APM データと並んだ Cilium、Hubble、Tetragon のメトリクス +- 📊 **統合ダッシュボード**: Cilium、Hubble、Tetragon のメトリクスをインフラストラクチャおよび APM データと並べて表示 - ⚡ **効率的なネットワーキング**: kube-proxy の置き換えと ENI モードによるネイティブ VPC ネットワーキング ## ソースリポジトリ -このワークショップで参照されるすべての設定ファイル、Helm values、およびダッシュボード JSON ファイルは、以下のリポジトリで利用できます +このワークショップで参照されるすべての構成ファイル、Helm values、およびダッシュボード JSON ファイルは、以下のリポジトリで入手できます -- **[isovalent_splunk_o11y](https://github.com/chambear2809/isovalent_splunk_o11y/)** — Helm values、OTel Collector 設定、Splunk ダッシュボード JSON ファイル、および完全な統合ガイド +- **[isovalent_splunk_o11y](https://github.com/chambear2809/isovalent_splunk_o11y/)** — Helm values、OTel Collector 構成、Splunk ダッシュボード JSON ファイル、および完全な統合ガイド - **[isovalent-demo-jobs-app](https://github.com/chambear2809/isovalent-demo-jobs-app)** — デモシナリオで使用される jobs-app Helm チャート（エラーインジェクションおよび修復スクリプトを含む） diff --git a/content/ja/scenarios/network-event-intelligence/1-getting-started/_index.md b/content/ja/scenarios/network-event-intelligence/1-getting-started/_index.md new file mode 100644 index 0000000000..5189533515 --- /dev/null +++ b/content/ja/scenarios/network-event-intelligence/1-getting-started/_index.md @@ -0,0 +1,76 @@ +--- +title: はじめに +linkTitle: 1. はじめに +weight: 1 +time: 2 minutes +authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] +--- + + +## ワークショップへのアクセス + +このワークショップの前に、ワークショップインスタンスへのアクセス情報が提供されているはずです。このワークショップでは、Splunk Enterprise と IT Service Intelligence が含まれた事前設定済みの環境を使用します。インスタンスへのリンクと認証情報は、Splunk Show のインスタンス詳細で確認できます。 + +このワークショップを完了するために必要なすべてのデータは `netops` インデックスで利用可能です。このインデックスには、**Catalyst Center**、**Merkai**、および **Solarwinds** からのアラートのデータが含まれています。 + +自動化された障害シナリオが30分サイクルで実行されます。Catalyst Center のサイトは15分間正常に動作し、その後15分間パフォーマンスが低下します。環境が異常な状態の間、**Catalyst Center** と **Solarwinds** から Issue とアラートが生成されます。 + +このワークショップの大部分は IT Service Intelligence で完了します。特に記載がない限り、ナビゲーション手順はそこから開始します。 + +{{% notice style="primary" title="ワークショップインスタンスにアクセスする" %}} + +**1.** Splunk Show のワークショップ詳細に記載された URL と認証情報を使用して、Splunk インスタンスにログインします。 + +**2.** **Apps -> IT Service Intelligence** に移動します。 + +ITSI を初めて開く際に、Getting Started モーダルを閉じる必要がある場合があります（もちろん、重要な情報をすべて読んでからです）。 + +![ITSI Getting Started Modal](../images/getting-strarted-modal.png?width=30vw) +{{% / notice %}} + +## データの取り込み + +このワークショップでは一貫したシナリオを提供するために datagen を使用していますが、実際の環境では、このワークショップで扱うユースケースを実装するために以下の Splunk Apps および Add-on が必要です。 + +### 1. [Cisco Catalyst Add-on for Splunk](https://splunkbase.splunk.com/app/7538) + +_Cisco Catalyst Add-on for Splunk は、さまざまな Cisco 製品（Cisco Identity Services Engine、Cisco SD-WAN、Cisco Catalyst Center、Cisco Cyber Vision）のデータを収集します。この Add-on は、これらのソースからのデータを解析し、Splunk インデックスに保存します。_ + +### 2. [Splunk App for Content Packs](https://splunkbase.splunk.com/app/5391) + +_Splunk App for Content Packs には、IT Service Intelligence (ITSI) 環境の迅速なセットアップに役立つパッケージ済みコンテンツが含まれています。このパッケージ済みコンテンツは、KPI Base searches、ITSI Glass Tables、テンプレート、およびその他のオブジェクトで構成されています。_ + +{{% notice style="info" %}} +このワークショップでは **Content Pack for Cisco Enterprise Networks** を使用します。これにより、**Cisco Catalyst Add-on for Splunk** が提供するトポロジー情報を使用してサービスを自動的にインポートできます。 +{{% / notice %}} + +### 3. [SolarWinds Add-on for Splunk](https://splunkbase.splunk.com/app/3584) (Optional) + +_SolarWinds Add-on for Splunk は、SolarWinds のアラートと SolarWinds の資産インベントリ（ネットワークデバイスとそのさまざまな属性）を収集します。この Add-on には、任意の SolarWinds クエリをスケジュールし、対応する出力を Splunk にインデックスできる汎用入力も含まれています。 +データを直接分析したり、Splunk プラットフォーム内の他のアプリケーションパフォーマンス関連データと相関させるためのコンテキストデータフィードとして使用したりできます。_ + +{{% notice style="info" %}} +この Add-on は、このワークショップで扱うユースケースではオプションです。SolarWinds のアラートは Splunk HTTP Event Collector に直接送信されるため、Add-on は不要です。実際のシナリオでは、Add-on は資産インベントリ情報を使用して追加のコンテキストやデータエンリッチメントを提供できます。 +{{% / notice %}} + +## 追加の Apps/Add-on + +### 1. [Cisco Meraki Add-on for Splunk](https://splunkbase.splunk.com/app/5580) + +_Splunk Add-on for Cisco Meraki は、Meraki 組織全体にわたる包括的なネットワークオブザーバビリティとセキュリティ監視を提供します。この Add-on は、Cisco Meraki REST API と Webhook を介してリッチなデータを収集し、ネットワークパフォーマンス、セキュリティ、およびデバイスの健全性に関するインサイトを提供します。データの探索やカスタムダッシュボードの作成に役立つサンプルビジュアライゼーションも提供されています。_ + +{{% notice style="info" %}} +Cisco Meraki はこのワークショップでは扱いませんが、`netops` インデックスには **Cisco Meraki Add-on for Splunk** を使用して収集される Cisco Meraki データが利用可能です。 +{{% / notice %}} + +### 2. [Cisco Enterprise Networking for Splunk Platform](https://splunkbase.splunk.com/app/7539) + +_Cisco Enterprise Networking for Splunk Platform は、さまざまな Cisco 製品（Cisco Identity Services Engine、Cisco SD-WAN、Cisco Catalyst Center、Cisco Cyber Vision、Cisco Meraki、Cisco ThousandEyes）のダッシュボードにビジュアライゼーションを表示します。_ +この App は以下によって収集されたデータを使用します + +* _Cisco Catalyst Add-on for Splunk_ +* _Cisco Catalyst Enhanced Netflow Add-on for Splunk_ +* _Cisco Meraki Add-on for Splunk_ +* _Cisco ThousandEyes App for Splunk_ + +![Cisco Enterprise Networking App](../images/cisco-ent-network-overview.png?width=30vw) diff --git a/content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/1-cisco-enterprise-networks-content-pack.md b/content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/1-cisco-enterprise-networks-content-pack.md new file mode 100644 index 0000000000..9ce9bf8cfb --- /dev/null +++ b/content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/1-cisco-enterprise-networks-content-pack.md @@ -0,0 +1,68 @@ +--- +title: Cisco Enterprise Networks Content Pack のインストール +linkTitle: 2.1 Cisco Enterprise Networks Content Pack のインストール +weight: 1 +time: 5 minutes +authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] +--- + +このセクションでは、Cisco ネットワークインフラストラクチャ向けの事前構築されたサービス、KPI、およびデータ統合を提供する Cisco Enterprise Networks Content Pack をインストールします。 + +{{% notice title="演習: Cisco Enterprise Networks Content Pack のインストール" style="primary" icon="running" %}} +**1.** ITSI で **Configuration -> Data Integrations** に移動します + +**2.** Data Integrations の下にあるタブから **Content Library** を選択します + +{{% notice style="Info" %}} +ここでは、Splunk App for Content Packs で利用可能なすべてのすぐに使える統合を確認できます + +![Data Integrations](../../images/content-library.png?width=40vw) +{{% / notice %}} + +**3.** **Content Pack for Cisco Enterprise Networks** を選択し、**Proceed** をクリックします + +{{% notice style="Info" %}} +このページでは、コンテンツパックで利用可能な内容の概要が表示されます + +![Content Pack for Cisco Enterprise Networks](../../images/content-pack-overview.png?width=40vw) +{{% / notice %}} + +**5.** **Add all 14 objects** が有効になっていることを確認します + +**6.** **Import As Enabled** トグルを有効にします + +**重要: Add a prefix to your new objects セクションにプレフィックスを入力しないでください** + +**7.** **Install Selected** をクリックします + +{{% notice style="Info" %}} +Install Selected をクリックする前に、Add all 14 objects と Import As Enabled の両方がオンになっていることを確認してください + +![Install Selected](../../images/install-selected.png?width=40vw) +{{% / notice %}} + +**8.** **Install** をクリックします。 + +{{% notice style="Info" %}} +本番環境では、大きな変更を行う前にバックアップを取ることがベストプラクティスです + +![Install](../../images/install-confirm.png?width=40vw) +{{% / notice %}} + +**9.** インストールが完了したことを確認します。 + +{{% notice style="Info" %}} +サマリーにより、すべてのオブジェクトが正常にインストールされたことが確認できます + +![Installation Complete](../../images/installation-complete.png?width=40vw) +{{% / notice %}} + +{{% notice style="Primary" title="お疲れ様でした！" %}} +Cisco Enterprise Networks Content Pack のインストールが完了しました！ + +次のセクションでは、コンテンツパックを使用して Catalyst Center Sites を ITSI のサービスとして自動的にインポートする方法を説明します。 + +**Configure Services** をクリックして、ワークショップの次のセクションに進んでください。 +{{% / notice %}} + +{{% / notice %}} diff --git a/content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/2-itsi-service-kpi-import-and-setup.md b/content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/2-itsi-service-kpi-import-and-setup.md new file mode 100644 index 0000000000..6c93bcf25e --- /dev/null +++ b/content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/2-itsi-service-kpi-import-and-setup.md @@ -0,0 +1,83 @@ +--- +title: ITSI サービスと KPI の検証 +linkTitle: 2.2 ITSI サービスと KPI の検証 +weight: 2 +time: 5 minutes +authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] +--- + +ITSI 4.21 では、手動のインポートプロセスがガイド付きワークフローと事前構築済みのデータインテグレーションに置き換えられました。コンテンツパックには、Meraki と Catalyst Center のサービス階層を自動的に検出して構築するサービスインポートモジュールが含まれています。 + +{{% notice title="演習: サービスのインポートとアラートの設定" style="primary" icon="running" %}} + +{{% notice title="ヒント" style="primary" icon="lightbulb" %}} +Catalyst Center のサービスインポートページに戻るには、**Configuration** > **Data Integrations** > **Content Library** > **Cisco Enterprise Networks** に移動します。 +{{% / notice %}} + +**1.** **Service Import Modules** の下で、**Cisco Catalyst Center** を選択します。 + +{{% notice style="Info" %}} +**Catalyst Center** と **Meraki** の両方で自動サービス階層インポートがサポートされています + +![Service Import Modules](../../images/service-import-modules.png?width=40vw) +{{% / notice %}} + +**2.** Catalyst Center ホストと利用可能なすべてのサービスを選択します。**Next** をクリックします。 + +{{% notice style="Info" %}} +Catalyst Center ホストと利用可能なすべてのサイトを選択して、ITSI サービスとしてインポートします + +![Select Services](../../images/select-services.png?width=40vw) +{{% / notice %}} + +**3.** **Default Service Sandbox** を選択します。**Next** をクリックします。 + +{{% notice style="Info" %}} +サービスは本番環境の ITSI に公開する前に、レビュー用のサンドボックスにインポートされます + +![Default Service Sandbox](../../images/default-service-sandbox.png?width=40vw) +{{% / notice %}} + +**4.** インポートされるサービスを確認します。**Import** をクリックします。 + +{{% notice style="Info" %}} +Import をクリックする前に、作成される Catalyst Center サイトサービスの完全なリストを確認します + +![Review Services](../../images/review-services.png?width=40vw) +{{% / notice %}} + +**5.** Service Sandbox を確認します。**Publish** をクリックします。事前チェックが完了したら、**Next** をクリックします。 + +{{% notice style="Info" %}} +サンドボックスでサービス階層を確認し、公開して ITSI でサービスをアクティブにします + +![Service Sandbox](../../images/service-sandbox-publish.png?width=40vw) +{{% / notice %}} + +**6.** **Configuration** > **Service Monitoring** > **Service and KPI Management** に移動します。 + +**7.** **Select All** チェックボックスを使用して、すべてのサービスを選択します。 + +**8.** すべてのサービスを選択した状態で、**Bulk Action** > **Enable** をクリックします。 + +{{% notice style="Info" %}} +Service and KPI Management ページから Bulk Action を使用して、インポートされたすべてのサービスを一括で有効にします + +![Service and KPI Management](../../images/service-kpi-management.png?width=40vw) +{{% / notice %}} + +**9.** **Enable** をクリックします。数分後に KPI が表示されます。 + +{{% notice style="Info" %}} +有効化アクションを確認します。KPI は数分以内に計算を開始します + +![Enable KPIs](../../images/enable-kpis.png?width=40vw) +{{% / notice %}} + +{{% notice style="Primary" title="お疲れ様でした！" %}} +CSV やルックアップの作成、SPL の記述、サービス依存関係の手動設定を一切行うことなく、すべての Catalyst Center サービスをインポートできました。とても便利ですね！ + +次のセクションに進んで、設定が正しく動作していることを検証しましょう。 +{{% / notice %}} + +{{% /notice %}} diff --git a/content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/3-itsi-validate-configuration.md b/content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/3-itsi-validate-configuration.md new file mode 100644 index 0000000000..2ebf7702de --- /dev/null +++ b/content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/3-itsi-validate-configuration.md @@ -0,0 +1,41 @@ +--- +title: 設定の検証 +linkTitle: 2.3 設定の検証 +weight: 3 +time: 2 minutes +authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] +--- + +インポートしたサービスと KPI が正しく計算されていること、および Catalyst Center からのアラートパイプラインがアクティブであることを確認してから次に進みます。 + +{{% notice title="演習: 設定の検証" style="primary" icon="running" %}} + +**1.** **Service Analyzer** > **Default Service Analyzer** に移動します。 + +インポートしたサービスと、Catalyst Center Site Service Template に含まれる KPI が表示されるはずです。 + +サービスと KPI のヘルスステータスが表示されるまで数分かかる場合があります。 + +{{% notice style="Info" %}} +Service Analyzer には、インポートした Catalyst Center サイトサービスとその現在のヘルスステータスが表示されます + +![ITSI Service Analyzer](../../images/service-analyzer.png?width=40vw) +{{% / notice %}} + +**2.** **Tree** をクリックして **Service Tree** ビューに切り替えます + +**3.** サービスツリーで Store サービスのいずれかをクリックして、Catalyst Center Site に関連付けられた KPI を表示します + +{{% notice style="Info" %}} +サービスをクリックすると、個々の KPI とネットワークレイヤーごとの現在のヘルススコアが表示されます + +![Service KPIs](../../images/service-kpis.png?width=40vw) +{{% / notice %}} + +{{% notice style="Primary" title="おめでとうございます！" %}} +Catalyst Center サービスが ITSI で稼働しています！ + +次のセクションでは、**Inbound Notification Service** を設定します。これにより、ネットワークパフォーマンスの低下を示す Catalyst Center Issue が発生した際に、ITSI で自動的にNotable Event が作成されるようになります。 +{{% / notice %}} + +{{% / notice %}} diff --git a/content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/_index.md b/content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/_index.md new file mode 100644 index 0000000000..ee35e28ebb --- /dev/null +++ b/content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/_index.md @@ -0,0 +1,43 @@ +--- +title: Catalyst Center サービスを ITSI にインポートする +linkTitle: 2. Catalyst Center サービスを ITSI にインポートする +weight: 2 +time: 2 minutes +authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] +--- + +## デバイスヘルスからロケーションベースのネットワーク可視性へ + +従来のネットワーク監視ツールは、個々のデバイスについて報告します（ルーターが稼働しているか停止しているか、スイッチに到達可能かどうかなど）。このレベルの可視性では、*何が*障害を起こしたかはわかりますが、*どこで影響が出ているか*や*ビジネスにとってどの程度深刻か*はわかりません。ブランチオフィスのディストリビューションスイッチが劣化し始めた場合、運用チームはサイト全体が影響を受けていることを把握するために、ツール間でアラートを手動で相関付ける必要があってはなりません。 + +このセクションでは、そのギャップに対処します。**Content Pack for Cisco Enterprise Networks** を使用して Cisco Catalyst Center のトポロジーデータを ITSI にインポートすることで、デバイスのヘルスをサイトレベルまで集約する**ロケーション対応サービスモデル**を作成します。50 個の個別デバイスアラートを監視する代わりに、サイトごとに単一のサービスヘルススコアが表示され、チームは「*現在どのサイトに問題が発生しているか？*」という質問に即座に答えることができます。 + +## Content Pack が重要な理由 + +**Content Pack for Cisco Enterprise Networks**（**Splunk App for Content Packs** から入手可能）は、ここでの重要なイネーブラーです。サービスと KPI を一から手動で構築するのではなく、Content Pack は **Cisco Catalyst Add-on for Splunk** によって既に収集されているトポロジーデータを使用して、Catalyst Center サイトを ITSI サービスとして自動的に検出してインポートします。各サイトがサービスとなり、各サービスにはそのサイト内のすべてのネットワークレイヤーのヘルスを反映する事前構築済み KPI のセットが設定されます。 + +インポートワークフローは Cisco Catalyst Center のサイト階層を読み取り、サイトごとに 1 つの ITSI サービスを作成します。その後、ITSI はエンティティディスカバリーサーチを実行して、適切なデバイス（エンティティ）を各サービスに自動的に関連付けます。手動マッピングは不要です！ + +![Import Catalyst Center Services](../images/review-services.png?width=40vw) + +## Catalyst Center Site サービステンプレート + +この統合の中心にあるのが **Catalyst Center Site** サービステンプレートです。サービスがインポートされると、このテンプレートが各サイトに適用され、そのロケーションにおけるネットワークスタックの異なるレイヤーをそれぞれ追跡する 6 つのすぐに使える KPI が提供されます + +| KPI | 測定内容 | +|---|---| +| **Access Layer** | Access Layer デバイスの平均 HealthScore | +| **Access Points** | Access Point デバイスの平均 HealthScore | +| **Core Layer** | Core Layer デバイスの平均 HealthScore | +| **Distribution Layer** | Distribution Layer デバイスの平均 HealthScore | +| **Router Health** | ルーターの平均 HealthScore | +| **Wireless Controller Health** | Wireless Controller の平均 HealthScore | + +これらの KPI は Cisco Catalyst Center HealthScore から直接取得されます。これは、Catalyst Center がオンボーディング、接続性、および無線周波数のヘルスに基づいて各デバイスに割り当てる 1〜10 のスコアです。ネットワークレイヤーごとにこれらのスコアを平均化することで、ITSI はサイト全体のヘルスを低下させている*スタックのどの部分が原因か*を正確に特定できます。その結果、「サイト X が劣化している」から「サイト X の Access Layer が問題である」への特定が数秒で行えるようになります。 + +## このセクションで行うこと + +このセクションを完了すると、以下が達成されます + +- **Content Pack for Cisco Enterprise Networks** をインストールし、Catalyst Center サイトを ITSI サービスとしてインポートしたこと +- Catalyst Center Site KPI が実際のネットワークヘルスデータで正しく入力されていることを検証したこと diff --git a/content/ja/scenarios/network-event-intelligence/3-configure-catalyst-center-notifications/1-setup-cisco-catalyst-inbound-notifications.md b/content/ja/scenarios/network-event-intelligence/3-configure-catalyst-center-notifications/1-setup-cisco-catalyst-inbound-notifications.md index 1249cdc3b9..fda1808779 100644 --- a/content/ja/scenarios/network-event-intelligence/3-configure-catalyst-center-notifications/1-setup-cisco-catalyst-inbound-notifications.md +++ b/content/ja/scenarios/network-event-intelligence/3-configure-catalyst-center-notifications/1-setup-cisco-catalyst-inbound-notifications.md @@ -6,103 +6,80 @@ time: 5 minutes authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] --- -
-
-ITSI 4.21 には、Cisco Meraki および Catalyst Center アラート用のネイティブデータインテグレーションが含まれています。推奨される方法は、アラートを正規化するために必要な設定が事前に構成されたデフォルトの接続を有効にすることです。デフォルトの構成は、お客様固有のユースケースに合わせてカスタマイズできます。 +ITSI 4.21 には、Cisco Meraki および Catalyst Center アラート用のネイティブデータ統合が含まれています。推奨される方法は、アラートを正規化するために必要な設定が事前構成されているデフォルト接続を有効化することです。デフォルト構成は、お客様固有のユースケースに合わせてカスタマイズできます。 -このセクションでは、ロケーション間でイベントを相関できるようにアラートをカスタマイズし、サービスの正常性が正常に戻ったときにエピソードが自動的に解決されるようにステータスマッピングを更新します。 -
+このセクションでは、ロケーション間でイベントを相関できるようにアラートをカスタマイズし、サービスの健全性が正常に戻ったときにエピソードが自動的に解決されるようにステータスマッピングを更新します。 -{{% notice title="演習: アラートインテグレーションの設定" style="primary" icon="running" %}} +{{% notice title="演習: アラート統合の構成" style="primary" icon="running" %}} **1.** ITSI で、**Configuration** > **Data Integrations** に移動します。 **2.** **Integrations library** の **Alerts** セクションで、**Cisco Catalyst Center** を選択します。 -
{{% notice style="Info" %}} -
-Data Integrations ライブラリの Alerts セクションには、Catalyst Center と Meraki 用の事前構築済み接続が含まれています -
+Data Integrations library の Alerts セクションには、Catalyst Center と Meraki 用の事前構築された接続が含まれています ![Data Integrations](../../images/data-integrations-alerts.png?width=40vw) {{% / notice %}} -
**3.** **+ Add Connection** をクリックします。 -
{{% notice style="Info" %}} -
-カスタム接続を追加すると、サーチ、フィールドマッピング、スロットリングの動作をデフォルトとは独立して制御できます -
+カスタム接続を追加すると、検索、フィールドマッピング、およびスロットリング動作をデフォルトとは独立して制御できます ![Add Connection](../../images/add-connection.png?width=40vw) {{% / notice %}} -
-**4.** 名前に `Catalyst Center Alerts` と入力します。以下のサーチを使用します: +**4.** 名前に `Catalyst Center Alerts` と入力します。以下の検索を使用します ```splunk -index=netops sourcetype="cisco:dnac:issue" -| eval itsi_site = case( isnotnull(SiteNameHierarchy) AND SiteNameHierarchy!="", mvindex(split(SiteNameHierarchy, "/"), 3), isnotnull(DeviceName) AND DeviceName!="", "Store-" . mvindex(split(DeviceName, "-"), 0) ) +index=netops sourcetype="cisco:dnac:issue" +| eval itsi_site = case( isnotnull(SiteNameHierarchy) AND SiteNameHierarchy!="", mvindex(split(SiteNameHierarchy, "/"), 3), isnotnull(DeviceName) AND DeviceName!="", "Store-" . mvindex(split(DeviceName, "-"), 0) ) ``` **5.** **Validate** をクリックします **6.** **Lookback period** を **5 minutes** に設定します -
{{% notice style="Info" %}} -
-検証により、保存前にサーチがイベントを返し、フィールドマッピングが正しいことが確認されます -
+検証により、保存前に検索がイベントを返し、フィールドマッピングが正しいことを確認します ![Validate Connection](../../images/validate-connection.png?width=40vw) {{% / notice %}} -
-**7.** **Source** を **Mapping rule** に更新し、タイプに **Coalesce** を使用します +**7.** **Source** を **Coalesce** タイプの **Mapping rule** に更新します **8.** 最初のフィールドとして `DeviceName` を、2番目のフィールドとして `SiteName` を選択します **9.** **else use the default value** フィールドに `IssueSpecificEntityValue` と入力します -
{{% notice style="Info" %}} -
Source フィールドは、ITSI エピソード内でアラートの発生元を識別するために使用されます -
![Update Source](../../images/cat-center-notification-config-1.png?width=40vw) {{% / notice %}} -
-**10.** **Severity ID** マッピングを **Mapping rule** に更新し、タイプとして **Value case mapping** を使用します +**10.** **Severity ID** マッピングを **Value case mapping** タイプの **Mapping rule** に更新します -**11.** `IssueStatus` **is equal to (not case sensitive)** を `resolved` に設定し、**then use** を `Normal` にします +**11.** `IssueStatus` **is equal to (not case sensitive)** を `resolved` に設定し、**then use** を `Normal` に設定します -**12.** if ステートメントの残りの部分に以下の値をマッピングします: +**12.** 残りの if ステートメントについて、以下の値をマッピングします -`vendor_severity` **is equal to (not case sensitive)** を `P1` に設定し、**then use** を `Critical` にします +`vendor_severity` **is equal to (not case sensitive)** を `P1` に設定し、**then use** を `Critical` に設定します -`vendor_severity` **is equal to (not case sensitive)** を `P2` に設定し、**then use** を `High` にします +`vendor_severity` **is equal to (not case sensitive)** を `P2` に設定し、**then use** を `High` に設定します -`vendor_severity` **is equal to (not case sensitive)** を `P3` に設定し、**then use** を `Medium` にします +`vendor_severity` **is equal to (not case sensitive)** を `P3` に設定し、**then use** を `Medium` に設定します -`vendor_severity` **is equal to (not case sensitive)** を `P4` に設定し、**then use** を `Low` にします +`vendor_severity` **is equal to (not case sensitive)** を `P4` に設定し、**then use** を `Low` に設定します 最後に、**else use this default value** を `Info` に設定します -
{{% notice style="Info" %}} -
-Catalyst Center の重要度の値を ITSI の重要度スケールにマッピングして、エピソードに正しい優先度が表示されるようにします -
+Catalyst Center の重大度値を ITSI の重大度スケールにマッピングして、エピソードに正しい優先度が表示されるようにします ![Severity ID Mapping](../../images/severity-mapping.png?width=40vw) {{% / notice %}} -
**13.** **Title** フィールドを `IssueSpecificSummary` に変更します @@ -110,7 +87,7 @@ Catalyst Center の重要度の値を ITSI の重要度スケールにマッピ **15.** **Run every** を **1 minute** に変更します -**16.** **Service Association** セクションに `NY HQ`、`Store-SJC10`、`Store-SJC12` を追加します +**16.** **Service Association** セクションに `NY HQ`、`Store-SJC10`、および `Store-SJC12` を追加します **17.** **Entity Lookup Field** に `SiteNameHierarchy` を使用します @@ -118,27 +95,20 @@ Catalyst Center の重要度の値を ITSI の重要度スケールにマッピ **19.** **Suppress period** を **5 minutes** ごとに設定します -**20.** 右上の **Preview Results** をクリックします（**注:** プレビューで結果が表示されない場合があります。イベントは **Create a custom NEAP** セクションで確認します） +**20.** 右上の **Preview Results** をクリックします（**注意** プレビューで結果が表示されない場合があります。イベントは **Create a custom NEAP** セクションで確認します） **21.** **Save and Activate** をクリックします -
{{% notice style="Info" %}} -
subcomponent フィールドは、各アラートを ITSI 内の対応する Catalyst Center サイトサービスにリンクするものです -
![Subcomponent Configuration](../../images/subcomponent-config.png?width=40vw) {{% / notice %}} -
-{{% notice style="Primary" title="よくできました！" %}} -
-Catalyst Center のアラートが、正規化されたNotable Eventとしてサイトサービスにリンクされた状態で ITSI に取り込まれるようになりました。 +{{% notice style="Primary" title="お疲れ様でした！" %}} +Catalyst Center アラートが、サイトサービスにリンクされた正規化済みの注目すべきイベントとして ITSI に流入するようになりました。 次のセクションでは、ITSI が両方のベンダーからのイベントを相関できるように、SolarWinds を2番目のアラートソースとして追加します。 -
{{% / notice %}} {{% /notice %}} -
diff --git a/content/ja/scenarios/network-event-intelligence/3-configure-catalyst-center-notifications/_index.md b/content/ja/scenarios/network-event-intelligence/3-configure-catalyst-center-notifications/_index.md new file mode 100644 index 0000000000..b993c4241b --- /dev/null +++ b/content/ja/scenarios/network-event-intelligence/3-configure-catalyst-center-notifications/_index.md @@ -0,0 +1,24 @@ +--- +title: Catalyst Center 通知の設定 +linkTitle: 3. Catalyst Center 通知の設定 +weight: 3 +time: 2 minutes +authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] +--- + +## Catalyst Center アラートを ITSI に取り込む + +Catalyst Center のサービスと KPI が ITSI で稼働している状態で、次のステップはインバウンド通知を設定し、Catalyst Center が生成した Issue と Event を ITSI エピソードに直接取り込むことです。これにより、ロケーションベースの監視を実用的なものにするフィードバックループが構築されます。サイトの KPI ヘルススコアが低下すると、Catalyst Center が Issue を発行し、その Issue は影響を受けたサイトサービスに紐づくノータブルイベントとして ITSI に表示されます。 + +**Cisco Catalyst Add-on for Splunk** がデータの取り込みを処理しますが、アラートの正規化には ITSI 内でインバウンド通知接続を設定する必要があります。Content Pack for Cisco Enterprise Networks には、Catalyst Center 用の構築済みアラートデータ統合テンプレートが含まれており、関連フィールドが自動的にマッピングされるため、セットアップは簡単です。 + +**注:** このセクションでは、ITSI で Catalyst Center インバウンド通知接続のカスタムバージョンを設定し、Catalyst Center からの Issue が Episode Review ページに正規化されたノータブルイベントとして表示されるようにします。 + +![Catalyst Center Notification Configuration](../images/cat-center-notification-config-1.png?width=60vw) + +## このセクションで行うこと + +このセクションを完了すると、以下が達成されます + +- ITSI で **Cisco Catalyst Center** アラート用のカスタムインバウンド通知接続を設定 +- イベントを正しいサイトサービスに関連付けるために必要なアラートフィールドをマッピング diff --git a/content/ja/scenarios/network-event-intelligence/4-configure-solarwinds-notifications/1-solarwinds-content-pack.md b/content/ja/scenarios/network-event-intelligence/4-configure-solarwinds-notifications/1-solarwinds-content-pack.md new file mode 100644 index 0000000000..be8fd07dc1 --- /dev/null +++ b/content/ja/scenarios/network-event-intelligence/4-configure-solarwinds-notifications/1-solarwinds-content-pack.md @@ -0,0 +1,111 @@ +--- +title: Solarwinds Content Pack のインストール +linkTitle: 4.1 Solarwinds Content Pack のインストール +weight: 1 +time: 5 minutes +authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] +--- + +このセクションでは、SolarWinds Content Pack をインストールおよび設定して、SolarWinds アラートを ITSI に取り込みます。これにより、クロスベンダー相関に必要な2ソースのアラートパイプラインが完成します。 + +{{% notice title="演習: Solarwinds Content Pack のインストール" style="primary" icon="running" %}} + +**1.** ITSI で、**Configuration** > **Data Integrations** に移動します。 + +**2.** **Integrations library** の **Alerts** セクションで、**Solarwinds** を選択します。 + +{{% notice style="Info" %}} +SolarWinds Content Pack には、ITSI 用の事前構築済みフィールドマッピングとアラートテンプレートが含まれています + +![Content Pack for Solarwinds](../../images/solarwinds-content-pack.png?width=40vw) +{{% / notice %}} + +**3.** 接続タイトルに `Solarwinds Alerts` と入力します。 + +**4.** 検索に以下の SPL を使用します: + +```text +index=netops sourcetype="solarwinds:alert:hec" +``` + +**5.** **Validate** をクリックします。 + +**6.** **Lookback period** を **5 minutes** に設定します。 + +{{% notice style="Info" %}} +検証により、接続を保存する前に検索が SolarWinds イベントを返していることを確認します + +![Validate Connection](../../images/solarwinds-validate.png?width=40vw) +{{% / notice %}} + +**7.** **Signature** を `title` に設定します。 + +{{% notice style="Info" %}} +Signature フィールドは各アラートタイプを一意に識別し、ITSI 内での重複排除に使用されます + +![Signature](../../images/solarwinds-signature.png?width=40vw) +{{% / notice %}} + +**8.** **Severity ID** のマッピングを、タイプとして **Value case mapping** を使用する **Mapping rule** に更新します + +**9.** `severity_id` **is equal to (not case sensitive)** を `1` に設定し、**then use** を `Normal` に設定します + +**10.** if 文の残りの部分について、以下の値をマッピングします: + +`severity_id` **is equal to (not case sensitive)** を `2` に設定し、**then use** を `Low` に設定します + +`severity_id` **is equal to (not case sensitive)** を `3` に設定し、**then use** を `Medium` に設定します + +`severity_id` **is equal to (not case sensitive)** を `4` に設定し、**then use** を `High` に設定します + +`severity_id` **is equal to (not case sensitive)** を `5` に設定し、**then use** を `Critical` に設定します + +最後に、**else use this default value** を `Info` に設定します + +{{% notice style="Info" %}} +SolarWinds の重要度の値を ITSI の重要度スケールにマッピングして、エピソードに正しい優先度が表示されるようにします + +![Severity ID Mapping](../../images/solarwinds-severity.png?width=40vw) +{{% / notice %}} + +**11.** **subcomponent** を `vendor_region` に更新します。 + +{{% notice style="Info" %}} +subcomponent フィールドは、各 SolarWinds アラートを対応するサイトにリンクし、クロスベンダー相関を可能にします + +![Subcomponent](../../images/solarwinds-subcomponent.png?width=40vw) +{{% / notice %}} + +**12.** **additional fields** を展開し、**description** を `signature` に設定します。 + +{{% notice style="Info" %}} +追加フィールドは、ITSI でエピソードを確認する際に表示される追加のコンテキストを提供します + +![Additional Fields](../../images/solarwinds-additional-fields.png?width=40vw) +{{% / notice %}} + +**13.** スケジュールを **Run Every Minute** に設定します。 + +**14.** **Service Association** セクションに `NY HQ`、`Store-SJC10`、および `Store-SJC12` を追加します + +**15.** **Enable throttling** トグルをオンにします + +**16.** **Suppress period** を **5 minutes** ごとに設定します + +**17.** 右上の **Preview Results** をクリックします（**注意:** プレビューで結果が表示されない場合があります。イベントは **Create a custom NEAP** セクションで確認します） + +**18.** **Save and Activate** をクリックします + +{{% notice style="Info" %}} +保存する前に Preview Results で変換されたフィールドを確認し、マッピングが正しいことを確認します + +![Save and Activate](../../images/solarwinds-save-activate.png?width=40vw) +{{% / notice %}} + +{{% notice style="Primary" title="お疲れ様でした！" %}} +SolarWinds アラートが Catalyst Center イベントとともに ITSI に流入するようになりました。両方のソースが正規化され、相関の準備が整いました。 + +次のセクションでは、両方のベンダーからのアラートをサイトごとに1つのエピソードにグループ化するカスタム NEAP を構築します。 +{{% / notice %}} + +{{% /notice %}} diff --git a/content/ja/scenarios/network-event-intelligence/4-configure-solarwinds-notifications/_index.md b/content/ja/scenarios/network-event-intelligence/4-configure-solarwinds-notifications/_index.md new file mode 100644 index 0000000000..2838eca316 --- /dev/null +++ b/content/ja/scenarios/network-event-intelligence/4-configure-solarwinds-notifications/_index.md @@ -0,0 +1,23 @@ +--- +title: Configure Solarwinds Notifications +linkTitle: 4. Configure Solarwinds Notifications +weight: 4 +time: 5 minutes +authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] +--- + + +## 2つ目のアラートソースの追加 + +このワークショップの重要な目標は、クロスベンダーのアラート相関を実演することです。Cisco Catalyst Center は Cisco インフラストラクチャをカバーしますが、多くのエンタープライズネットワークでは、非 Cisco デバイス、WAN リンク、およびより広範なネットワークヘルスメトリクスを追跡するために、Solarwinds のようなサードパーティ監視ツールにも依存しています。両方のソースが同じサイトまたは同じ時間帯についてアラートを発生させた場合、ITSI はそれぞれに個別のノイズを生成するのではなく、単一のエピソードにグループ化できる必要があります。 + +**Solarwinds Add-on for Splunk** は詳細なアセットコンテキストを提供できますが、このユースケースでは Solarwinds アラートは Splunk HTTP Event Collector に直接配信されます。ITSI には Solarwinds 用のビルトイン統合テンプレートが含まれており、これらのアラートを正規化して、Catalyst Center アラートなどの他のイベントソースと同じ方法で ITSI に認識されるようにします。 + +このセクションでは、**Solarwinds Inbound Notification** 接続を設定し、次のセクションの **Notable Event Aggregation Policy** が相関させる2ソースアラートパイプラインを完成させます。 + +## このセクションで行うこと + +このセクションを完了すると、以下が達成されます + +- **Solarwinds Inbound Notification** 接続を設定し、これらのアラートに対して ITSI に Notable Events を作成します +- Solarwinds アラートが正規化された Notable Events として ITSI に流入していることを確認します diff --git a/content/ja/scenarios/network-event-intelligence/5-create-custom-neap/1-itsi-create-custom-neap.md b/content/ja/scenarios/network-event-intelligence/5-create-custom-neap/1-itsi-create-custom-neap.md new file mode 100644 index 0000000000..d03a698246 --- /dev/null +++ b/content/ja/scenarios/network-event-intelligence/5-create-custom-neap/1-itsi-create-custom-neap.md @@ -0,0 +1,97 @@ +--- +title: ITSI Create Custom NEAP +linkTitle: 5.1 ITSI Create Custom NEAP +weight: 1 +time: 10 minutes +authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] +--- + +前のステップで Catalyst Center と Solarwinds のインバウンド通知ルールを設定したため、まもなくこれらのソースに対してエピソードが生成されるのが確認できるはずです。ITSI がデフォルトの集約ポリシーを適用していることに気づくかもしれません。これはアラートをソース別にグループ化することで迅速な集約価値を提供します。しかし、このデータセットではエピソードをロケーション別にグループ化したいと考えています。これにより、Catalyst Center と SolarWinds のアラート間の相関が可能になり、ITSI イベント管理の差別化機能となります。 + +{{% notice title="演習: カスタム NEAP の作成" style="primary" icon="running" %}} + +**1.** **Alerts and Episodes** に移動します。最近作成されたエピソードを確認します。アラートのグループ化に **Default Aggregation Policy** が使用されていることに注目してください。この環境のブレークシナリオは30分サイクル（15分間正常、15分間異常）で動作しているため、エピソードが表示されるまで最大15分かかる場合があります。 + +{{% notice style="Info" %}} +Alerts and Episodes ビューには、現在のすべてのNotableイベントと、それらがグループ化されたエピソードが表示されます + +![Alerts and Episodes](../../images/alerts-and-episodes.png?width=40vw) +{{% / notice %}} + +**2.** **Configuration** > **Event Management** > **Notable Event Aggregation Policies** に移動します。 + +**3.** 右上隅の **Create Notable Event Aggregation Policy** をクリックします。 + +{{% notice style="Info" %}} +ITSI にはいくつかの組み込みポリシーが含まれています。ここでは、複数のベンダーからのネットワークサイトアラートをグループ化するための新しいポリシーを作成します + +![Create NEAP](../../images/create-neap.png?width=40vw) +{{% / notice %}} + +**4.** **Filtering Criteria and Instructions** で `orig_sourcetype` matches `cisco:dnac:issue` を追加します。 + +**5.** **Add Rule (OR)** をクリックし、`orig_sourcetype` matches `solarwinds:alert:hec` と入力します。 + +**6.** **Group alerts episodes based on...** で `host` を `subcomponent` に置き換えます。 + +**7.** デフォルトの **Break Episode** スタンザを **If the flow of events into the episode is paused for** に置き換え、**600 seconds** を使用します。 + +{{% notice style="info" %}} +ブレーク条件が満たされると、現在のエピソードにはイベントを追加できなくなり、次のNotableイベントで新しいエピソードが開始されます。例: 次のイベントが発生した場合にエピソードをブレーク: message matches **status** `Normal`。このルールは、正常なNotableイベントを受信すると（問題が解決したことを示す）エピソードをブレークします。 +{{% /notice %}} + +{{% notice style="Info" %}} +フィルタリング条件はこのポリシーが適用されるアラートソースを定義し、グループ化フィールドはエピソードの形成方法を決定します + +![Filtering Criteria](../../images/filtering-criteria.png?width=40vw) +{{% / notice %}} + +{{% notice style="info" %}} +IT Service Intelligence (ITSI) の Event iQ は、機械学習アルゴリズムを使用してフィールド値を比較し、Notableイベントをエピソードに相関させます。イベントを相関させるための手動属性を定義する代わりに、グループ化ポリシーで使用する正しい属性を自動的に特定できます。ITSI にアラートをオンボードした後、アラートをフィルタリングする条件を設定し、Event iQ を使用して過去のイベントデータの分析に基づいてイベント相関ポリシーを作成できます。 + +ワークフローで Event iQ を使用すると、自動化されたアラート監視の迅速なセットアップ、アラートノイズの削減、イベントアクションの実行が可能になります。さらに、アルゴリズムは環境のアラートニーズに合わせて継続的にチューニングできます。 +{{% /notice %}} + +**8.** **Episode Information** を展開します。 + +* **Episode Title** を **Static Value** に設定し、`Network Issue Impacting: %subcomponent%` と入力します +* **Episode Severity** を **Same as the highest Severity** に設定します +* 右上の **Next** をクリックします + +{{% notice style="Info" %}} +エピソードタイトルで %subcomponent% を使用すると、このポリシーで作成されるすべてのエピソードに影響を受けるサイト名が自動的に入力されます + +![Episode Information](../../images/episode-information.png?width=40vw) +{{% / notice %}} + +**9.** **Action Rules** を設定します。 + +{{% notice style="info" %}} +集約ポリシー内でアクションルールを設定して、エピソードのアクティベーション条件が満たされたときに自動アクションを実行します。アクションルールはオプションであり、集約ポリシーごとに複数定義できます。 +{{% /notice %}} + +* ルールを追加: If **all event severities are** でドロップダウンから **Normal** を選択し、**60 seconds** と入力します +* Then **Change severity to** でドロップダウンから **Normal** を選択し、**Change status to** > **Resolved** を選択します +* **Next** をクリックします + +{{% notice style="Info" %}} +アクションルールにより、すべての関連アラートが正常に戻ったときにエピソードが自動的に解決され、手動トリアージが削減されます + +![Action Rules](../../images/action-rules.png?width=40vw) +{{% / notice %}} + +**10.** **Policy Title** に `Network Events by Location` と入力します。Status の **Enabled** をクリックします。**Next** をクリックします。 + +{{% notice style="Info" %}} +ポリシーをすぐに有効にして、保存後すぐに受信アラートのグループ化を開始するようにします + +![Policy Title](../../images/policy-title.png?width=40vw) +{{% / notice %}} + +{{% notice style="Primary" title="お疲れ様でした！" %}} +カスタム NEAP がアクティブになりました。同じサイトを共有する Catalyst Center と SolarWinds のアラートは、影響を受けるロケーション名がタイトルに付けられた単一のエピソードにグループ化されます。 + +次のセクションに進み、エンドツーエンドの設定全体を検証しましょう。 +{{% / notice %}} + +{{% /notice %}} diff --git a/content/ja/scenarios/network-event-intelligence/5-create-custom-neap/2-itsi-service-kpi-review.md b/content/ja/scenarios/network-event-intelligence/5-create-custom-neap/2-itsi-service-kpi-review.md new file mode 100644 index 0000000000..872f71eb1f --- /dev/null +++ b/content/ja/scenarios/network-event-intelligence/5-create-custom-neap/2-itsi-service-kpi-review.md @@ -0,0 +1,59 @@ +--- +title: ITSI サービスと KPI のレビュー +linkTitle: 5.2 ITSI サービスと KPI のレビュー +weight: 2 +time: 5 minutes +authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] +--- + +このセクションでは、前のステップで設定したコンテンツパックとアラート統合によって作成されたサービスとエピソードをレビューし、エンドツーエンドのパイプライン全体が正しく動作していることを確認します。 + +{{% notice title="演習: サービスとエピソードのレビュー" style="primary" icon="running" %}} + +{{% notice style="info" %}} +IT Service Intelligence (ITSI) の Service Insights は、組織内のビジネスサービスおよび技術サービスのマッピングと監視を表します。ITSI において、サービスとは組織に特定のサービスを提供するように構成された、相互接続されたアプリケーションとホストのセットです。ITSI Service Insights は、デバイスとアプリケーション間の接続に基づいてサービスの依存関係をマッピングし、問題のあるオブジェクトがサービス運用の残りの部分に与える影響を即座に確認できるようにします。 +{{% /notice %}} + +**1.** **ITSI Service Analyzer** > **Default Service Analyzer** に移動します。インポートしたサービスが表示されるはずです + +**2.** Analyzer の名前を `Network Health by Location` に編集します + +{{% notice style="Info" %}} +Tree ビューは、各 Catalyst Center サイトとその基盤となる KPI の正常性を含む完全なサービス階層を表示します + +![Service Analyzer Tree View](../../images/service-analyzer.png?width=40vw) +{{% / notice %}} + +**3.** 右側の **Tree** をクリックします + +**4.** **Filter Services** に **United States** を追加します + +**5.** 時間範囲を **Last 1 hour** に、**Auto Refresh** を **1 minute** に設定します + +{{% notice style="Info" %}} +United States でフィルタリングし、Auto Refresh を設定することで、すべてのロケーションにわたるサイトの正常性をリアルタイムで表示できます + +![Episode Review](../../images/service-kpis.png?width=40vw) +{{% / notice %}} + +**6.** **Save** をクリックします。表示は以下のグラフィックと同一になるはずです + +**7.** **Alerts and Episodes** をクリックします + +**8.** 最も新しく作成されたエピソードを選択します + +**9.** **Episode details** で、使用された **Aggregation Policy** が前のステップで作成した NEAP であることを確認します + +{{% notice style="Info" %}} +カスタム NEAP によって作成されたエピソードは、Catalyst Center と SolarWinds のアラートを単一のサイト名付きエピソードの下にグループ化します + +![Alerts and Episodes](../../images/episode-review.png?width=40vw) +{{% / notice %}} + +{{% notice style="Primary" title="お疲れ様でした！" %}} +パイプライン全体が確認されました。サービスとその依存関係が設定され、KPI が計算されており、カスタム NEAP がクロスベンダーのアラートをサイトごとにグループ化しています。 + +次のセクションに進んで、このシナリオのウォークスルーを行います。 +{{% / notice %}} + +{{% /notice %}} diff --git a/content/ja/scenarios/network-event-intelligence/5-create-custom-neap/_index.md b/content/ja/scenarios/network-event-intelligence/5-create-custom-neap/_index.md new file mode 100644 index 0000000000..c2d687c150 --- /dev/null +++ b/content/ja/scenarios/network-event-intelligence/5-create-custom-neap/_index.md @@ -0,0 +1,28 @@ +--- +title: カスタム NEAP の作成 +linkTitle: 5. カスタム NEAP の作成 +weight: 5 +time: 10 minutes +authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] +--- + + +## ベンダー間でのアラート相関 + +ネットワークイベントが発生すると、運用チームは何が起きたのか、どこから始まったのか、どのサービスやユーザーが影響を受けているのかを把握するために、接続されていない複数のツールを手動で調査する必要があります。共通の相関レイヤーがなければ、アラートのノイズは多く、調査は遅く、ネットワークインシデントのビジネスへの影響は顧客からの連絡が来るまで見えないままです。 + +ITSI の真の価値は、関連するイベントを **Notable Event Aggregation Policy (NEAP)** を使用して、単一のアクション可能なエピソードに相関させる機能にあります。 + +NEAP は、ITSI がノータブルイベントをグループ化するルールを定義します。このケースでは、同じネットワークサイトに関連する Catalyst Center と SolarWinds の両方からのアラートを単一のエピソードにグループ化することが目標です。これにより、運用チームは調査する場所が1つになり、対応するチケットが1つになり、どのサイトが影響を受けているか、何件のアラートソースが問題を裏付けているかを明確に把握できます。 + +ITSI には事前設定された NEAP が多数含まれていますが、このワークショップではロケーション別にアラートをグループ化することに特に焦点を当てています。このセクションでは、Catalyst Center と SolarWinds のアラートをサイト別に相関させるカスタム NEAP を構築し、サービスの正常性とエピソードの状態を一緒に確認することでポリシーが正しく機能していることを検証します。 + +![Episode Review](../images/episode-review.png?width=40vw) + +## このセクションで行うこと + +このセクションの終了時には、以下が完了しています + +- Catalyst Center と SolarWinds の両方からのアラートをネットワークサイト別にグループ化する**カスタム Notable Event Aggregation Policy** の作成 +- ネットワークの正常性が回復した際のエピソード自動解決の設定 +- Service Analyzer と Episode Review がリアルタイムのサイト正常性を反映していることの検証 diff --git a/content/ja/scenarios/network-event-intelligence/6-scenario-review/_index.md b/content/ja/scenarios/network-event-intelligence/6-scenario-review/_index.md new file mode 100644 index 0000000000..92bb3dd8ec --- /dev/null +++ b/content/ja/scenarios/network-event-intelligence/6-scenario-review/_index.md @@ -0,0 +1,105 @@ +--- +title: シナリオレビュー +linkTitle: 6. シナリオレビュー +weight: 6 +time: 10 minutes +authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] +--- + + +## シナリオ：小売店舗でのネットワーク障害 + +このシナリオは、キャンパス、ブランチ、店舗の拠点を持つ組織を対象としています。ネットワーク障害が発生した場合、運用チームはどのサイトが影響を受けているか、ネットワークのどのコンポーネントが異常であるかを迅速に把握する必要があります。このシナリオウォークスルーでは、ITSI が Cisco Catalyst Center からのデバイスヘルスデータを使用し、他のツール（この場合は Solarwinds）からのアラートと相関させて、数分で問題の全体像を提供する方法を示します。 + +実際の環境では、組織は通常、同じシステムを監視する多くの異なるツールを使用しています。障害が発生すると、すべてのツールがアラートやアラームを発報し始めます。これによりアラートストームが発生し、どこからトラブルシューティングを開始すべきかを理解することが非常に困難になります。その結果、障害解決に大幅な遅延が生じ、運用チーム全体にアラート疲れが蔓延します。 + +ITSI は、サイトおよびネットワークレイヤーごとにネットワークヘルスを把握し、任意の数の異なる監視ソリューションからのアラートを相関させる高度にアクション可能なエピソードを提供することで、この課題に対処します。コンソール間を行き来する代わりに、チームは何が起きているか、どこで起きているか、どのツールのどのアラートが関連しているかを単一のビューで確認できます。 + +## シナリオフロー：Catalyst Center による根本原因分析 + +{{% notice title="シナリオレビュー" style="primary" icon="play" %}} + +**1.** ITSI で **Service Analyzer** を開きます。**Access Points** KPI が劣化したヘルスステータスを示していることを確認します + +{{% notice style="Info" %}} +Service Analyzer は、インポートされたすべての Catalyst Center サイトサービスとその現在のヘルスの概要ビューを提供します + +![Service Analyzer](../images/service-analyzer.png?width=40vw) +{{% / notice %}} + +**2.** 右側の **Tree** を選択して **Service Tree** を表示します + +**3.** **Store-SJC12** サービスを選択して KPI を展開します。**Access Points** KPI が異常であることを確認します。これはこの拠点でワイヤレスの問題が発生していることを示しています + +**4.** **Access Points** KPI を選択してエンティティの詳細にドリルダウンします。この問題がこの拠点の **Floor-1** に影響していることが確認できるはずです + +{{% notice style="Info" %}} +サービスを選択すると、個々の KPI が表示されます。Access Points KPI のヘルススコアが劣化した状態を示しています + +![Store-SJC12 Access Points KPI](../images/service-kpis.png?width=40vw) +{{% / notice %}} + +{{% notice title="ボーナス" style="primary" icon="lightbulb" %}} +**Site Health Summary** リンクを使用してエンティティにドリルダウンし、この店舗のワイヤレスアクセスポイントのヘルスをより詳細に確認します。このダッシュボードは、Catalyst Center から直接取得された個々のデバイスヘルススコアの詳細ビューを提供します。 + +Site Health Summary ダッシュボードは、選択した拠点の個々のアクセスポイントのヘルススコアを表示します + +![Site Health Summary](../images/site-health.png?width=40vw) + +{{% / notice %}} + +**5.** KPI ヘルスの詳細の下にある **Episode Review** セクションを確認します。このサイトに **High** または **Critical** のエピソードが現在オープンされている場合、ここに表示されます。 + +{{% notice style="info" %}} +このシナリオは **Medium** の重大度で始まり、追加のアラートが生成されると **High** にエスカレートします。30分のブレイクサイクルのどの時点にいるかによっては、このリストにまだエピソードが表示されない場合があります。表示されない場合は、次のステップに進み、完全な Alerts and Episodes ビューを確認してください。 +{{% / notice %}} + +現在 **High** または **Critical** のエピソードがない場合は、**Alerts and Episodes** に移動してエピソードの完全なリストを確認します。シナリオの実行時間によっては、このサイトの以前に解決されたエピソードが表示される場合があります。これは、ITSI が根本的な問題が解消された際に、オープンされたエピソードを自動的にクローズし、ステータスを **Resolved** に設定できることを示しています + +**6.** 進行中のエピソードがある場合はそれを選択します。ない場合は、最近解決されたエピソードの1つを選択してレビューします + +**7.** エピソードの詳細で **影響を受けたサービスと KPI** を確認します。このビューは、このエピソード中にどのサービスと KPI が影響を受けたかを正確に示します。 + +{{% notice style="Info" %}} +エピソードの詳細は、アラートを影響を受けたサービスと KPI に紐づけ、ビジネスインパクトの全体像を提供します + +![Episode Review under KPI](../images/ongoing-episode-overview.png?width=40vw) +{{% / notice %}} + +**8.** **Events Timeline** タブを選択して、イベントが発生した順序を確認します + +**9.** **Sort** ドロップダウンから **Root cause analysis** を選択して、イベントを時系列で並べ替えます + +{{% notice style="Info" %}} +Root Cause Analysis でソートされた Events Timeline は、アラートが発報された順序を明らかにし、最初の障害からカスケードする影響への進行を示します + +![Episode Detail](../images/ongoing-episode.png?width=40vw) +{{% / notice %}} + +**10.** リストから個々のアラートを選択して確認します。このエピソードには **Solarwinds** と **Catalyst Center** の両方からのアラートが含まれていることに注目してください。これは、エピソードが前のセクションで作成した **Network Events by Location NEAP** を使用しているためで、ソースに関係なく特定のサイトのすべてのアラートをグループ化します + +{{% notice style="Info" %}} +単一エピソードでのクロスベンダーアラート相関。Catalyst Center と Solarwinds の両方のアラートが拠点ごとにグループ化されています + +![Alert Detail](../images/ongoing-episode-event-view.png?width=40vw) +{{% / notice %}} + +これで、アラートをコンテキスト内で確認し、いつ発生したかを理解し、状況の進展に伴う重大度の変化を追跡できるようになりました。Catalyst Center または Solarwinds からクリアリングイベントが受信されると、アラートの重大度は自動的に **Normal** に変更されます。NEAP で設定したアクションルールにより、すべてのアラートが正常に戻ると、エピソードは自動的に解決され、手動介入なしにループがクローズされます。 + +{{% notice style="Primary" title="ワークショップ完了！" %}} + +**これが重要な理由** + +このワークショップでは、Catalyst Center のトポロジーデータを使用して**拠点ベースのネットワーク可視性**を提供するように ITSI を設定し、**2つの独立した監視ツール**からのアラートを取り込みおよび正規化し、それらのアラートを**サイトごとの単一のアクション可能なエピソード**に相関させるカスタム集約ポリシーを構築しました。 + +その結果、ツール切り替えを排除し、アラートノイズを削減し、運用チームに3つの重要な質問に対する即座の回答を提供するシステムが構築されました*問題はどこにあるか？何が影響を受けているか？状況は改善しているか、悪化しているか？* + +エピソードの作成と解決を自動化することで、ITSI は平均復旧時間を短縮し、チームが切断されたコンソール間で重複するアラートを追いかける代わりに、実際の問題の調査に時間を費やせるようにします。 + +### Happy Splunking + +![Dancing Buttercup](../../../ninja-workshops/11-ingest-processor-for-observability-cloud/images/Splunk-dancing-buttercup-GIF-103.gif?width=40vw) + +{{% / notice %}} + +{{% /notice %}} diff --git a/content/ja/scenarios/network-event-intelligence/_index.md b/content/ja/scenarios/network-event-intelligence/_index.md new file mode 100644 index 0000000000..83feec88d0 --- /dev/null +++ b/content/ja/scenarios/network-event-intelligence/_index.md @@ -0,0 +1,40 @@ +--- +title: Network Event Intelligence with Splunk IT Service Intelligence +linkTitle: Network Event Intelligence +weight: 10 +archetype: chapter +authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] +description: Cisco Catalyst Center と SolarWinds のイベントを Splunk ITSI で相関させ、アラートノイズを削減し、ネットワークインシデントのビジネスへの影響を可視化します。 +time: 30 minutes +--- + +## ようこそ + +このハンズオンワークショップは、Network Event Intelligence のユースケースにおける IT Service Intelligence (ITSI) の力を効果的にデモンストレーションし、ポジショニングしたい方を対象に設計されています。参加者は、潜在的なクライアントに響く実世界のシナリオとユースケースに焦点を当てながら、これらのプラットフォームを統合する実践的な経験を得ることができます。このワークショップでは、Cisco Networking ポートフォリオ全体およびサードパーティ監視ソリューションにおける複数のソースの相関に重点を置いており、ソリューションアーキテクトが Splunk による効果的なネットワークイベント相関という重要な顧客課題への対応を自信を持って紹介できるようになります。 + +## はじめに・概要 + +今日の複雑な IT 環境において、アプリケーションやサービスのパフォーマンスと可用性を確保することは極めて重要です。このワークショップでは、Cisco Catalyst Center、Solarwinds、Splunk Enterprise、および Splunk IT Service Intelligence (ITSI) を含む強力なツールの組み合わせを紹介します。これらのツールが連携することで、包括的な監視およびアラート機能を提供します。 + +### 現代のネットワークオブザーバビリティの課題 + +現代のエンタープライズネットワークは、Cisco Catalyst Center、Meraki、ThousandEyes などの Cisco ソリューションから、SolarWinds、HPE Aruba Networking、Palo Alto Networks などのサードパーティツールまで、拡大し続けるベンダーとプラットフォームの組み合わせにまたがっています。それぞれが独自のフォーマットで、独自のコンソールを通じて、独自のアラートを生成します。ネットワークイベントが発生すると、運用チームは何が起きたのか、どこから始まったのか、どのサービスやユーザーが影響を受けているのかを把握するために、接続されていないツール間を手動で調査しなければなりません。共通の相関レイヤーがなければ、アラートノイズは高くなり、調査は遅くなり、ネットワークインシデントのビジネスへの影響は顧客から問い合わせがあるまで見えないままとなります。 + +### ソリューション: Network Event Intelligence + +包括的な Network Intelligence 戦略には、さまざまなソースからのデータを統合し、それを相関させてアクション可能なインサイトを得ることが必要です。このワークショップでは、Splunk Platform と ITSI がどのように連携してこれを実現するかをデモンストレーションします。 + +* **Cisco Enterprise Networks:** Catalyst Center、Meraki、ThousandEyes などの Cisco Data Fabric からの主要なデータソースを提供します。 + +* **Splunk:** ログ分析およびあらゆるソースからのデータ収集・相関のための中央プラットフォームとして機能し、強力な検索、可視化、および相関機能を実現します。Splunk は IT 環境の全体像を提供します。 + +* **Splunk IT Service Intelligence (ITSI):** 他のすべてのプラットフォームからのデータを相関させることでサービスインテリジェンスを提供します。ITSI では、サービスの定義、依存関係のマッピング、およびサービスの全体的な健全性とパフォーマンスを反映する重要業績評価指標（KPI）の監視が可能です。ITSI は IT の問題による*ビジネスへの影響*を理解するために不可欠です。 + +## ワークショップの目標 + +このワークショップを終了すると、以下の設定が完了します: + +* Cisco Catalyst Center からのデータを使用して、複数のロケーションからネットワークの健全性を監視する ITSI の設定 +* アラートを相関させるための Catalyst Center と Solarwinds の両方からのインバウンド通知の設定 +* Catalyst Center と Solarwinds の両方からの通知を使用した相関エピソードの設定 +* 劣化したサービスの健全性が正常に戻った際にエピソードが自動的に解決される設定 diff --git a/content/ja/scenarios/optimize-end-user-experiences/_index.md b/content/ja/scenarios/optimize-end-user-experiences/_index.md new file mode 100644 index 0000000000..7309ed47f4 --- /dev/null +++ b/content/ja/scenarios/optimize-end-user-experiences/_index.md @@ -0,0 +1,35 @@ +--- +title: Optimize End User Experiences +linkTitle: Optimize End User Experiences +weight: 4 +archetype: chapter +authors: ["Sarah Ware"] +time: 90 minutes +description: Splunk RUM と Synthetics を組み合わせて、実際のユーザーパフォーマンスを測定し、プロアクティブなテストを実行し、重要なフロントエンド KPI にアラートを設定します。 +--- + +Splunk Observability を使用して、エンドユーザーエクスペリエンスに関するインサイトを取得し、エクスペリエンスを改善するためのシナリオをプロアクティブにテストするにはどうすればよいでしょうか？ + +セクション: + +- 可用性とパフォーマンスをすぐに把握するために、基本的な [Synthetic テスト](./1-synthetics/_index.md)を設定する + - Uptime テスト + - API テスト + - Single page Browser テスト +- [RUM](./2-rum/_index.md) を探索して実際のユーザーを理解する +- ユーザーについて学んだことと、ユーザーに行ってほしい操作に基づいて、[高度な Synthetics テスト](./3-advanced-synthetics/_index.md)を作成する +- KPI を把握し、トレンドを表示し、イベントのコンテキストでデータを表示するために、[ダッシュボードチャート](./4-dashboards/_index.md)をカスタマイズする +- KPI にアラートを設定するために [Detectors](./5-detectors/_index.md) を作成する + +{{% notice title="Tip" style="primary" icon="lightbulb" %}}ワークショップ全体を通して以下を念頭に置いてください：エンドユーザーと自分自身/開発者にとって、最速で価値を実現するために、どのように戦略的にアクティビティの優先順位を決めればよいでしょうか？{{% /notice %}} + +## コンテキスト + +念のため確認ですが、エンドユーザーエクスペリエンスを構成するすべての要素をキャプチャするために、フロントエンドのパフォーマンスモニタリングが必要です。バックエンドのみを監視している場合、ユーザーの成功に不可欠な他のすべてのリソースを見逃していることになります。実際の事例については [What the Fastly Outage Can Teach Us About Observability](https://www.splunk.com/en_us/blog/devops/what-the-fastly-outage-can-teach-us-about-observability.html) をお読みください。下の画像をクリックすると拡大できます。 +![What goes into the front end](./images/frontend.png) + +## 参考資料 + +このワークショップでは、エンドユーザーエクスペリエンスをさらに理解し、最適化する方法に関するリソースへの参照が随所に登場します。サポートされている機能については [Splunk Docs](https://docs.splunk.com/observability/en/rum/intro-to-rum.html)、ヒントやコツについては [Lantern](https://lantern.splunk.com/Observability/UCE/Optimized_experiences) に加えて、[Google's web.dev](https://web.dev/) や [Mozilla](https://developer.mozilla.org/en-US/docs/Learn/Performance) も優れたリソースです。 + +使用している特定のライブラリ、プラットフォーム、CDN には、それぞれ独自のリソースがあることも覚えておいてください。例えば、[React](https://react.dev/reference/react/useCallback#skipping-re-rendering-of-components)、[Wordpress](https://wpengine.com/support/troubleshooting-high-time-first-byte-ttfb/)、[Cloudflare](https://community.cloudflare.com/t/improving-time-to-first-byte-ttfb-with-cloudflare/390367) にはそれぞれパフォーマンスを改善するための独自のヒントがあります。 diff --git a/content/ja/scenarios/optimize-monitoring/_index.md b/content/ja/scenarios/optimize-monitoring/_index.md new file mode 100644 index 0000000000..682135bf4e --- /dev/null +++ b/content/ja/scenarios/optimize-monitoring/_index.md @@ -0,0 +1,29 @@ +--- +title: クラウド監視の最適化 +linkTitle: クラウド監視の最適化 +weight: 1 +archetype: chapter +authors: ["Tim Hard"] +description: ハイブリッドクラウド上のITOpsチーム向け — OpenTelemetryによるデータ収集の標準化、チーム間でのダッシュボードとアラートの再利用、メトリクスとログの相関によるMTTRの短縮。 +time: 45 minutes +--- + +クラウドアーキテクチャの弾力性は、監視アーティファクトも同様に弾力的にスケールする必要があることを意味し、専用に構築された監視資産のパラダイムを打破します。その結果、管理オーバーヘッド、可視性のギャップ、技術的負債が急増し、MTTRは遅くなります。これは通常、3つの理由で発生します + +* **複雑で非効率なデータ管理**: インフラストラクチャデータが一貫性のない命名規則で複数のツールに分散し、断片的なビューと不十分なメタデータやラベリングにつながります。複数のエージェントとデータフローの管理が複雑さをさらに増します。 +* **不十分な監視とトラブルシューティング体験**: データの可視化とトラブルシューティングが遅く、個別のダッシュボードと手動の相関で煩雑になり、Kubernetesやサーバーレス関数などの一時的なテクノロジーの監視ツールの不足によりさらに妨げられます。 +* **運用とスケーリングの課題**: 手動のオンボーディング、ユーザー管理、チャージバックプロセス、および広範なデータ要約の必要性が、運用を遅らせ管理タスクを肥大化させ、データ収集とスケーラビリティを複雑にします。 + +これらの課題に対処するには、以下の方法が必要です + +* **データ収集とタグの標準化**: 単一のオープンソースエージェントによる集中監視で、統一された命名規則を適用しメタデータによる可視性を確保します。データ収集を最適化し、monitoring-as-codeアプローチを使用して一貫した収集とタグ付けを実現します。 +* **チーム間でのコンテンツの再利用**: テンプレートと自動化により新しいITインフラストラクチャのオンボーディングとユーザー管理を効率化します。すぐに使えるダッシュボード、アラート、セルフサービスツールを活用してコンテンツの再利用を可能にし、統一された監視を確保して手動作業を削減します。 +* **アラートの適時性の向上**: 高性能なオープンソースのデータ収集と、リアルタイムのストリーミングベースのデータ分析およびアラートを組み合わせて、通知の適時性を向上させます。一般的な問題パターンに対する自動設定アラート（AutoDetect）と、最小限ながら効果的な監視ダッシュボードおよびアラートにより、新たな問題への迅速な対応を確保し、潜在的な障害を最小限に抑えます。 +* **インフラストラクチャメトリクスとログの相関**: インフラストラクチャメトリクスとログのシームレスな相関を可能にすることで、すべてのITインフラストラクチャの完全な監視カバレッジを実現します。高性能なデータ可視化と、データ、ダッシュボード、アラートの単一の信頼できる情報源により、相関プロセスを簡素化し、IT環境のより効果的なトラブルシューティングと分析を可能にします。 + +このワークショップでは、以下の内容を探ります + +* **OpenTelemetry** を使用したデータ収集とタグの標準化方法。 +* チーム間でのコンテンツの再利用方法。 +* アラートの適時性の向上方法。 +* インフラストラクチャメトリクスとログの相関方法。 diff --git a/content/ja/scenarios/self-service-observability/_index.md b/content/ja/scenarios/self-service-observability/_index.md new file mode 100644 index 0000000000..274e5330d3 --- /dev/null +++ b/content/ja/scenarios/self-service-observability/_index.md @@ -0,0 +1,24 @@ +--- +title: Self-Service Observability +linkTitle: Self-Service Observability +weight: 5 +archetype: chapter +time: 1 minute +authors: ["Bill Grant"] +draft: true +description: プラットフォームチーム向け — 収集の標準化、メトリクスコストの管理、Terraform による Observability-as-code の実行により、開発者と SRE がセルフサービスで利用できるようにします。 +--- + +**Splunk Observability Cloud** には、組織内で一貫性、標準、ベストプラクティスを確立する責任を持つプラットフォームチームを支援する強力な機能が含まれています。 + +このワークショップでは、オブザーバビリティの実践に標準化を適用するさまざまな方法を説明します。 + +以下の内容をカバーします + +* 標準に基づいたデータ収集、およびプロセスのさまざまなポイントでのメタデータの適用 +* メトリクスのレビューと Metrics Pipeline Management の適用によるコスト管理 +* Terraform と API を使用した Observability-as-code の構成 + +これらの例を実演するために、さまざまなスクリプトを使用します。同時にワークショップを受講している他の参加者とデータが混在しないよう、一意の名前を選択してください。 + +それでは始めましょう！ diff --git a/content/ja/scenarios/thousandeyes-integration/4-distributed-tracing/1_configure_instrumentation.md b/content/ja/scenarios/thousandeyes-integration/4-distributed-tracing/1_configure_instrumentation.md index b196b5b5dc..960147cc58 100644 --- a/content/ja/scenarios/thousandeyes-integration/4-distributed-tracing/1_configure_instrumentation.md +++ b/content/ja/scenarios/thousandeyes-integration/4-distributed-tracing/1_configure_instrumentation.md @@ -1,14 +1,14 @@ --- title: 分散トレーシングと双方向ドリルダウン -linkTitle: 4.1 インストルメンテーションの設定 +linkTitle: 4.1 計装の設定 weight: 1 time: 10 minutes -description: インストルメンテーションの設定 +description: 計装の設定 --- ## 必要な変更の概要 -[ThousandEyes のドキュメント](https://docs.thousandeyes.com/product-documentation/integration-guides/custom-built-integrations/distributed-tracing)、特に [Splunk Observability APM のページ](https://docs.thousandeyes.com/product-documentation/integration-guides/custom-built-integrations/distributed-tracing/distributed-tracing-splunk-apm) に、分散トレーシングに必要な内容が記載されています。 +[ThousandEyes のドキュメント](https://docs.thousandeyes.com/product-documentation/integration-guides/custom-built-integrations/distributed-tracing)、特に [Splunk Observability APM のページ](https://docs.thousandeyes.com/product-documentation/integration-guides/custom-built-integrations/distributed-tracing/distributed-tracing-splunk-apm) に、分散トレーシングに必要な設定が記載されています。 Propagators について: @@ -18,19 +18,19 @@ Propagators について: さらに、sampler を `parentbased_always_on` に設定することで、ThousandEyes がリクエストを開始した後もトレースが継続されます。 -{{% notice title="重要なポイント" style="warning" %}} -テストの結果（少なくともこの執筆時点では）、propagators の順序が重要であり、デフォルトの順序では動作しないことが確認されています。そのため、正しい順序にパッチを適用する必要があります。 +{{% notice title="重要な注意点" style="warning" %}} +テスト（少なくとも本稿執筆時点）において、propagators の順序が重要であり、デフォルトの順序では動作しないことを確認しています。そのため、正しい順序にパッチを適用する必要があります。 {{% /notice %}} 以下の変更を行います: - ステップ 1: OTel Collector の変更 - - インストルメンテーションに正しい順序の propagators (`baggage`, `b3`, `tracecontext`) をパッチします -- ステップ 2: アプリケーションのパッチ - - サービスに Java インストルメンテーションを注入するためのパッチを適用します + - propagators の正しい順序（`baggage`、`b3`、`tracecontext`）で instrumentation にパッチを適用します +- ステップ 2: アプリケーションへのパッチ + - サービスに Java instrumentation を注入するためのパッチを適用します ### ステップ 1: OTel Collector の変更 -インストルメンテーションの設定を確認しましょう: +instrumentation の設定を確認しましょう: {{< tabs >}} {{% tab title="Script" %}} @@ -59,9 +59,9 @@ Spec: {{% /tab %}} {{< /tabs >}} -`Propagators` の下に必要なものが設定されていることが確認できますが、正しい順序にするためにパッチを適用します。 +`Propagators` の下に必要なものが設定されていることがわかりますが、正しい順序にするためにパッチを適用します。 -### ステップ 2: インストルメンテーションのパッチ（デフォルトの解決） +### ステップ 2: instrumentation へのパッチ（デフォルトの解決） ここではパッチで対応しますが、将来のアップグレードでこの変更は失われます。正しい方法は `values.yaml` ファイルを更新して、常にこの設定が適用されるようにすることです。 @@ -91,7 +91,7 @@ instrumentation.opentelemetry.io/splunk-otel-collector patched {{% /tab %}} {{< /tabs >}} -Propagators が正しい順序になっていること、および sampler が追加されていることを確認できます: +Propagators（正しい順序）と追加された sampler が設定されていることを確認できます: {{< tabs >}} {{% tab title="Script" %}} @@ -122,7 +122,7 @@ Spec: {{% /tab %}} {{< /tabs >}} -### ステップ 3: アプリケーションのパッチ +### ステップ 3: アプリケーションへのパッチ まず、デプロイされているコンテナイメージを確認しましょう: @@ -143,9 +143,9 @@ kubectl describe pods api-gateway | grep Image: {{% /tab %}} {{< /tabs >}} -`api-gateway` にはコンテナが1つだけあることが確認できます。アプリケーションにパッチを適用すると、複数のコンテナイメージ（api-gateway 用とインストルメンテーション用）が表示されるようになります。 +`api-gateway` にはコンテナが 1 つだけあることがわかります。アプリケーションにパッチを適用すると、複数のコンテナイメージ（api-gateway 用と instrumentation 用）が表示されるようになります。 -Java インストルメンテーションを注入しましょう。（注意: `config-server`、`discovery-server`、`admin-server` は既にパッチが適用されているため、変更はありません。）: +Java instrumentation を注入しましょう。（注意: `config-server`、`discovery-server`、`admin-server` は既にパッチが適用されているため変更はありません。）: {{< tabs >}} {{% tab title="Script" %}} @@ -171,7 +171,7 @@ deployment.apps/visits-service patched {{% /tab %}} {{< /tabs >}} -{{% notice title="他のランタイムの場合" style="info" %}} +{{% notice title="他のランタイムについて" style="info" %}} 他のランタイムの場合は、言語に対応するアノテーションを使用してください。例: - `instrumentation.opentelemetry.io/inject-nodejs` @@ -179,7 +179,7 @@ deployment.apps/visits-service patched - `instrumentation.opentelemetry.io/inject-dotnet` {{% /notice %}} -インストルメンテーションがデプロイされたことを確認できます: +instrumentation がデプロイされたことを確認できます: {{< tabs >}} {{% tab title="Script" %}} @@ -198,7 +198,7 @@ kubectl describe pods api-gateway | grep Image: {{% /tab %}} {{< /tabs >}} -また、この Pod で Java インストルメンテーションが有効になっており、propagators に `baggage`、`b3`、`tracecontext` が正しい順序で含まれていることも確認できます: +また、この Pod で Java instrumentation が有効になっており、propagators に `baggage`、`b3`、`tracecontext` が正しい順序で含まれていることも確認できます: {{< tabs >}} {{% tab title="Script" %}} @@ -218,14 +218,14 @@ kubectl describe pods api-gateway | grep OTEL_PROPAGATORS {{< /tabs >}} {{% notice title="すべての Pod を再起動" style="warning" %}} -一部の Pod には既にインストルメンテーションが注入されているため、正しいインストルメンテーションを適用するにはすべてを再起動することが重要です。 +一部の Pod には既に instrumentation が注入されているため、正しい instrumentation を適用するにはすべての Pod を再起動することが重要です。 -以下を実行します: +再起動するには: {{< tabs >}} {{% tab title="Script" %}} ```bash -kubectl rollout restart deployment +kubectl rollout restart deployment -l app.kubernetes.io/part-of=spring-petclinic ``` {{% /tab %}} @@ -276,7 +276,7 @@ kubectl run te-petclinic-curl \ {{< /tabs >}} {{% notice title="お待ちください" style="warning" %}} -期待される出力が得られるまで、しばらく時間がかかる場合があります。 +期待される出力が得られるまでに時間がかかる場合があります。 {{% /notice %}} デプロイメント環境は以下の通りです: diff --git a/content/ja/scenarios/thousandeyes-integration/4-distributed-tracing/3_create_tests.md b/content/ja/scenarios/thousandeyes-integration/4-distributed-tracing/3_create_tests.md index 5f497674b6..c957c7ec5f 100644 --- a/content/ja/scenarios/thousandeyes-integration/4-distributed-tracing/3_create_tests.md +++ b/content/ja/scenarios/thousandeyes-integration/4-distributed-tracing/3_create_tests.md @@ -8,12 +8,12 @@ description: テストの作成 ## 概要 -ここでは、このインテグレーションを実証するためのテストを作成します。 +ここでは、この統合を実演するためのテストを作成します。 3つのテストを作成します -* ThousandEyes エージェント（クラスター内部）からのテスト。アプリケーションがパブリックインターネットからアクセスできない場合に有用です -* より興味深いトレース（クラスター内部） +* ThousandEyes エージェントからのテスト（クラスター内部）。アプリケーションがパブリックインターネットからアクセスできない場合に便利です +* より詳細なトレース（クラスター内部） * パブリックインターネットからのテスト。パブリック URL と ThousandEyes Cloud Agent を使用します ### ステップ 1: HTTP テスト（Kubernetes クラスター内） @@ -26,44 +26,38 @@ description: テストの作成 * **How often test runs**: 10 minutes * **Agents**: `Enterprise Agents` タブを選択し、このガイドの前のステップでデプロイしたエージェントを選択します * **Enable distributed tracing**: 有効にします -* **Verify Content**: オプションです。返されるページコンテンツを検証したい場合は `PetClinic` を使用します。 +* **Verify Content**: オプションです。返されるページコンテンツを検証する場合は `PetClinic` を使用します。 ![ThousandEyes Script Settings](../../images/test-distributed-tracing.png?width=20vw) 4. **Instant Test** をクリックします {{% notice title="Instant Test" style="info" %}} -これにより新しいタブが開き、テストは保存されませんのでご注意ください。 +これにより新しいタブが開き、テストは保存されません。この点にご注意ください。 {{% /notice %}} 6. **Service Map** タブに切り替えます -ThousandEyes でサービスマップビューが表示されるまで少し時間がかかる場合がありますが、Splunk Observability Cloud でトレースを確認できるはずです。 +ThousandEyes でサービスマップビューが表示されるまで少し時間がかかる場合がありますが、Splunk Observability Cloud でトレースを見つけることができるはずです。 7. トレースをコピーします 8. Splunk Observability Cloud で、**APM > Trace Analyzer** に移動し、トレースを貼り付けて **Go** をクリックします -最終的に、以下のような表示が確認できるはずです +最終的に、以下のような画面が表示されるはずです ![Test 1 - ThousandEyes](../../images/test1-te.png?width=35vw) ![Test 1 - APM](../../images/test1-apm.png?width=35vw) -### ステップ 2: HTTP テスト（Kubernetes クラスター内）- より興味深いトレース +### ステップ 2: HTTP テスト（Kubernetes クラスター内）- より詳細なトレース ステップ 1 を繰り返しますが、URL には `http://api-gateway.default.svc.cluster.local:82/api/customer/owners`（Owners List）を使用します。 -同じテストを編集して、Instant Test を実行できます。 +先ほど作成したテストを編集し、Instant Test を実行できます。 -より興味深いマップが得られるはずです。 +より詳細なマップが得られるはずです。 ![Test 2 - ThousandEyes](../../images/test2-te.png?width=35vw) ![Test 2 - APM](../../images/test2-apm.png?width=35vw) -{{% notice title="ThousandEyes の失敗" style="note" %}} +{{% notice title="ThousandEyes Failure" style="note" %}} ThousandEyes でテストが失敗していることに気づきましたか？これは、Owners List に基づいて **Verify Content** を変更しなかったためです。 ![Test 2 - ThousandEyes Verify Content Failure](../../images/test2-te-fail.png?width=20vw) {{% /notice %}} - -### ステップ 3: HTTP テスト（パブリック） - -最後に、パブリックインターネットからこのページにアクセスできるか確認しましょう。 - -XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX diff --git a/content/ja/scenarios/thousandeyes-integration/_index.md b/content/ja/scenarios/thousandeyes-integration/_index.md index e7102fc8f7..88a38c6c39 100644 --- a/content/ja/scenarios/thousandeyes-integration/_index.md +++ b/content/ja/scenarios/thousandeyes-integration/_index.md @@ -1,26 +1,26 @@ --- -title: ThousandEyes Integration with Splunk Observability Cloud +title: ThousandEyes と Splunk Observability Cloud の統合 linkTitle: ThousandEyes Integration weight: 5 archetype: chapter authors: ["Alec Chamberlain"] time: 120 minutes -description: Kubernetes に ThousandEyes Enterprise Agent をデプロイし、シンセティックデータを Splunk Observability Cloud にストリーミングし、ThousandEyes と Splunk APM 間の双方向ドリルダウンを有効にします。 +description: Kubernetes で ThousandEyes Enterprise Agent を実行し、シンセティクスを Splunk Observability Cloud にストリーミングし、ThousandEyes テストと Splunk APM トレース間を横断的に分析します。 --- -このワークショップでは、**ThousandEyes と Splunk Observability Cloud** を統合し、シンセティックモニタリングとオブザーバビリティデータ全体にわたる統一的な可視性を提供する方法を紹介します。 +このワークショップでは、**ThousandEyes と Splunk Observability Cloud** を統合し、シンセティックモニタリングとオブザーバビリティデータ全体にわたる統一的な可視性を提供する方法を説明します。 ## 学習内容 このワークショップを完了すると、以下のことができるようになります - ThousandEyes Enterprise Agent をコンテナ化されたワークロードとして Kubernetes にデプロイする -- 付属の Spring PetClinic アプリケーションを内部 Kubernetes テストターゲットとしてデプロイする +- 付属の Spring PetClinic アプリケーションを Kubernetes 内部のテストターゲットとしてデプロイする - OpenTelemetry を使用して ThousandEyes メトリクスを Splunk Observability Cloud と統合する - ThousandEyes と Splunk APM が同じリクエストにリンクできるように分散トレーシングを設定する -- 内部 Kubernetes サービスおよび外部依存関係に対するシンセティックテストを作成する +- Kubernetes 内部サービスおよび外部依存関係に対するシンセティックテストを作成する - Splunk Observability Cloud ダッシュボードでテスト結果を監視する -- ThousandEyes から Splunk APM トレースに移動し、元の ThousandEyes テストに戻る +- ThousandEyes から Splunk APM トレースへ移動し、元の ThousandEyes テストに戻る ## セクション @@ -34,30 +34,30 @@ description: Kubernetes に ThousandEyes Enterprise Agent をデプロイし、 ### シナリオ拡張 - [Kubernetes テスト](./4-kubernetes-testing/_index.md) - シンセティックモニタリングとトレース相関の両方に役立つ内部テストを作成する -- [RUM](./6-rum-thousandeyes/_index.md) - ThousandEyes のネットワークシグナルと Splunk RUM を相関させてエンドユーザー調査を行う +- [RUM](./6-rum-thousandeyes/_index.md) - ThousandEyes のネットワークシグナルと Splunk RUM を相関させ、エンドユーザー調査に活用する ### サポート - [トラブルシューティング](./5-troubleshooting/_index.md) - よくある問題と解決策 {{% notice title="Tip" style="primary" icon="lightbulb" %}} -このシナリオは2つの連携した統合と考えてください：OpenTelemetry ストリームが ThousandEyes メトリクスを Splunk に取り込み、分散トレーシングが Splunk APM から ThousandEyes への逆方向のパスを提供します。 +このシナリオは2つの接続された統合として考えてください：OpenTelemetry ストリームが ThousandEyes メトリクスを Splunk に取り込み、分散トレーシングが Splunk APM から ThousandEyes への逆方向のパスを提供します。 {{% /notice %}} ## 前提条件 - Kubernetes クラスター（v1.16+） -- 選択した namespace にリソースをデプロイするための RBAC 権限（注：このワークショップでは default namespace を使用します） -- Enterprise Agent トークンへのアクセス権を持つ ThousandEyes アカウント -- インジェストトークンへのアクセス権と APM ルックアップ用の API トークンを作成する権限を持つ Splunk Observability Cloud アカウント +- 選択した名前空間にリソースをデプロイするための RBAC 権限（注：このワークショップでは default 名前空間を使用します） +- Enterprise Agent トークンにアクセスできる ThousandEyes アカウント +- インジェストトークンへのアクセスと APM ルックアップ用の API トークンを作成する権限を持つ Splunk Observability Cloud アカウント ## 統合のメリット ThousandEyes を Splunk Observability Cloud に接続することで、以下のメリットが得られます -- 🔗 **統一的な可視性**：シンセティックテスト結果を RUM、APM トレース、インフラストラクチャメトリクスと相関させる -- 📊 **強化されたダッシュボード**：既存の Splunk オブザーバビリティメトリクスと並べて ThousandEyes データを可視化する -- 🔄 **双方向ドリルダウン**：ThousandEyes Service Map から Splunk トレースに移動し、Splunk APM からリクエストを生成した ThousandEyes テストに戻る -- 🚨 **一元化されたアラート**：Splunk 内で ThousandEyes テスト結果に基づいてアラートを設定する -- 🔍 **根本原因分析**：問題がネットワーク関連（ThousandEyes）かアプリケーション関連（APM）かを迅速に特定する -- 📈 **包括的な分析**：Splunk の強力な分析エンジンでシンセティックモニタリングのトレンドを分析する +- 🔗 **統一的な可視性**: シンセティックテスト結果を RUM、APM トレース、インフラストラクチャメトリクスと相関させる +- 📊 **強化されたダッシュボード**: 既存の Splunk オブザーバビリティメトリクスと並べて ThousandEyes データを可視化する +- 🔄 **双方向ドリルダウン**: ThousandEyes Service Map から Splunk トレースへ、また Splunk APM からリクエストを生成した ThousandEyes テストへ移動する +- 🚨 **一元化されたアラート**: Splunk 内で ThousandEyes テスト結果に基づいたアラートを設定する +- 🔍 **根本原因分析**: 問題がネットワーク関連（ThousandEyes）かアプリケーション関連（APM）かを迅速に特定する +- 📈 **包括的な分析**: Splunk の強力な分析エンジンでシンセティックモニタリングのトレンドを分析する diff --git a/content/ja/splunk4rookies/_index.md b/content/ja/splunk4rookies/_index.md index 3d25d88106..f1808be954 100644 --- a/content/ja/splunk4rookies/_index.md +++ b/content/ja/splunk4rookies/_index.md @@ -1,8 +1,10 @@ ---- -title: Splunk4Rookies ワークショップ -menuPost: " " -weight: 1 -description: 以下は初心者向けワークショップです。 ---- ++++ +title = "Splunk4*Rookies*." +weight = "1" +description = "Splunk Observability Cloud を初めてお使いですか？ここから始めましょう。これらの短いガイド付きワークショップでは、事前の経験を前提とせずにプラットフォーム全体をエンドツーエンドで体験できます。" +layout = "default" +[params] + images = ["images/s4r-featured.png"] ++++ -{{% children depth="1" description="true" %}} +{{% children type="card" description="true" image="true" %}} diff --git a/content/ja/splunk4rookies/financial-services-observability-cloud/3-quick-tour/_index.md b/content/ja/splunk4rookies/financial-services-observability-cloud/3-quick-tour/_index.md new file mode 100644 index 0000000000..4ac7fac382 --- /dev/null +++ b/content/ja/splunk4rookies/financial-services-observability-cloud/3-quick-tour/_index.md @@ -0,0 +1,14 @@ +--- +title: UI - Quick Tour 🚌 +linkTitle: 3. UI - Quick Tour +weight: 3 +archetype: chapter +description: Splunk Observability Cloud UIのクイックツアーです。 +--- + +Splunk Observability Cloudのさまざまなコンポーネントについて、短いウォークスルーから始めます。これはUIに慣れていただくことを目的としています。 + +1. **Splunk Observability Cloudへのサインイン** +2. **Application Performance Monitoring (APM)** +3. **Infrastructure Monitoring** +4. **Log Observer** diff --git a/content/ja/splunk4rookies/financial-services-observability-cloud/_index.md b/content/ja/splunk4rookies/financial-services-observability-cloud/_index.md new file mode 100644 index 0000000000..eb32f8f715 --- /dev/null +++ b/content/ja/splunk4rookies/financial-services-observability-cloud/_index.md @@ -0,0 +1,31 @@ +--- +title: Finserv Observability Cloud +weight: 3 +authors: ["Robert Castley", "Pieter Hagen", "Jeremy Hicks", "Deepti Bhutani"] +time: 30 minutes +aliases: + - /en/s4r/ +description: 金融サービスチーム向け。Splunk Observability Cloud が FSI デジタルエコシステム全体にリアルタイムの可視性を提供する方法を、30分のハンズオンセッションでご覧いただけます。 +params: + images: + - /images/featured.png +--- + +このワークショップでは、Splunk Observability Cloud が金融サービスのお客様にどのような価値を提供するかをデモンストレーションします。インフラストラクチャからアプリケーション、ユーザーエクスペリエンスに至るまで、デジタルエコシステム全体にわたるリアルタイム、フルフィデリティ、AI を活用したモニタリングを提供する能力により、価値を実現します。モダンなクラウドネイティブのマイクロサービスベース環境向けに専用設計されています。他のオブザーバビリティソリューションとは一線を画す、プラットフォームの最も強力な機能をいくつか体験していただけます + +- **Infrastructure Monitoring** +- **NoSample Full-fidelity Application Performance Monitoring (APM) による完全なエンドツーエンドのトレース可視性** +- **ノーコードのログクエリ** +- **タグ分析とエラースタックによる根本原因分析** +- **コンポーネント間のシームレスなナビゲーションを実現する Related Content** + +Splunk Observability Cloud の中核的な強みの一つは、テレメトリデータを統合し、エンドユーザーエクスペリエンスとアプリケーションスタック全体の包括的な全体像を作成する能力です。 + +このワークショップでは、Kubernetes 上にデプロイされたマイクロサービスベースの送金アプリケーションに焦点を当てます。ユーザーは送金を開始でき、ユーザー確認、残高確認、コンプライアンスチェックなど、すべての適切なチェックが処理されます。このアプリケーションは OpenTelemetry で完全に計装されており、詳細なパフォーマンスデータをキャプチャします。 + +**OpenTelemetry とは？** +OpenTelemetry は、メトリクス、トレース、ログなどのテレメトリデータの計装、生成、収集、エクスポートを支援するために設計されたオープンソースのツール、API、ソフトウェア開発キット（SDK）のコレクションです。このデータにより、ソフトウェアのパフォーマンスと動作を詳細に分析することができます。 + +OpenTelemetry コミュニティは急速に成長しており、Splunk、Google、Microsoft、Amazon などの大手企業がサポートしています。現在、Cloud Native Computing Foundation において Kubernetes に次いで2番目に多いコントリビューター数を誇っています。 + +![Full Stack](images/featured.png) diff --git a/content/ja/splunk4rookies/observability-cloud-short/_index.md b/content/ja/splunk4rookies/observability-cloud-short/_index.md new file mode 100644 index 0000000000..ebcd9c4659 --- /dev/null +++ b/content/ja/splunk4rookies/observability-cloud-short/_index.md @@ -0,0 +1,29 @@ +--- +title: Observability Cloud (1 hour) +weight: 2 +authors: ["Robert Castley", "Pieter Hagen"] +time: 60 minutes +description: 短縮版。完全に計装された Kubernetes マイクロサービスアプリに対するハンズオントラブルシューティング — Splunk Observability Cloud の本質的な体験を1時間で。 +params: + images: + - images/featured-o11y.png +difficulty: Rookie +--- + +## はじめに + +Splunk Observability Cloud を使用した問題のトラブルシューティングをハンズオンで体験します。Kubernetes 上で完全に計装されたマイクロサービスアプリケーションを使用し、メトリクス、トレース、ログをリアルタイムで分析します。 + +## ワークショップの概要 + +この1時間のハンズオンセッションでは、以下の内容をカバーします + +- **実際のユーザーデータの生成** - Online Boutique ウェブサイトを閲覧して、メトリクス、トレース、ログを生成します +- **RUM** - パフォーマンスの低いブラウザセッションを特定し、トラブルシューティングを開始します +- **APM** - フロントエンドの RUM トレースをバックエンドの APM トレースにリンクし、異常やエラーを検出します +- **Log Observer** - 「Related Content」を使用して、APM トレースから関連するログに移動します +- **Synthetics** - 毎分実行される Synthetic テストで24時間365日のモニタリングを設定します + +![Full Stack](images/featured-o11y.png) + +**さあ、ショッピングに行きましょう！** diff --git a/content/ja/splunk4rookies/observability-cloud/3-quick-tour/_index.md b/content/ja/splunk4rookies/observability-cloud/3-quick-tour/_index.md index 51401b6782..e115732bc2 100644 --- a/content/ja/splunk4rookies/observability-cloud/3-quick-tour/_index.md +++ b/content/ja/splunk4rookies/observability-cloud/3-quick-tour/_index.md @@ -1,23 +1,16 @@ --- -title: UI - クイックツアー 🚌 -linkTitle: 3. UI - クイックツアー +title: UI - Quick Tour 🚌 +linkTitle: 3. UI - Quick Tour weight: 3 archetype: chapter description: Splunk Observability Cloud UIのクイックツアー --- -Splunk Observability Cloudの様々なコンポーネントについて簡単な説明から始めます。これはUIに慣れてもらうことを目的としています。 +Splunk Observability Cloud のさまざまなコンポーネントについて、簡単なウォークスルーから始めます。これは UI に慣れていただくことを目的としています。 1. **Splunk Observability Cloud へのサインイン** 2. **Real User Monitoring (RUM)** 3. **Application Performance Monitoring (APM)** 4. **Log Observer** 5. **Synthetics** -6. **Infrastructure Monitoring（IM）** - -{{% notice title="ヒント" style="primary" icon="lightbulb" %}} -このワークショップを進める最も簡単な方法は以下を使用することです: - -- このページの右上にある左右の矢印（**<** | **>**） -- キーボードの左（◀️）と右（▶️）のカーソルキー - {{% /notice %}} +6. **Infrastructure Monitoring** diff --git a/content/ja/splunk4rookies/observability-cloud/_index.md b/content/ja/splunk4rookies/observability-cloud/_index.md index 6e576d7dc6..cf8748b69c 100644 --- a/content/ja/splunk4rookies/observability-cloud/_index.md +++ b/content/ja/splunk4rookies/observability-cloud/_index.md @@ -1,31 +1,33 @@ --- -title: Observability Cloud +title: Observability Cloud (3 hours) weight: 1 authors: ["Robert Castley", "Pieter Hagen"] -time: 2 minutes +time: 90 minutes aliases: - - /ja/s4r/ -description: このワークショップでは、Splunk Observability Cloudがフロントエンドアプリケーションからバックエンドサービスまで、ユーザー体験の視点からどのように即座に可視性を提供するかをお見せします - Splunk Observability Cloudの最も魅力的な機能と差別化要因を体験していただきます。 + - /en/s4r/ +description: 3時間のハンズオンワークショップです。ライブのマイクロサービスアプリケーションを使用して、Splunk Observability Cloud プラットフォームをエンドツーエンドで探索し、他のオブザーバビリティツールとの差別化機能を確認します。 +params: + images: + - /images/featured.png --- -このワークショップでは、Splunk Observability Cloudがフロントエンドアプリケーションからバックエンドサービスまで、ユーザー体験に関する即時の可視性をどのように提供するかをデモンストレーションします。他の可観測性ソリューションと一線を画す、プラットフォームの最も強力な機能をいくつか体験していただきます +このワークショップでは、Splunk Observability Cloud がフロントエンドアプリケーションからバックエンドサービスまで、ユーザーエクスペリエンスに対する即時の可視性をどのように提供するかを実演します。他のオブザーバビリティソリューションとの差別化を実現するプラットフォームの強力な機能を探索する機会があります -- **インフラ監視（Infrastructure Monitoring, IM）** -- **完全で忠実な Real User Monitoring（RUM）** -- **Application Performance Monitoring（APM）による End to End の NoSample で完全忠実なトレースの可視性** -- **コード入力を必要としないログクエリ** -- **外形監視・合成監視（Synthetic Monitoring）** -- **タグ分析とエラースタックによる根本原因分析** -- **Related Contents によるコンポーネント間のシームレスなナビゲーション** +- **Infrastructure Monitoring** +- **Full-fidelity Real User Monitoring (RUM)** +- **NoSample Full-fidelity Application Performance Monitoring (APM) による完全なエンドツーエンドのトレース可視性** +- **ノーコードログクエリ** +- **Synthetic Monitoring** +- **タグ分析とエラースタックによる根本原因分析** +- **Related Content** によるコンポーネント間のシームレスなナビゲーション -Splunk Observability Cloudのコアとなる強みの一つは、テレメトリデータを統合し、エンドユーザーエクスペリエンスとアプリケーションスタック全体の包括的な全体像を作成する能力です。 +Splunk Observability Cloud の核となる強みの一つは、テレメトリデータを統合し、エンドユーザーエクスペリエンスとアプリケーションスタック全体の包括的な全体像を作成できることです。 -このワークショップでは、AWS EC2インスタンス上にデプロイされたマイクロサービスベースのeコマースアプリケーションに焦点を当てます。ユーザーは商品を閲覧し、カートに商品を追加し、注文を完了できます。このアプリケーションは、詳細なパフォーマンスデータを取得するためにOpenTelemetryで計装されています。 +このワークショップでは、AWS EC2 インスタンス上にデプロイされたマイクロサービスベースの e コマースアプリケーションに焦点を当てます。ユーザーは商品を閲覧し、カートにアイテムを追加し、購入を完了することができます。このアプリケーションは、詳細なパフォーマンスデータをキャプチャするために OpenTelemetry で完全に計装されています。 -**OpenTelemetry とは？** +**OpenTelemetry とは？** +OpenTelemetry は、メトリクス、トレース、ログなどのテレメトリデータの計装、生成、収集、エクスポートを支援するために設計されたオープンソースのツール、API、ソフトウェア開発キット（SDK）のコレクションです。このデータにより、ソフトウェアのパフォーマンスと動作の詳細な分析が可能になります。 -[OpenTelemetry](https://opentelemetry.io/) は、メトリクス、トレース、ログなどのテレメトリデータの計装、生成、収集、エクスポートを支援するために設計されたオープンソースのツール、API、ソフトウェア開発キット（SDK）のコレクションです。このデータにより、ソフトウェアのパフォーマンスと動作の詳細な分析が可能になります。 +OpenTelemetry コミュニティは急速に成長しており、Splunk、Google、Microsoft、Amazon などの主要企業によってサポートされています。現在、Cloud Native Computing Foundation 内で Kubernetes に次いで2番目に多いコントリビューター数を誇っています。 -OpenTelemetryコミュニティは急速に成長しており、Splunk、Google、Microsoft、Amazonなどの大手企業からのサポートを受けています。現在、Cloud Native Computing Foundationにおいて、Kubernetesに次いで2番目に多くのコントリビューターを抱えています。 - -![Full Stack](images/splunk-full-stack.png) +![Full Stack](images/featured.png) diff --git a/content/ja/unsupported-field-workshops/_index.md b/content/ja/unsupported-field-workshops/_index.md new file mode 100644 index 0000000000..2c1e3fd36d --- /dev/null +++ b/content/ja/unsupported-field-workshops/_index.md @@ -0,0 +1,11 @@ +--- +title: サポート対象外フィールドワークショップ +linkTitle: サポート対象外フィールドワークショップ +description: Splunk フィールドエンジニアによるハンズオンワークショップです。公式サポートではなくコミュニティによって維持されていますが、APM、IM、OnCall、Lambda トレーシングなど幅広い製品を深くカバーしています。 +weight: 20 +params: + images: + - ../images/featured-unsupported.jpg +--- + +{{% children type="card" description="true" %}}