このワークショップでは、以下の内容をハンズオン形式で体験します：
それでは始めましょう！
このワークショップを最も簡単にナビゲートする方法は以下の通りです：
各参加者用にAWS/EC2でUbuntu Linuxインスタンスを準備しています。インストラクターから提供されたIPアドレスとパスワードを使用して、以下のいずれかの方法でEC2インスタンスに接続してください：
ssh splunk@IP addressワークショップでは vi を使用してファイルを編集します。簡単な使い方を説明します。
ファイルを編集用に開くには：
i を押して Insert mode に切り替え、通常通りテキストを入力します。Esc を押すと Command mode に戻ります。Esc を押してコマンドモードに戻り、:w と入力します。Esc を押してコマンドモードに戻り、:q! と入力します。Esc を押してコマンドモードに戻り、:wq と入力します。vi の包括的な説明については An introduction to the vi editor を参照してください。
別のエディタを使用したい場合は、代わりに nano を使用できます：
「データを取り込む」ための最初のステップは、OpenTelemetry Collectorをデプロイすることです。Collectorは環境内のテレメトリデータを受信して処理し、Splunk Observability Cloudにエクスポートします。
このワークショップではKubernetesを使用し、Helmを使用してK8sクラスターにCollectorをデプロイします。
HelmはKubernetes用のパッケージマネージャーで、以下のような利点があります：
正しいディレクトリに移動し、スクリプトを実行してCollectorをインストールしましょう：
スクリプトの実行には1分程度かかる場合があります。
このスクリプトはどのようにしてCollectorをインストールしたのでしょうか？まず、~./profile ファイルに設定された環境変数が読み込まれていることを確認しました：
重要：以下のコマンドは
1-deploy-otel-collector.shスクリプトによって既に実行されているため、 実行する必要はありません。
次に、splunk-otel-collector-chart Helmチャートをインストールし、最新の状態であることを確認しました：
最後に、helm install を使用してCollectorをインストールしました：
helm installコマンドはvalues.yamlファイルを参照していることに注意してください。 このファイルは Collector の設定をカスタマイズするために使用されます。詳細は後述します。
以下のコマンドでCollectorが実行中かどうかを確認できます：
Splunk Observability Cloudで、Infrastructure → Kubernetes → Kubernetes Clusters に移動し、
クラスター名（$INSTANCE-k3s-cluster）を検索します：
Collectorの設定をカスタマイズする前に、現在の設定がどのようになっているかを 確認するにはどうすればよいでしょうか？
Kubernetes環境では、Collectorの設定はConfig Mapを使用して保存されています。
以下のコマンドで、クラスター内に存在するconfig mapを確認できます：
次に、以下のようにしてCollectorエージェントのconfig mapを表示できます：
K8sでは values.yaml ファイルを使用してCollectorの設定をカスタマイズできます。
values.yamlファイルで利用可能なカスタマイズオプションの包括的なリストについては、 このファイルを参照してください。
例を見てみましょう。
Collectorに送信されるトレースを確認したいとします。この目的にはdebug exporterを使用できます。これはOpenTelemetry関連の問題のトラブルシューティングに役立ちます。
vi または nano を使用して values.yaml ファイルを編集できます。ここではviを使用した例を示します：
以下のテキストをコピーして values.yaml ファイルの末尾に貼り付けて、debug exporterを追加します：
以下のテキストを追加する前に、vi で ‘i’ を押してインサートモードに入ってください。
これらの変更後、values.yaml ファイルは以下の内容を含むはずです：
vi で変更を保存するには、
escキーを押してコマンドモードに入り、:wq!と入力してからenter/returnキーを押します。
ファイルを保存したら、以下のコマンドで変更を適用できます：
values.yaml ファイルを通じてCollectorの設定を変更した場合は、
config mapを確認して、Collectorに適用された実際の設定を確認することが有用です：
期待通り、debug exporterがtracesパイプラインに追加されたことが確認できます：
debug exporterの出力については、クラスターにアプリケーションをデプロイして トレースのキャプチャを開始した後に確認します。
この時点で、K8sクラスターにOpenTelemetry Collectorをデプロイし、 インフラストラクチャメトリクスの収集に成功しています。
次のステップは、サンプルアプリケーションをデプロイし、 OpenTelemetryで計装してトレースをキャプチャすることです。
Pythonで書かれたマイクロサービスベースのアプリケーションを使用します。ワークショップをシンプルに保つため、 credit check serviceとcredit processor serviceの2つのサービスに焦点を当てます。
時間を節約するため、両方のサービスのDockerイメージを既に構築してDocker Hubで公開しています。 以下のコマンドで、K8sクラスターにcredit check serviceをデプロイできます：
次に、credit processor serviceをデプロイしましょう：
最後に、トラフィックを生成するロードジェネレーターをデプロイしましょう：
このセクションでは、アプリケーションの概要を説明します。アプリケーションの完全な ソースコードを確認したい場合は、GitHub の Observability Workshop リポジトリを参照してください。
credit check serviceとcredit processor serviceのビルドに使用されるDockerfileを見ると、
OpenTelemetryで既に計装されていることがわかります。例として、
/home/splunk/workshop/tagging/creditcheckservice-py-with-tags/Dockerfile を見てみましょう：
splunk-py-trace-bootstrap が含まれていることがわかります。これは、アプリケーションで使用される
サポートされているパッケージにOpenTelemetryの計装をインストールします。また、splunk-py-trace が
アプリケーションを起動するコマンドの一部として使用されていることもわかります。
/home/splunk/workshop/tagging/creditcheckservice-py-with-tags/requirements.txt ファイルを確認すると、
パッケージのリストに splunk-opentelemetry[all] が含まれていることがわかります。
最後に、このサービスのデプロイに使用したKubernetesマニフェスト（/home/splunk/workshop/tagging/creditcheckservice-py-with-tags/creditcheckservice-dockerhub.yaml）を確認すると、
コンテナに環境変数が設定されており、OTLPデータのエクスポート先を
OpenTelemetryに伝えていることがわかります：
これだけで、サービスをOpenTelemetryで計装できます！
アプリケーションでいくつかのカスタムタグをキャプチャしていますが、これについては後ほど詳しく見ていきます。その前に、 タグの概念とそれが重要な理由について説明します。
タグは、トレース内のスパンに関する追加のメタデータを提供するキーと値のペアで、Splunk APM に送信するスパンのコンテキストを充実させることができます。
例えば、決済処理アプリケーションでは以下を追跡できると便利です：
これにより、決済処理中にエラーやパフォーマンスの問題が発生した場合、トラブルシューティングに必要なコンテキストを得ることができます。
一部のタグはOpenTelemetry Collectorで追加できますが、このワークショップで扱うタグはより詳細なもので、アプリケーション開発者がOpenTelemetry SDKを使用して追加します。
タグは、アプリケーションを真にオブザーバブルにするために不可欠です。トレースにコンテキストを追加することで、 なぜ一部のユーザーは素晴らしい体験を得て、他のユーザーはそうでないのかを理解する助けになります。また、 Splunk Observability Cloud の強力な機能は、タグを活用して根本原因に素早くたどり着くことを支援します。
先に進む前に用語について説明します。このワークショップでは tags（タグ）について説明しますが、 これは Splunk Observability Cloud で使用する用語です。OpenTelemetry では 代わりに attributes（属性）という用語を使用します。そのため、このワークショップ全体で タグが言及されている場合、それは属性と同義として扱ってください。
Pythonアプリケーションでタグをキャプチャするには、まず /home/splunk/workshop/tagging/creditcheckservice-py-with-tags/main.py ファイルの先頭に
import文を追加してtraceモジュールをインポートします：
次に、現在のスパンへの参照を取得して、属性（別名タグ）を追加できるようにします：
とても簡単ですよね？credit check serviceで合計4つのタグをキャプチャしており、最終的な結果は以下のようになります：
Splunk Observability Cloudでトレースデータを確認する前に、 以下のコマンドでエージェントCollectorのログをtailして、debug exporterがキャプチャした内容を確認しましょう：
ヒント：CTRL+C を使用してログのtailを停止します。
エージェントCollectorのログに以下のようなトレースが書き込まれているはずです：
トレースに、コードでキャプチャした credit.score や credit.score.category などの
タグ（属性とも呼ばれる）が含まれていることに注目してください。次のセクションで、
Splunk Observability Cloudでトレースを分析してパフォーマンス問題の根本原因を見つける際に、これらを使用します。
Tag Spotlight などの Splunk Observability Cloud の高度な機能を使用するには、まず1つ以上のタグをインデックスする必要があります。
これを行うには、Settings -> MetricSets に移動し、APM タブが選択されていることを確認します。次に + Add Custom MetricSet ボタンをクリックします。
以下の詳細を入力して credit.score.category タグをインデックスしましょう（注意：ワークショップの参加者全員が同じ組織を使用しているため、このステップはインストラクターが代わりに行います）：
Start Analysis をクリックして続行します。
分析が実行されている間、タグは Pending MetricSets のリストに表示されます。
分析が完了したら、Actions 列のチェックマークをクリックします。
このタグをインデックスするために、Troubleshooting MetricSet と呼ばれるものを作成したことにお気づきかもしれません。Troubleshooting MetricSet（TMS）は、Tag Spotlight などの機能を使用してこのタグに関する問題をトラブルシューティングできるため、このように名付けられています。
また、選択しなかった Monitoring MetricSet（MMS）という別のオプションがあることにもお気づきかもしれません。Monitoring MetricSetはトラブルシューティングを超えて、タグをアラートやダッシュボードに使用できます。このワークショップではこの機能については詳しく説明しませんが、ぜひご自身で探索することをお勧めする強力な機能です。
キャプチャしたAPMデータの一部を確認して、アプリケーションのパフォーマンスを見てみましょう。
APM に移動し、Environment ドロップダウンを使用して環境を選択します（例：tagging-workshop-instancename）。
サービスのリストに creditprocessorservice と creditcheckservice が表示されているはずです：
右側の Service Map をクリックしてサービスマップを表示します。creditcheckservice が creditprocessorservice を呼び出しており、平均応答時間が少なくとも3秒であることがわかります：
次に、右側の Traces をクリックして、このアプリケーションでキャプチャされたトレースを確認します。一部のトレースは比較的高速（数ミリ秒程度）に実行される一方、他のトレースは数秒かかることがわかります。
実行時間の長いトレースの1つをクリックします。この例では、トレースに5秒かかり、ほとんどの時間が creditprocessorservice の一部である /runCreditCheck 操作の呼び出しに費やされていることがわかります：
しかし、なぜ一部のトレースは遅く、他のトレースは比較的速いのでしょうか？
トレースを閉じてTrace Analyzerに戻ります。Errors only を on に切り替えると、一部のトレースにエラーがあることにも気づくでしょう：
エラートレースの1つを見ると、creditprocessorservice が otherservice という別のサービスを呼び出そうとしたときにエラーが発生していることがわかります。しかし、なぜ一部のリクエストは otherservice への呼び出しを行い、他のリクエストは行わないのでしょうか？
一部のリクエストがなぜ遅く実行され、一部のリクエストがなぜエラーになるのかを特定するために、 トレースを1つずつ確認して問題の背後にあるパターンを見つけようとすることもできます。
Splunk Observability Cloud は、問題の根本原因を見つけるためのより良い方法を提供します。次にこれを確認しましょう。
credit.score.category タグをインデックスしたので、Tag Spotlight と一緒に使用してアプリケーションをトラブルシューティングできます。
APM に移動し、右側の Tag Spotlight をクリックします。Service ドロップダウンから creditcheckservice サービスが選択されていることを確認します（まだ選択されていない場合）。
Tag Spotlight を使用すると、impossible のスコアになるクレジットスコアリクエストの100%にエラーがあることがわかります。一方、他のすべてのクレジットスコアタイプのリクエストにはまったくエラーがありません！
これは Tag Spotlight の威力を示しています！この機能がなければ、このパターンを見つけるのは時間がかかります。数百のトレースを手動で確認してパターンを特定する必要があり（それでも見つかる保証はありません）。
エラーを確認しましたが、レイテンシはどうでしょうか？Requests & errors distribution ドロップダウンをクリックして Latency distribution に変更しましょう。
重要：Cards display の横にある設定アイコンをクリックして、P50 と P99 のメトリクスを追加します。
ここでは、poor クレジットスコアのリクエストが遅く実行されていることがわかります。P50、P90、P99の時間は約3秒で、これはユーザーが待つには長すぎ、他のリクエストよりもはるかに遅いです。
また、exceptional クレジットスコアの一部のリクエストも遅く実行されていることがわかります。P99の時間は約5秒ですが、P50の応答時間は比較的速いです。
リクエストに関連付けられたクレジットスコアカテゴリがパフォーマンスとエラー率に影響を与える可能性があることがわかったので、インデックスされたタグを活用する別の機能を確認しましょう：Dynamic Service Maps です。
Dynamic Service Mapsを使用すると、特定のサービスをタグ別に分解できます。例えば、APM をクリックし、次に Service Map をクリックしてサービスマップを表示しましょう。
creditcheckservice をクリックします。次に、右側のメニューで Breakdown というドロップダウンをクリックし、credit.score.category タグを選択します。
この時点で、サービスマップは動的に更新され、creditcheckservice に到達するリクエストのパフォーマンスがクレジットスコアカテゴリ別に分解されて表示されます：
このビューにより、good と fair のクレジットスコアのパフォーマンスは優れている一方、poor と exceptional のスコアははるかに遅く、impossible のスコアはエラーになることが明確にわかります。
Tag Spotlight により、このサービスを担当するエンジニアがさらに調査すべきいくつかの興味深いパターンが明らかになりました：
impossible クレジットスコアリクエストがエラーになるのか？poor クレジットスコアリクエストが遅く実行されるのか？exceptional リクエストが遅く実行されるのか？SREとして、このコンテキストをエンジニアリングチームに伝えることは、彼らの調査に非常に役立ちます。サービスが「時々遅い」と単に伝えるよりも、はるかに迅速に問題を追跡できるからです。
興味があれば、creditprocessorservice のソースコードを確認してください。impossible、poor、exceptionalのクレジットスコアを持つリクエストは異なる方法で処理されており、そのため我々が発見したエラー率とレイテンシの違いが生じていることがわかります。
アプリケーションで見られた動作は、モダンなクラウドネイティブアプリケーションでは一般的なものです。サービスに渡される異なる入力が異なるコードパスにつながり、その一部がパフォーマンスの低下やエラーを引き起こします。例えば、実際のクレジットチェックサービスでは、低いクレジットスコアになるリクエストは、リスクをさらに評価するために別のダウンストリームサービスに送信される場合があり、高いスコアになるリクエストよりも遅く実行されたり、より高いエラー率に遭遇したりする可能性があります。
このワークショップでは、以下の概念についてハンズオン形式で学びました：
このワークショップで共有したベストプラクティスに沿ってタグを収集することで、Splunk Observability Cloud に送信するデータからさらに多くの価値を得ることができます。このワークショップを完了した今、自分のアプリケーションからタグの収集を開始するために必要な知識を身につけました！
今日からタグのキャプチャを始めるには、サポートされている各言語でタグを追加する方法を確認し、次にTag Spotlightで分析できるように Troubleshooting MetricSets を作成する方法を確認してください。さらにヘルプが必要な場合は、Splunk エキスパートに問い合わせてください。
また、他の言語や環境がOpenTelemetryでどのように計装されているかを確認するには、 Splunk OpenTelemetry Examples GitHub リポジトリを参照してください。
ワークショップが完了したら、以前に credit.score.category タグ用に作成したAPM MetricSetを削除することを忘れないでください。